[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#176311: gcc-3.2: configure generated from broken libtool.m4

Is it likely this will be addressed in the gcc-3.2 branch?

Ryan Murray writes:
> Package: gcc-3.2
> Version: 1:3.2.2ds4-0pre5
> Severity: grave
> 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.
> This problem causes libstdc++ to be built improperly, without
> depending on shared libraries that it needs to, which in turn breaks
> several other c++ builds.
> -- 
> To UNSUBSCRIBE, email to debian-gcc-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: