Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
$ ACCEPT_KEYWORDS=ppc emerge libpcre ... libtool: install: warning: remember to run `libtool --finish /usr/lib' echo "/bin/sh ./libtool --mode=install /usr/bin/install -c libpcreposix.la /var/tmp/portage/libpcre-4.2-r1/image//usr/lib/libpcreposix.la" /bin/sh ./libtool --mode=install /usr/bin/install -c libpcreposix.la /var/tmp/portage/libpcre-4.2-r1/image//usr/lib/libpcreposix.la /bin/sh ./libtool --mode=install /usr/bin/install -c libpcreposix.la /var/tmp/portage/libpcre-4.2-r1/image//usr/lib/libpcreposix.la libtool: install: warning: relinking `libpcreposix.la' (cd /var/tmp/portage/libpcre-4.2-r1/work/pcre-4.2; /bin/sh ./libtool --mode=relink gcc -O2 -mcpu=7450 -pipe -I. -I. -rpath /usr/lib -L. -lpcre -version-info 0:0:0 -o libpcreposix.la pcreposix.lo -inst-prefix-dir /var/tmp/portage/libpcre-4.2-r1/image/) ./libtool: line 1: test: too many arguments gcc -dynamiclib -flat_namespace -undefined suppress -o .libs/libpcreposix.0.0.0.dylib pcreposix.lo -L/var/tmp/portage/libpcre-4.2-r1/work/pcre-4.2 /usr/lib/libpcre.dylib -lc -install_name /usr/lib/libpcreposix.0.dylib gcc: /usr/lib/libpcre.dylib: No such file or directory libtool: install: error: relink `libpcreposix.la' with the above command before installing it make: *** [install] Error 1 Reproducible: Always Steps to Reproduce: 1. 2. 3. Portage 2.0.51_pre13 (default-macos-10.3, gcc-3.3, unavailable, 7.4.0 Power Macintosh powerpc) ================================================================= System uname: 7.4.0 Power Macintosh powerpc cat: /etc/gentoo-release: No such file or directory distcc 2.0.1-zeroconf powerpc-apple-darwin7.0 (protocol 1) (default port 3632) [disabled] Autoconf: sys-devel/autoconf-2.57 Automake: sys-devel/automake-1.6.3 Binutils: ACCEPT_KEYWORDS="macos" AUTOCLEAN="yes" CFLAGS="-O2 -mcpu=7450 -pipe" CHOST="powerpc-apple-darwin" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-O2 -mcpu=7450 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache cvs keepwork" GENTOO_MIRRORS="http://ftp.uni-erlangen.de/pub/mirrors/gentoo http://gentoo.osuosl.org/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="macos X berkdb ldap mysql nls perl python readline ruby"
Now that aliases for libtool and libtoolize have been put in the macos profiles (see bug #56648), this bug continues to happen. So it's not a problem with running Apple's libtool instead of GNU libtool: the GNU libtool is being run here. I patched ltmain.sh to do a "set -x" at the top of the file, edited my local libpcre-4.5.ebuild to include the macos keyword, and re-ran "emerge -av libpcre". Here's the result: localhost$ emerge -av libpcre . . . *MANY* lines of output skipped... . . . + test relink = relink + eval '(cd $output_objdir && $rm ${realname}U && $mv $realname ${realname}U)' ++ cd .libs ++ rm -f libpcreposix.0.0.0.dylibU ++ mv -f libpcreposix.0.0.0.dylib libpcreposix.0.0.0.dylibU + test -n '' + save_deplibs= -L/var/tmp/portage/libpcre-4.5/work/pcre-4.5 -L/var/tmp/portage/libpcre-4.5/work/pcre-4.5/.libs /usr/lib/libpcre.dylib -lc + eval 'cmds="$CC' '$(test' '.$module' = .yes '&&' echo -bundle '||' echo '-dynamiclib)' '$allow_undefined_flag' -o '$lib' '$libobjs' '$deplibs$linkopts' -install_name '$rpath/$soname' '$(test' -n '\"$verstring\"' -a 'x$verstring' '!=' x0.0 '&&' echo '$verstring)"' +++ test .no = .yes +++ echo -dynamiclib +++ test -n '"-compatibility_version' 1 -current_version '1.0"' -a x-compatibility_version 1 -current_version 1.0 '!=' x0.0 ./libtool: line 1: test: too many arguments ^^^^^^^^ This is where it begins to go wrong... . . . More output snipped, it's just echoing the "gcc" command below before actually executing it... . . . ++ gcc -dynamiclib -flat_namespace -undefined suppress -o .libs/libpcreposix.0.0.0.dylib pcreposix.lo -L/var/tmp/portage/libpcre-4.5/work/pcre-4.5 -L/var/tmp/portage/libpcre-4.5/work/pcre-4.5/.libs /usr/lib/libpcre.dylib -lc -install_name /usr/lib/libpcreposix.0.dylib gcc: /usr/lib/libpcre.dylib: No such file or directory + exit 1 + echo 'libtool: install: error: relink `libpcreposix.la'\'' with the above command before installing it' libtool: install: error: relink `libpcreposix.la' with the above command before installing it + exit 1 make: *** [install] Error 1 !!! ERROR: dev-libs/libpcre-4.5 failed. !!! Function src_install, Line 37, Exitcode 2 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message. localhost$ Look at the line above my "This is where it begins to go wrong" comment. That test is supposed to be running the following test: test -n \"$verstring\" -a x$verstring != x0.0 && echo $verstring Here we're testing that the $verstring variable is non-empty and is not equal to 0.0. But $verstring, at this point in the code, contains "-compatibility_version 1 -current_version 1.0". The spaces in that variable don't mix well with the "x$verstring != x0.0" test, which ends up seeing "x-compatibility_version 1 -current_version 1.0 != x0.0", and that's where the "too many arguments" comes from. Thus, a test which should have succeeded (and returned 0) fails and returns an error code of 1, which is taken by the rest of ./libtool to be "Oh, the test failed." That sends ./libtool down the wrong branch of an if...then...else conditional, and it never recovers from that first mistake. I think this is the root cause of the problems compiling libpcre.
http://fink.sourceforge.net/doc/porting/preparing.php has a discussion of what looks like this exact bug. It also has a configure patch that can be applied. I'll test it out and report back.
The configure patch gets rid of the "./libtool: line 1: test: too many arguments" errors, but libpcre still does not compile. The "gcc: /usr/lib/libpcre.dylib: No such file or directory" bug is still there. Running the gcc command by hand shows that it fails if /usr/lib/libpcre.dylib is specified explicitly on the command line, but it succeeds if -lpcre is used instead of /usr/lib/libpcre.dylib. Furthermore, the libpcreposix.0.0.0.dylib file thus created has the correct /usr/lib paths built into it: localhost:/var/tmp/portage/libpcre-4.5/work/pcre-4.5 root# otool -L .libs/libpcreposix.0.0.0.dylib .libs/libpcreposix.0.0.0.dylib: /usr/lib/libpcreposix.0.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libpcre.0.dylib (compatibility version 1.0.0, current version 1.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.1.1) (otool -L is the OS X equivalent of the Linux ldd command). It looks like replacing the explicit path in gcc with a -lpcre would be a solution to this bug. Now to find a way to actually implement it.
Further investigation into the innards of ltmain.sh shows that the format (/usr/lib/libpcre.dylib versus -lpcre) of the gcc arguments is controlled by two variables, $hardcode_direct and $hardcode_shlibpath_var, and that configure is responsible for setting these variables (to either "yes" or "no"). If $hardcode_direct is "yes", the /usr/lib/libpcre.dylib format will be used for relinking dynamic libraries such as libpcreposix. If $hardcode_shlibpath is "yes", the -lpcre format will be used for relinking dynamic libraries such as libpcreposix. Obviously both should not be "yes" at the same time. The configure script that comes with libpcre-4.5 contains an entry for Darwin that sets $hardcode_direct to "yes" and $hardcode_shlibpath to "no". My experience, as recorded in comment #3, shows that the -lpcre format would work just fine in relinking, and so $hardcode_direct should be set to "no" and $hardcode_shlibpath to "yes" in configure. I'll create a patch to do just that.
Created an attachment (id=37502) [edit] pcre-4.2-macos.patch Here's the patch described in comment #4. It also includes the configure patch from fink (comment #2) that gets rid of the "./libtool: line 1: test: too many arguments" errors. With this patch, libpcre-4.2-r1, libpcre-4.4, and libpcre-4.5 all build and install just fine on my machine.
Created an attachment (id=37503) [edit] libpcre-4.2-r1.ebuild.patch Patch to libpcre-4.2-r1.ebuild to include the new pcre-4.2-macos.patch (and also the pcre-4.2-link.patch which is also needed to make this version compile).
Created an attachment (id=37504) [edit] libpcre-4.2-r1.ebuild.patch Patch to libpcre-4.2-r1.ebuild to include the new pcre-4.2-macos.patch (and also the pcre-4.2-link.patch which is also needed to make this version compile).
Created an attachment (id=37505) [edit] libpcre-4.4.ebuild.patch Patch to libpcre-4.4.ebuild to include the new pcre-4.2-macos.patch. (Also scratching the duplicate libpcre-4.2-r1.ebuild.patch -- my first submission returned 500 Server Error, and so I re-submitted, but the first one had gone through).
Created an attachment (id=37506) [edit] libpcre-4.5.ebuild.patch Patch to libpcre-4.5.ebuild to include the new pcre-4.2-macos.patch.
Quick question to any developers who read this bug: In the future, when I submit ebuild changes (as opposed to new ebuilds), which would be better: attach just an ebuild patch like I just did, or attach the complete new ebuild (with a -r# version bump). E.g., should I have attached complete libpcre-4.2-r2, libpcre-4.4-r1, and libpcre-4.5-r1 ebuilds?
Commen #10: diff is preferred. You don't need to bump revisions if you only fix build problem. See Ebuild Poilcy http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml for detail.
The libtool 'too many arguments' error is not reproduceable for me. I am however getting the same error as was described in comment #4. The proposed fix there solves the problem, however nothing will be able to link against this library until the ranlib issue is solved. I've updated this bug to reflect that. As soon as the ranlib problem is fixed, I will commit the fix outlined in comment #4.
Dang it! Just upgraded portage and now I'm getting both errors. So as soon as the ranlib problem is fixed, I will incorporate both patches.
From ebuild.sh: #our custom version of libtool uses $S and $D to fix #invalid paths in .la files export S D I'm guessing that this is part of the problem here. Macos does not have gentoo's custom version of libtool, so unfortunately for us, we don't get any nice fixes by the above. I suppose that the best way to deal with this is to use the solution suggested above -- namely to set $hardcode_direct to nom bypassing the problem completely. Might be a recurring issue though... :-(
libpcre ebuild contains both elibtoolize and gnuconfig_update. What happens if you comment out elibtoolize from the ebuild?
I haven't tried commenting out elibtoolize, but note that the problem occurs during econf, not elibtoolize. The proposed patch works, so I'm satisfied to use that unless anyone has a good objection. Unless I hear anything further, I will be rolling in the patch as soon as portage 2.0.51_pre21 comes out.
Re: Comment #15: I tried commenting out elibtoolize during my bughunting. It's been over a week now, and I'm just going by memory, so don't take this as 100% reliable or anything. My memory is that commenting out the elibtoolize call made libpcre compile, *but* that I was suspicious of it: elibtoolize applies the relink patch, which among other things has the following: $echo "$modename: warning: relinking \`$file'" 1>&2 $show "$relink_command" if $run eval "$relink_command"; then : else $echo "$modename: error: relink \`$file' with the above command befo re installing it" 1>&2 - continue + exit 1 fi fi So running elibtoolize means that relinking errors, which *used* to issue a warning and move on, now will exit the make. Was that relink error important? Could it be ignored? I'd rather have the error be issued and exit the ebuild than for the ebuild to go through, only to discover later that we've built a library that can't be used (because it really *needed* to be relinked and the relinking didn't happen). That will cause bug reports from further down the pipe (when someone builds a package that depends on libpcre) instead of bug reports on the libpcre ebuild itself.
I really would be very unhappy to take such a necessary check out of the ebuild, especially when there is a workable fix. If I have relinking errors, I want to know about it.
Agreed. This package needs applying the patch to fix the original error. I thought it was 'too many arguments' type error. Sorry.
In CVS for libpcre-4.5. I do not see the need to support older versions unless there is a specific need, in which case please file a bug.
