[lfs-dev] Glibc-2.16.0 [ test-installation.pl ]
zarniwhoop at ntlworld.com
Wed Aug 15 08:56:06 PDT 2012
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
> > 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
> > Anyway, I forgot to note which previous sed I'm using for the successful
> > run -
> > DL=$(readelf -l /bin/sh | sed -n 's at .*interpret.*/tools\(.*\)]$@\1 at 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
> > 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.
das eine Mal als Tragödie, das andere Mal als Farce
More information about the lfs-dev