Despite repeated rebuilds, libpcre always installs non-functional libtool wrappers to "${EPREFIX}/usr/bin/pcregrep" and "${EPREFIX}/usr/bin/pcretest". When building using 'ebuild' manually, the MIPS binaries are correctly located in "${S}/.libs/", but only libtool wrappers end up in "${ED}/usr/bin/" after "ebuild install". Since the majority of packages aren't affected by this problem (binutils being the notable exception... for some reason, the first build of a given version of binutils will always install libtool wrappers, and any subsequent builds of the same version will always correctly install the binaries) I'm assuming that this problem is generally unique to libpcre. Clearly, this can be a serious problem if a nonfunctional wrapper is installed in place of a binary or DSO, and isn't noticed. Would it be practical to modify the portage "install" ebuild stage to recursively scan the "${ED}" directory for libtool wrappers, and abort the install if any are present? I've just checked another system, and files from packages fftw, libmpeg2, libpaper, libpcre, rarian, and scrollkeeper has installed libtool wrappers - but on rebuild, all of these were resolved except for libpcre. (This problem certainly isn't unique to IRIX: One of my Linux systems broke recently, and this too was because a libtool wrapper had been installed - portage really should be checking for this...)
(... although the libtool wrapper for 'storepasswd' from libvncserver turns out to be an ebuild bug, rather than a libtool problem)
This bug seems to deal with lots of issues. - pcre seems to install crap - binutils seems to install crap - request for new QA check in portage for installed libtool wrappers - linux problems with the same libtool crap the QA check: yes we can do, as soon as we know how a wrapper looks like and how we can reliably detect one linux problems would mean that there are others running into similar problems reported on bugzilla or forums.g.o the real issue has to be found and fixed/resolved, e.g. even the initial install of a package should install binaries, not libtool wrappers
Some hints without time to really investigate: IIRC, the usual reason that libtool-wrappers get installed instead of the final binaries is that libtool does not support this combination for the particular platform: *) Installing with DESTDIR *) In-Package shared library dependencies. So when reinstalling a package does help, then the in-package binaries most likely get linked against the already installed shared libs, so relinking the binaries is not necessary as it isn't linked against in-package shared libraries (libtool does detect this). Did have this problem on HP-UX (and maybe AIX) too, had to add elibtoolize-patches for that. Problem is that libtool does not know how to create final binaries as well as shared libraries linking against in-package shared libraries not available in their final directory yet at linktime, that use the shared libraries from their final directory at runtime after package installation has finished. This depends on how to encode RUNPATH into the binaries/sharedlibs at linktime for yet nonexisting runtime dependencies. But it makes me wonder to hear this happening on Linux too...
The case I cited - a problem with libvncserver - turns out not to be the same thing: a libtool wrapper is distributed with the libvncserver source, and this was being installed without having been processed in any way. So, in this case, false alarm. However, I *swear* that, not too many months ago, one of my Linux servers broke (in some minor way) and I traced this down to a libtool wrapper in place of a library. A rebuild fixed this - but it does go to show that it can happen on non-prefix installs too. Unfortunately, I didn't make a note at the time of which package this affected. It does suggest, though, that a QA check would be a great idea - picking up this error for all platforms, so at least an idea of the scale of the problem can be gained. It's probably (highly?) version-specific, but a libtool wrapper will always seem to start: #! /bin/sh # <binary> - temporary wrapper script for .libs/<binary> # Generated by ltmain.sh - GNU libtool 1.5.22 (1.1220.2.365 2005/12/18 22:14:06) # # The <binary> program cannot be directly executed until all the libtool # libraries that it depends on are installed. # # This wrapper script should never be moved out of the build directory. # If it is, it will not operate correctly. ... so when I've been checking for this, I've been looking for the string "temporary wrapper script" on the third line of the file. This may be too specific for a general-use QA check, but it's worked for me so far. I'd suggest that some form of similar test be applied to any file installed by portage with the executable bit set, as well as all libraries (which I guess could be anything beneath libexec/$(get_libdir) or could be containing .so or .a in the filename?) The only gotcha here is that libtool itself should correctly install template files which do match ;)
dev-libs/glib also installs libtool wrappers on first installation, but correct binaries thereafter. I've just done a from-scratch system rebuild, and there don't seem to be many packages affected at all: glib, binutils, and libpcre (although the latter is the only one not resolved by re-installing, and therefore *really* broken).
(In reply to comment #5) > dev-libs/glib also installs libtool wrappers on first installation, but correct > binaries thereafter. This does mean you always have to merge such packages _twice_ when you upgrade them, because the binaries installed as wrappers first are linked against the previously installed old sharedlibs instead of the in-package new ones. But once the old sharedlibs are there, the new version won't install wrappers any more. So it's not easy to notice the package needs a remerge - eventually preserve-libs and/or revdep-rebuild might notice this iff they work.
... and also x11-libs/gtk+ Yes - all of the affected packages (except libpcre, which is weird) will work correctly on the second installation. preserve-libs seems to be a no-go on IRIX, but I have a version of revdep-rebuild (Bug 278081) which works - although it doesn't pick-up these instances (and neither, so far as I can see, would revdep-rebuild on Linux).
Why is preserve-libs a no-go again? Isn't IRIX ELF-based? If we get pax-utils working (scanelf) then it seems we should be fairly easily able to get preserve-libs going on IRIX, unless I forgot something...
IRIX is ELF-based, yes. I haven't looked for a while now, but last time I tried to build pax-utils there was mass breakage.... I'll try again next week, but I'm pretty sure my initial impression was "not gonna work on IRIX" :( In fact, I've just given it a quick bash now, and the build fails with: cc-1035 cc: ERROR File = porting.h, Line = 158 #error directive: "no idea what the native byte order is" # error "no idea what the native byte order is" ^ cc-1040 cc: WARNING File = paxelf.h, Line = 19 An identifier is expected. union { void *ehdr, *vdata; char *data; }; ^ cc-1018 cc: ERROR File = paxinc.h, Line = 105 An unmatched left parentheses "(" appears in an expression. #define warn(fmt, args...) \ ^ cc-1018 cc: ERROR File = paxinc.h, Line = 107 An unmatched left parentheses "(" appears in an expression. #define warnf(fmt, args...) warn("%s%s%s(): " fmt, YELLOW, __FUNCTION__, NORM , ## args) ^ cc-1018 cc: ERROR File = paxinc.h, Line = 108 An unmatched left parentheses "(" appears in an expression. #define warnp(fmt, args...) warn(fmt ": %s" , ## args , strerror(errno)) ^ cc-1018 cc: ERROR File = paxinc.h, Line = 109 An unmatched left parentheses "(" appears in an expression. #define warnfp(fmt, args...) warnf(fmt ": %s" , ## args , strerror(errno)) ^ cc-1018 cc: ERROR File = paxinc.h, Line = 110 An unmatched left parentheses "(" appears in an expression. #define _err(wfunc, fmt, args...) \ ^ cc-1018 cc: ERROR File = paxinc.h, Line = 115 An unmatched left parentheses "(" appears in an expression. #define err(fmt, args...) _err(warn, fmt, ## args) ^ cc-1018 cc: ERROR File = paxinc.h, Line = 116 An unmatched left parentheses "(" appears in an expression. #define errf(fmt, args...) _err(warnf, fmt, ## args) ^ cc-1018 cc: ERROR File = paxinc.h, Line = 117 An unmatched left parentheses "(" appears in an expression. #define errp(fmt, args...) _err(warnp, fmt , ## args) ^ cc-1196 cc: WARNING File = paxelf.c, Line = 98 The indicated function is declared implicitly. type = EGET(EHDR32(elf->ehdr)->e_type); ^ ... cc-1055 cc: ERROR File = paxelf.c, Line = 562 A macro invocation has too many arguments. READELF_HEADER(64) ^ cc-3452 cc: ERROR File = paxelf.c, Line = 562 The compilation is aborted due to the number of errors. 101 errors detected in the compilation of "paxelf.c". make: *** [paxelf.o] Error 2 ... so this could well be a fix of changing GNU-style variadic macros to ones which MIPSpro is happy with (e.g. 'warn(fmt, ...)' where the second argument isn't named) - but I doubt it'll be as simple as that.
After further testing, this problem seems to affect any package which uses/links against gtk+, imagemagick, gegl, libsndfile, and more. In all cases except for libpcre, a second reinstall of the same version results in libraries being created correctly. I've also seem a new phenomenon, which seems to have started at about the same time as the libtool-wrapper issue became obvious, and when the libtool patch was added to prevent libraries being mis-numbered on IRIX: A number of packages will now fail to link unless the installed older version is first removed from the filesystem - otherwise the complains about being unable to remap read-only sections of the existing library. Next time this happens, I'll get a complete dump of the output. I can't help feeling that there's something subtle but also deep and icky broken here :(
$EPREFIX/usr/bin/sndfile-resample also seems to be perpetually broken in spite of rebuilds.
The thing that is broken here is the DESTDIR support of libtool for IRIX. Seems like libtool-maintainers consider DESTDIR support not as mandatory to call a platform as "supported" or "working". They _do_ have tests in their testsuite, but if they detect DESTDIR not being supported, these tests result in "expected failure" or "skipped". First thing you have to figure out is how to correctly use your linker to create sharedlibs and executables linking against uninstalled (not in their final place yet) shared libraries (known as the "linkpath"), but the resulting executables/sharedlibs _do_ search for the dependend sharedlibs in their final place _only_ (or at least: _first_) (known as the "runpath"). This is the missing bit libtool maintainers need to know for your platform. As libtool does not know how to link to-be-installed sharedlibs/programs against uninstalled sharedlibs, and also does not find the needed sharedlibs at their target location (=libdir) yet, it does not (re)link for installation but installs the wrapper instead. This is why the wrapper goes away when merging again (don't know why not for pcre). So you likely will have to dig into libtool internals and get those DESTDIR checks working (PASS). You also will have to *carefully* read your linker manpage (experience shows: read it again and again and again ...)
Okay - that gives me something to work with, thanks. I wonder if only certain version(s) of libtool are affected, though - this problem only occurs with certain packages, definitely doesn't affect the entire system as a whole.
I've just had a read-through (only one, mind ;) of the IRIX 'ld' manpage, and to be honest I'm none the wiser. There doesn't seem to be any mention of anything akin to DESTDIR or indicative of non-in-place linking. The manpage is online here, if you've got the time to take a glance: http://docs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?cmd=getdoc&coll=0650&db=man&fname=1%20ld I've been trying to follow your HP/UX patch from July 2009 - but I really need to sit down with the GNU ld and HP/UX ld manuals to act as a rosetta stone for a comparison.
I've just rebuild libtool (2.2.6b), and all of the test results are "PASS", except for three: FAIL: tests/demo-hardcode.test FAIL: tests/demo-relink.test FAIL: tests/depdemo-relink.test I saw no "expected failure" or "skipped" results. Can you confirm that this matches what you'd expect for broken DESTDIR support? (Are you aware of the IRIX libtool fix which seems to prevent library numbering from being off-by-one - I don't suppose there's any change of a misinteraction with this? There's also weirdness such as Bug 307465...)
(In reply to comment #14) Ohw - DESTDIR is nothing more than a variable for the makefiles, to allow for installing an application into some temporary image location. Within portage/ebuilds, it is the value of ${D} during 'make install', and the makefiles have to put *everything* they install into ${DESTDIR}, but in a state ready to run from /, so the package manager (=portage) only has to take everything from ${DESTDIR} and put it to /. As far as I can read from that manpage, both the linker and the loader provide all the required mechanisms (-rpath,-L,-soname) necessary for libtool to provide everything we expect it to provide - including DESTDIR and SONAME support. Even installing without relinking should be possible when using the _RLD*_ROOT environment variables. So it seems that libtool just doesn't know this...
Created attachment 224045 [details] libtool-2.2.6b build.log build.log for libtool-2.2.6b showing 3/124 test failures. I notice that the test scripts themselves aren't prefixified, so are running from system /bin/sh (e.g. ancient ksh, in this case).
depdemo-relink.test says: depdemo-relink.test: === Running depdemo-relink.test dependencies: l1 (0) l2 (0) l1 (1) l4 (0) l3 (0) l1 (2) l2 (2) l1 (3) libm [sin(1.5) = 0.997495] var_l1(4) + var_l2(6) + var_l4(10) == 20 depdemo-relink.test: === removing libl3.la from depdemo/l3 depdemo-relink.test: === running depdemo/depdemo dependencies: l1 (0) l2 (0) l1 (1) l4 (0) l3 (0) l1 (2) l2 (2) l1 (3) libm [sin(1.5) = 0.997495] var_l1(4) + var_l2(6) + var_l4(10) == 20 depdemo-relink.test: === linking a broken depdemo/l3/libl3.la /opt/gentoo/bin/bash ../libtool --tag=CC --mode=link cc -c99 -O2 -n32 -mips4 -r14000 -float_const -use_readonly_const -TARG:isa=mips4:platform=ip30:processor=r14000 -TENV:zeroinit_in_bss=ON -OPT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON -LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -diag_error 1035,1999,3333 -woff 1174,1183,1185,1552,3968,3970 -no-undefined -Wl,-n32,-mips4,-rdata_shared,-allow_jump_at_eop,-rpath,/opt/gentoo/usr/lib32:/opt/gentoo/lib32 -L/opt/gentoo/usr/lib32 -L/opt/gentoo/lib32 -o libl3.la -rpath /usr/opt/gentoo/var/tmp/portage/sys-devel/libtool-2.2.6b/work/libtool-2.2.6b/_inst/lib ../l2/l2.lo ../l1/libl1.la ../l2/libl2.la libtool: link: cc -shared ../l2/.libs/l2.o -Wl,-rpath -Wl,/opt/gentoo/var/tmp/portage/sys-devel/libtool-2.2.6b/work/libtool-2.2.6b/tests/depdemo/l1/.libs:/opt/gentoo/var/tmp/portage/sys-devel/libtool-2.2.6b/work/libtool-2.2.6b/tests/depdemo/l2/.libs:/usr/opt/gentoo/var/tmp/portage/sys-devel/libtool-2.2.6b/work/libtool-2.2.6b/tests/depdemo/l1/.libs:/usr/opt/gentoo/var/tmp/portage/sys-devel/libtool-2.2.6b/work/libtool-2.2.6b/_inst/lib -L/usr/opt/gentoo/var/tmp/portage/sys-devel/libtool-2.2.6b/work/libtool-2.2.6b/tests/depdemo/l1/.libs -L/opt/gentoo/usr/lib32 -L/opt/gentoo/lib32 ../l1/.libs/libl1.so ../l2/.libs/libl2.so /usr/opt/gentoo/var/tmp/portage/sys-devel/libtool-2.2.6b/work/libtool-2.2.6b/tests/depdemo/l1/.libs/libl1.so -mips4 -r14000 -Wl,-n32 -Wl,-mips4 -Wl,-rdata_shared -Wl,-allow_jump_at_eop -Wl,-rpath -Wl,/opt/gentoo/usr/lib32:/opt/gentoo/lib32 -soname libl3.so.0 `test -n "sgi0.0" && echo "X-set_version sgi0.0" | /opt/gentoo/usr/bin/sed -e 1s/^X//` -update_registry .libs/so_locations -o .libs/libl3.so.0.0 libtool: link: (cd ".libs" && rm -f "libl3.so.0" && ln -s "libl3.so.0.0" "libl3.so.0") libtool: link: (cd ".libs" && rm -f "libl3.so" && ln -s "libl3.so.0.0" "libl3.so") libtool: link: (cd ".libs" && rm -f "libl3.so" && ln -s "libl3.so.0.0" "libl3.so") libtool: link: ( cd ".libs" && rm -f "libl3.la" && ln -s "../libl3.la" "libl3.la" ) depdemo-relink.test: === running depdemo/depdemo with broken libl3.la dependencies: l1 (0) l2 (0) l1 (1) l4 (0) l3 (0) l1 (2) l2 (2) l1 (3) libm [sin(1.5) = 0.997495] var_l1(4) + var_l2(6) + var_l4(10) == 20 depdemo-relink.test: === Exiting: depdemo/depdemo runs even though libl3.la is incomplete depdemo-relink.test: shlibpath_overrides_runpath should be set to no
After running demo-inst.test (and being told "Welcome to GNU Hell!" twice then "Welcome to *modular* GNU Hell!" !?), the results are: demo-hardcode.test: demo-hardcode.test: === Running demo-hardcode.test demo-hardcode.test: === Running `make hardcode' in demo You may ignore any linking errors from the following command: cc -c99 -O2 -n32 -mips4 -r14000 -float_const -use_readonly_const -TARG:isa=mips4:platform=ip30:processor=r14000 -TENV:zeroinit_in_bss=ON -OPT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON -LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -diag_error 1035,1999,3333 -woff 1174,1183,1185,1552,3968,3970 -Wl,-n32,-mips4,-rdata_shared,-allow_jump_at_eop,-rpath,/opt/gentoo/usr/lib32:/opt/gentoo/lib32 -L/opt/gentoo/usr/lib32 -L/opt/gentoo/lib32 -o hc-direct main.o ./.libs/libhello.so -lm -Wl,-rpath -Wl,/usr/opt/gentoo/var/tmp/portage/sys-devel/libtool-2.2.6b/work/libtool-2.2.6b/_inst/lib || echo unsupported > hc-direct ld32: WARNING 84 : /usr/lib32/mips4/libm.so is not used for resolving any symbol. cc -c99 -O2 -n32 -mips4 -r14000 -float_const -use_readonly_const -TARG:isa=mips4:platform=ip30:processor=r14000 -TENV:zeroinit_in_bss=ON -OPT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON -LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -diag_error 1035,1999,3333 -woff 1174,1183,1185,1552,3968,3970 -Wl,-n32,-mips4,-rdata_shared,-allow_jump_at_eop,-rpath,/opt/gentoo/usr/lib32:/opt/gentoo/lib32 -L/opt/gentoo/usr/lib32 -L/opt/gentoo/lib32 -o hc-libflag main.o -Wl,-rpath -Wl,/opt/gentoo/var/tmp/portage/sys-devel/libtool-2.2.6b/work/libtool-2.2.6b/tests/demo/.libs -L/usr/opt/gentoo/var/tmp/portage/sys-devel/libtool-2.2.6b/work/libtool-2.2.6b/_inst/lib -lhello -lm ld32: WARNING 84 : /usr/lib32/mips4/libm.so is not used for resolving any symbol. You may ignore any linking errors from the following command: LD_LIBRARYN32_PATH=./.libs cc -c99 -O2 -n32 -mips4 -r14000 -float_const -use_readonly_const -TARG:isa=mips4:platform=ip30:processor=r14000 -TENV:zeroinit_in_bss=ON -OPT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON -LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -diag_error 1035,1999,3333 -woff 1174,1183,1185,1552,3968,3970 -Wl,-n32,-mips4,-rdata_shared,-allow_jump_at_eop,-rpath,/opt/gentoo/usr/lib32:/opt/gentoo/lib32 -L/opt/gentoo/usr/lib32 -L/opt/gentoo/lib32 -o hc-libpath main.o -lhello -lm -Wl,-rpath -Wl,/usr/opt/gentoo/var/tmp/portage/sys-devel/libtool-2.2.6b/work/libtool-2.2.6b/_inst/lib || echo unsupported > hc-libpath ld32: FATAL 9 : I/O error (-lhello): No such file or directory cc -c99 -O2 -n32 -mips4 -r14000 -float_const -use_readonly_const -TARG:isa=mips4:platform=ip30:processor=r14000 -TENV:zeroinit_in_bss=ON -OPT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON -LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -diag_error 1035,1999,3333 -woff 1174,1183,1185,1552,3968,3970 -Wl,-n32,-mips4,-rdata_shared,-allow_jump_at_eop,-rpath,/opt/gentoo/usr/lib32:/opt/gentoo/lib32 -L/opt/gentoo/usr/lib32 -L/opt/gentoo/lib32 -o hc-minusL main.o -L./.libs -lhello -lm -Wl,-rpath -Wl,/usr/opt/gentoo/var/tmp/portage/sys-devel/libtool-2.2.6b/work/libtool-2.2.6b/_inst/lib || echo unsupported > hc-minusL ld32: WARNING 84 : /usr/lib32/mips4/libm.so is not used for resolving any symbol. demo-hardcode.test: === Finding libtool.m4's guesses at hardcoding values = Searching for hardcoded library directories in each program .libs was not hardcoded in `hc-direct', as libtool expected .libs was hardcoded in `hc-libflag', as libtool expected `hc-libpath' was not linked properly, as libtool expected .libs was hardcoded in `hc-minusL', which fooled libtool demo-relink.test: demo-relink.test: === Running demo-relink.test Welcome to GNU Hell! cos (0.0) = 1 ** This is not GNU Hello. There is no built-in mail reader. ** demo-relink.test: === removing libhello.la from demo demo-relink.test: === running demo/hell Welcome to GNU Hell! cos (0.0) = 1 ** This is not GNU Hello. There is no built-in mail reader. ** demo-relink.test: === linking a broken demo/libhello.la demo-relink.test: === Running `make libhello.la libhello_la_OBJECTS=hello.lo' in demo /opt/gentoo/bin/bash ./libtool --tag=CC --mode=link cc -c99 -O2 -n32 -mips4 -r14000 -float_const -use_readonly_const -TARG:isa=mips4:platform=ip30:processor=r14000 -TENV:zeroinit_in_bss=ON -OPT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON -LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -diag_error 1035,1999,3333 -woff 1174,1183,1185,1552,3968,3970 -no-undefined -version-info 3:12:1 -Wl,-n32,-mips4,-rdata_shared,-allow_jump_at_eop,-rpath,/opt/gentoo/usr/lib32:/opt/gentoo/lib32 -L/opt/gentoo/usr/lib32 -L/opt/gentoo/lib32 -o libhello.la -rpath /usr/opt/gentoo/var/tmp/portage/sys-devel/libtool-2.2.6b/work/libtool-2.2.6b/_inst/lib hello.lo -lm libtool: link: cc -shared .libs/hello.o -L/opt/gentoo/usr/lib32 -L/opt/gentoo/lib32 -lm -mips4 -r14000 -Wl,-n32 -Wl,-mips4 -Wl,-rdata_shared -Wl,-allow_jump_at_eop -Wl,-rpath -Wl,/opt/gentoo/usr/lib32:/opt/gentoo/lib32 -soname libhello.so.2 `test -n "sgi2.11:sgi2.10:sgi2.9:sgi2.8:sgi2.7:sgi2.6:sgi2.5:sgi2.4:sgi2.3:sgi2.2:sgi2.1:sgi2.0:sgi2.12" && echo "X-set_version sgi2.11:sgi2.10:sgi2.9:sgi2.8:sgi2.7:sgi2.6:sgi2.5:sgi2.4:sgi2.3:sgi2.2:sgi2.1:sgi2.0:sgi2.12" | /opt/gentoo/usr/bin/sed -e 1s/^X//` -update_registry .libs/so_locations -o .libs/libhello.so.2.12 ld32: WARNING 84 : /usr/lib32/mips4/libm.so is not used for resolving any symbol. libtool: link: (cd ".libs" && rm -f "libhello.so.2" && ln -s "libhello.so.2.12" "libhello.so.2") libtool: link: (cd ".libs" && rm -f "libhello.so" && ln -s "libhello.so.2.12" "libhello.so") libtool: link: (cd ".libs" && rm -f "libhello.so" && ln -s "libhello.so.2.12" "libhello.so") libtool: link: ( cd ".libs" && rm -f "libhello.la" && ln -s "../libhello.la" "libhello.la" ) demo-relink.test: === running demo/hell with broken libhello.la 36704212:/opt/gentoo/var/tmp/portage/sys-devel/libtool-2.2.6b/work/libtool-2.2.6b/tests/demo/.libs/hell: rld: Error: unresolvable symbol in /opt/gentoo/var/tmp/portage/sys-devel/libtool-2.2.6b/work/libtool-2.2.6b/tests/demo/.libs/hell: nothing 36704212:/opt/gentoo/var/tmp/portage/sys-devel/libtool-2.2.6b/work/libtool-2.2.6b/tests/demo/.libs/hell: rld: Fatal Error: this executable has unresolvable symbols demo-relink.test: === Failed, as expected demo-relink.test: === running demo/hell with installed libhello.la 36736185:/opt/gentoo/var/tmp/portage/sys-devel/libtool-2.2.6b/work/libtool-2.2.6b/tests/demo/.libs/hell: rld: Error: unresolvable symbol in /opt/gentoo/var/tmp/portage/sys-devel/libtool-2.2.6b/work/libtool-2.2.6b/tests/demo/.libs/hell: nothing 36736185:/opt/gentoo/var/tmp/portage/sys-devel/libtool-2.2.6b/work/libtool-2.2.6b/tests/demo/.libs/hell: rld: Fatal Error: this executable has unresolvable symbols demo-relink.test: === shlibpath_overrides_runpath should be set to yes
I was worried that the compiler-wrapper script I'm using might be passing additional -Wl,-rpath or -L options which are confusing libtool - but with this definitively disabled, the results are still the same: demo-hardcode.test: === Finding libtool.m4's guesses at hardcoding values = Searching for hardcoded library directories in each program .libs was not hardcoded in `hc-direct', as libtool expected .libs was hardcoded in `hc-libflag', as libtool expected `hc-libpath' was not linked properly, as libtool expected .libs was hardcoded in `hc-minusL', which fooled libtool demo-relink.test: === running demo/hell with broken libhello.la 36735508:/opt/gentoo/var/tmp/portage/sys-devel/libtool-2.2.6b/work/libtool-2.2.6b/tests/demo/.libs/hell: rld: Error: unresolvable symbol in /opt/gentoo/var/tmp/portage/sys-devel/libtool-2.2.6b/work/libtool-2.2.6b/tests/demo/.libs/hell: nothing 36735508:/opt/gentoo/var/tmp/portage/sys-devel/libtool-2.2.6b/work/libtool-2.2.6b/tests/demo/.libs/hell: rld: Fatal Error: this executable has unresolvable symbols demo-relink.test: === Failed, as expected demo-relink.test: === running demo/hell with installed libhello.la 36716449:/opt/gentoo/var/tmp/portage/sys-devel/libtool-2.2.6b/work/libtool-2.2.6b/tests/demo/.libs/hell: rld: Error: unresolvable symbol in /opt/gentoo/var/tmp/portage/sys-devel/libtool-2.2.6b/work/libtool-2.2.6b/tests/demo/.libs/hell: nothing 36716449:/opt/gentoo/var/tmp/portage/sys-devel/libtool-2.2.6b/work/libtool-2.2.6b/tests/demo/.libs/hell: rld: Fatal Error: this executable has unresolvable symbols demo-relink.test: === shlibpath_overrides_runpath should be set to yes depdemo-relink.test: === running depdemo/depdemo with broken libl3.la dependencies: l1 (0) l2 (0) l1 (1) l4 (0) l3 (0) l1 (2) l2 (2) l1 (3) libm [sin(1.5) = 0.997495] var_l1(4) + var_l2(6) + var_l4(10) == 20 depdemo-relink.test: === Exiting: depdemo/depdemo runs even though libl3.la is incomplete depdemo-relink.test: shlibpath_overrides_runpath should be set to no Hmm - so what *should* shlibpath_overrides_runpath be? These tests indicate both "yes" and "no"! The 'rld' (runtime linker - the binary responsible for loading shared objects) manpage says: The search path for shared objects is as follows: 1. The path of the shared object, if specified in the liblist. That is, if the soname of the shared object has a path. For more information, see the ld(1) man page. 2. DT_RPATH, if it is defined in the executable or any DSO that rld has opened. 3. Use LD_LIBRARY_PATH, if it is defined in the environment at the time of execution. 4. The default library search path. ... which'd indicate shlibpath_overrides_runpath=yes is correct? Which'd indicate a problem with depdemo-relink.test?
(In reply to comment #15) > FAIL: tests/demo-hardcode.test > FAIL: tests/demo-relink.test > FAIL: tests/depdemo-relink.test > > I saw no "expected failure" or "skipped" results. > > Can you confirm that this matches what you'd expect for broken DESTDIR support? Nope: libtool has two generations of testsuites, the new one is run only if the old one does not have FAILs - these three are from the old one. You can run the new one explicitly using 'make check TESTS=' (iirc). What does happen to the tests when you run them using vanilla libtool? And what changes when you run them outside Gentoo Prefix, without the magic of compiler- and ld-wrapper? This is necessary when working with libtool upstream - which is the final target after all... While I can give some hints here and there, I'm afraid I won't have the time to really dig into the libtool internals with you, so I advise to ask libtool upstream for help - sorry.
Created attachment 224129 [details] tests/testsuite.log Well, the good news(?) is that the test passes and failures are identical under Prefix portage with wrappers etc. as when built from source entirely separately by a different user - so portage doesn't appear to be introducing any additional failures.
We are sorry to close this bug. We lack the man-power and devotion to support mips-irix in the tree.
