Everybody knows that libtool can be problematic in multilib.
Mostly (at least in clfs1) the problems show up in blfs 32-bit and
we can pass LDFLAGS='-L/lib -L/usr/lib' or occasionally LD="gcc
${BUILD32}". However, something happened between 20060424 and
20060515 to cause one of the 32-bit libtool tests (pdemo-make) to
fail. The main change in that period was changing the build order
to match LFS, perhaps that exposed the problem or perhaps it was
something else. I've now got it passing all 103 tests again on
32-bit powerpc64, but only by playing with LDEMULATION.
If I try passing LDFLAGS as above (for configure), 4 of 98 tests
fail. If I try make LD="gcc ${BUILD32}"eck then 46 tests pass and
57 are skipped, which isn't the coverage I was looking for ;)
With make LDEMULATION=elf32ppc all 103 tests pass, but clearly this
is an arch-specific value (from ld -V, then pick your favourite
emulation and see if that fixes it).
So far, I know the test failure exists on powerpc64 for 32-bit and
on sparc multilib for 32-bit (it's in Jim's results).
I expect it exists on x86_64 for 32-bit (probably fixable with
LDEMULATION=elf_i386 ) but I don't have a recent x86_64 multilib
build to test on, and I'm not close to building one.
Probably, it exists in some of the mips multilib variants (maybe
both 32 and n32) but I have no way of testing those and no results I
can look at.
This only affects the test results, and the fix only affects how we
run the tests. I suppose I need to open a ticket for this.
Anybody here with multilib x86_64 or mips who can confirm or deny
the test failure exists ?
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
_______________________________________________
Clfs-dev mailing list
[email protected]
http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-dev
