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 symbols: File in wrong format Expected Results: a compiled mpfr as a prerequisite for gcc
Created attachment 130764 [details] build log
Created attachment 131052 [details, diff] 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 >
Created attachment 131054 [details] 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.
Created attachment 131056 [details, diff] 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.
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. >
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. > > >
Comment on attachment 131056 [details, diff] this will fix the aforementioned expectation to find .libs/libmpfr.lai during the install phase these changes are not correct
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
*** Bug 261423 has been marked as a duplicate of this bug. ***
Happens as well with the recent one and is sorely annoying.
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.
*** Bug 432124 has been marked as a duplicate of this bug. ***
