[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Ccrtp-devel] Re: address@hidden: Bug#176721: libccrtp_1.0pre0-1(mips/un
From: |
David Sugar |
Subject: |
[Ccrtp-devel] Re: address@hidden: Bug#176721: libccrtp_1.0pre0-1(mips/unstable): configure built with brokenlibtool.m4] |
Date: |
Wed, 15 Jan 2003 12:06:55 -0500 |
User-agent: |
KMail/1.4.3 |
Mark,
for bug reports on ccrtp, the correct address is the list, address@hidden
That way more eyes get to look at it, and especially everyone with cvs
commit. It would also be useful to pass it through the commonc++ list(s)
especially when (like this one) we are talking about a bug that effects
multiple packages. I have an older "stable" reference system that I still
use for cutting all my primary "production release" tarballs for
distributions and I am loath to migrate it to a more recent GNU/Linux
distribution, though I probably should update automake/autoconf/libtool on it
at least.
David
On Wednesday 15 January 2003 04:45, Mark Purcell wrote:
> David (and others),
>
> I have received the attached report from Ryan Murray regarding problems
> trying to autobuild ccrtp with a broken libtool.m4 on the mips
> architecture.
>
> As Ryan suggests this is fixed by updating all the libtool related files
> in the source tree. I have applied this the to the Debian GNU/Linux source
> tree for your application, but you might also like to update the upstream
> source tree as well.
>
> Mark
>
> Btw, which is the correct address for bug reports, the included README file
> is not clear.
>
> ----- Forwarded message from Ryan Murray <address@hidden> -----
>
> From: address@hidden (Ryan Murray)
> Date: Tue, 14 Jan 2003 13:11:35 -0800
> To: address@hidden
> User-Agent: Mutt/1.3.28i
> Subject: Bug#176721: libccrtp_1.0pre0-1(mips/unstable): configure built
> with broken libtool.m4 Reply-To: address@hidden (Ryan Murray),
> address@hidden
>
> Package: libccrtp
> Version: 1.0pre0-1
> Severity: serious
>
> There was an error while trying to autobuild your package:
> > Automatic build of libccrtp_1.0pre0-1 on resume.rfc822.org by sbuild/mips
> > 1.170 Build started at 20030107-1449
>
> [...]
>
> > ** Using build dependencies supplied by package:
> > Build-Depends: debhelper (>> 3.0.0), libcommoncpp2-dev, libxml2-dev
>
> The version of libtool used to build this source package is too old to
> correctly support shared libraries for the Debian mips and mipsel
> architectures. At least version (1.4.2-7) and higher correctly supports
> them. You need to update all of the libtool related files by running
> the following on your source tree:
>
> libtoolize --force --copy
> aclocal
> autoheader
> automake
> autoconf
>
> autoheader may not be needed, and you may need to use autoconf2.13
> rather than autoconf.
>
> You may also need to apply the patch in libtool bug #98342 if your
> package builds more than one library, where one library depends on the
> other. Versions of libtool from 1.4.2-7.1 include a fix for this problem
> already, so using the newest version is recommended.
>
> The correct 'configure' script will have output that looks like this:
> # This must be Linux ELF.
> linux-gnu*)
> case $host_cpu in
> alpha* | hppa* | i*86 | mips | mipsel | powerpc* | sparc* | ia64* | s390*
> ) lt_cv_deplibs_check_method=pass_all ;;
> *)
>
> Older versions of libtool used a file_magic check for the pattern
> file_magic ELF [0-9][0-9]*-bit [LM]SB (shared object|dynamic lib )
>
> The output of file(1) on a shared library on MIPS does not match this
> regular expression, however. Earlier versions of file had been
> modified to match this regular expression, but the latest version uses
> the same output as upstream once again. The file check often causes
> problems, and results on a build-dep on file that you might not
> otherwise be aware of. The new method doesn't need file(1) at all,
> and is far less fragile, so it is best to upgrade the configure script
> with proper mips support.
>
>
> ----- End forwarded message -----