On Tue, Aug 14, 2012 at 09:40:28PM -0500, Bruce Dubbs wrote: > Ken Moffat wrote: > > On Tue, Aug 14, 2012 at 08:31:36PM -0500, Bruce Dubbs wrote: > >>> > >>> When the ld.so regexp triggers on x86_64, the line contains: > >>> ld.so-version=$(if $(abi-64-ld-soname),$(abi-64-ld-soname),ld.so.1) > >>> > >>> My initial reaction when I saw that was unprintable - I still have > >>> no idea where the $(abi-64-ld-soname) comes from. But: > >> > >> I thought I mentioned that on the lists. It's an environment variable > >> and is incompatible with the perl script. That's why we remove it with > >> a sed expression. > >> > > Are we at cross-purposes ? > > I don't think so. Am I missing something? > I read your reply as "we use a sed to remove the environment variable". > > All I can see, as of about 24 hours > > ago, is a sed to ensure that the Makefile line to run > > test-installation.pl is deleted. > > Right. Because it doesn't work as you mention above with > $(abi-64-ld-soname). > > > Anyway, I forgot to note which previous sed I'm using for the successful > > run - > > > > DL=$(readelf -l /bin/sh | sed -n 's@.*interpret.*/tools\(.*\)]$@\1@p') && > > sed -i "s|libs -o|libs -L/usr/lib -Wl,-dynamic-linker=$DL -o|" \ > > scripts/test-installation.pl && > > unset DL && > > Are you running on a 64-bit or 32-bit system? I can check it again. > 64-bit. I suspect that 32-bit on a 32bit-only i686 might not have an issue, and that 32-bit on a 64-bit-capable processor will have a similar problem. > > I've commented the other one because it looked as if upstream have > > fixed it : > > #sed -i -e 's/"db1"/& \&\& $name ne "nss_test1"/' > > scripts/test-installation.pl && > > and it seems they have. > > OK. It's been a while since I looked at 7.1 stable and this isn't in > the current xml, even commented out. > > I'll try to put test-installation.pl back in and test it. I've got a > couple of changes to make first for gcc and perl. The problem is that > it takes a long time to build and test these packages and I don't want > to make too many changes to svn at once. > For the moment, please don't treat this as a priority. I've been distracted by other things today and am nowhere near confirming that it is indeed a perl-5.16 problem. If it isn't caused by perl-5.16, then fixing the perl is not the right answer.
OTOH, if anyone is building 32-bit and can keep the glibc source and build directories around, testing a change to the perl script should only take a few seconds. Oddly, I had to run it from within the *source* directory. If I do blame the perl version [ plausible, a lot of "baggage" was dropped in 5.16 ], I'll produce instructions for changing the file and for how to run it. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
