dev-libs/mpfr fails to cross-compile: "/usr/lib/libgmp.so: could not read symbols: File in wrong format"

[Jacob Godserv]

The error message is quite simple:
/usr/lib/libgmp.so: could not read symbols: File in wrong format

The issue is the autoconf tool incorrectly configures mpfr for cross-compiling, and so it fails when it tries to link against a host library. The fix is not to patch mpfr, but autoconf itself. Yuck.

[cfriedt (chrisfriedt)]

arm-softfloat-linux-gnu-ld attempts to link to the i686 elf shared object, libgmp.so.3.4.1, located in /usr/lib before trying to link to the arm shared object located in the default search path, /usr/arm-softfloat-linux-gnu/usr/lib.

If a new ebuild is created passing in the arguments --with-gmp-lib=/usr/arm-softfloat-linux-gnu/usr/lib and --with-gmp-include=/usrarm-softfloat-linux-gnu/usr/include, then the configure script complains that the c compiler cannot create executables.

================================================================================
output of PORTAGE_CONFIGROOT=/root/tmp ROOT=/root/tmp emerge --info:
================================================================================
Portage 2.1.2.12 (default-linux/arm/2007.0, gcc-4.1.1, glibc-2.5-r4, 2.6.21.6 i686)
=================================================================
System uname: 2.6.21.6 i686 Pentium II (Klamath)
Gentoo Base System release 1.12.9
Timestamp of tree: Mon, 10 Sep 2007 19:00:01 +0000
app-shells/bash: 3.1_p17
dev-lang/python: 2.4.3-r4
dev-python/pycrypto: 2.0.1-r6
sys-apps/baselayout: 1.12.9
sys-apps/sandbox: 1.2.17
sys-devel/autoconf: 2.61
sys-devel/automake: 1.10
sys-devel/binutils: 2.17
sys-devel/gcc-config: 1.3.16
sys-devel/libtool: 1.5.22
virtual/os-headers: 2.6.21
ACCEPT_KEYWORDS="arm"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-Os -pipe -mtune=arm920t"
CHOST="arm-softfloat-linux-gnu"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo"
CTARGET="arm-softfloat-linux-gnu"
CXXFLAGS="-Os -pipe -mtune=arm920t"
DISTDIR="/root/tmp/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="-k"
FEATURES="buildpkg distlocks metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"
MAKEOPTS="-j2"
PKGDIR="/root/tmp/var/tmp/binpkgs"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/root/tmp/var/tmp"
PORTDIR="/root/tmp/usr/portage"
PORTDIR_OVERLAY="/root/tmp/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="arm berkdb bzip2 crypt ncurses nptl nptlonly pcre python readline ssl tcpd zlib" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" USERLAND="GNU"
Unset: INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
================================================================================

================================================================================
output of /root/tmp/var/tmp/portage/dev-libs/mpfr-2.2.1_p5/temp/build.log will follow in an attachment
================================================================================

Reproducible: Always

Steps to Reproduce:
1. create a cross-toolchain for arm-softfloat-linux-gnu
2. emerge baselayout int /root/tmp
3. USE="fortran gcj mudflap -nls" PORTAGE_CONFIGROOT=/root/tmp ROOT=/root/tmp emerge -av gcc

Actual Results:
/usr/lib/libgmp.so: could not read symbo...

[cfriedt (chrisfriedt)]

Created attachment 130764
build log

[cfriedt (chrisfriedt)]

Created attachment 131052
when cross-compiling, allows compiler to search in directories other than /usr/lib for libgmp.so

I created a patch (attached) that has disabled the '-rpath ${libdir}' portion in Makefile.in . The problem was that the rpath directive was preventing the compiler from looking in all directories containing libgmp.so (even the built-in search path for the cross-compiler, i.e. /usr/arm-softfloat-linux-gnu/{lib,usr/lib}).

The libgmp.so that it did try to link to was in /usr/lib. It was a symbolic link to libgmp.so.3.4.1 for the build architecture, hence the 'file is in wrong format' because the libgmp.so was not an arm shared object.

Note1, this problem was only encountered when cross-compiling (i686->arm).

Note2, you should rename this patch file to patch06 and put it in dev-libs/mpfr/files/2.2.1, and then rename the ebuild to mpfr-2.2.1_p6.ebuild so that the patch is applied automatically. Either that, or save it as mpfr-2.2.1-disable-rpath-to-fix-cross.patch, and then do

tc-is-cross-compiler && \
epatch ${FILESDIR}/${PV}/mpfr-2.2.1-disable-rpath-to-fix-cross.patch \
|| die "patch failed: mpfr-2.2.1-disable-rpath-to-fix-cross.patch"

(In reply to comment #1)
> Created an attachment (id=130764) [edit]
> build log
>

[cfriedt (chrisfriedt)]

Created attachment 131054
build.log after my first patch

Apparently /usr/bin/install expexts that .la files from the sourcedir should be suffixed with an 'i', as in .libs/libmpfr.lai, before they are installed.

This log file just illustrates that tendency causing an error during the emake install portion of the build.

I would think that this is something that could be changed easily. I'm going to put up another patch that will address Makefile.in and correct that issue.

[cfriedt (chrisfriedt)]

Created attachment 131056
this will fix the aforementioned expectation to find .libs/libmpfr.lai during the install phase

After applying mpfr-2.2.1-disable-rpath-to-fix-cross.patch, which fixed the 'make' phase during cross-compile, and mpfr-2.2.1-fix-install-lai-issue.patch, which fixed the 'make install' phase during cross-compile, this package installed cleanly.

[cfriedt (chrisfriedt)]

I would suggest that someone please review these patches, although they are very clean and apply only to Makefile.in.

The first patch, mpfr-2.2.1-disable-rpath-to-fix-cross.patch, should be renamed to patch06 and copied to portage/dev-libs/mpfr/files.

The second patch, mpfr-2.2.1-fix-install-lai-issue.patch, should be renamed to patch06 and copied to portage/dev-libs/mpfr/files.

The ebuild mpfr-2.2.1_p5.ebuild may simply be copied to mpfr-2.2.1_p7.ebuild, then a digest may be created with 'ebuild mpfr-2.2.1_p7.ebuild digest', and that can be marked stable after review.

Best regards,

Chris

ps: oh yeah, I also had to patch gmp to have that compile (prereq for mpfr and also for gcc when fortran is selected.... still working on the gcc part for cross-compiling i686->arm-softfloat-linux-gnu)
(In reply to comment #4)
> Created an attachment (id=131056) [edit]
> this will fix the aforementioned expectation to find .libs/libmpfr.lai during
> the install phase
>
> After applying mpfr-2.2.1-disable-rpath-to-fix-cross.patch, which fixed the
> 'make' phase during cross-compile, and mpfr-2.2.1-fix-install-lai-issue.patch,
> which fixed the 'make install' phase during cross-compile, this package
> installed cleanly.
>

[cfriedt (chrisfriedt)]

For some reason, even though --enable-shared is passed in as a configure option in the ebuild (same as before), the .so files are not copied over, only the .a files.

This should be fixed in the Makefile.in as well.

(In reply to comment #5)
> I would suggest that someone please review these patches, although they are
> very clean and apply only to Makefile.in.
>
> The first patch, mpfr-2.2.1-disable-rpath-to-fix-cross.patch, should be renamed
> to patch06 and copied to portage/dev-libs/mpfr/files.
>
> The second patch, mpfr-2.2.1-fix-install-lai-issue.patch, should be renamed to
> patch06 and copied to portage/dev-libs/mpfr/files.
>
> The ebuild mpfr-2.2.1_p5.ebuild may simply be copied to mpfr-2.2.1_p7.ebuild,
> then a digest may be created with 'ebuild mpfr-2.2.1_p7.ebuild digest', and
> that can be marked stable after review.
>
> Best regards,
>
> Chris
>
>
> ps: oh yeah, I also had to patch gmp to have that compile (prereq for mpfr and
> also for gcc when fortran is selected.... still working on the gcc part for
> cross-compiling i686->arm-softfloat-linux-gnu)
> (In reply to comment #4)
> > Created an attachment (id=131056) [edit]
> > this will fix the aforementioned expectation to find .libs/libmpfr.lai during
> > the install phase
> >
> > After applying mpfr-2.2.1-disable-rpath-to-fix-cross.patch, which fixed the
> > 'make' phase during cross-compile, and mpfr-2.2.1-fix-install-lai-issue.patch,
> > which fixed the 'make install' phase during cross-compile, this package
> > installed cleanly.
> >
>

[Mike Frysinger (vapier)]

Comment on attachment 131056
this will fix the aforementioned expectation to find .libs/libmpfr.lai during the install phase

these changes are not correct

[Mike Frysinger (vapier)]

this really falls into the "libtool has problems with cross-compiling" category as this is not mpfr specific at all ... the code you're touching is all autogenerated from the autotool packages

you should be able to workaround the issue on your machine by doing:
rm /usr/lib/libm.so
echo 'GROUP ( /lib/libm.so )' > /usr/lib/libm.so

[Jacob Godserv (fun2program8)]

We can't fix this. We depend on the developers of autoconf at this point.

[Jacob Godserv (fun2program8)]

Worked around the issue by adding 'USE="-fortran"' to SYSROOT make.conf. mpfr is no longer required at that point.

[Jacob Godserv (fun2program8)]

Errr, 'USE="{$USE} -fortran"', but smart folks should know that. ;)

[Mike Frysinger (vapier)]

*** Bug 261423 has been marked as a duplicate of this bug. ***

[Lu-zero (lu-zero)]

Happens as well with the recent one and is sorely annoying.

[Lu-zero (lu-zero)]

a good workaround is removing the .la from gmp and generally from everything else.
I'm tempted to make libtool ignore the .la if a .so exists.

[Mike Frysinger (vapier)]

*** Bug 432124 has been marked as a duplicate of this bug. ***