[lfs-dev] Glibc-2.16.0 [ test-installation.pl ]

Bruce Dubbs bruce.dubbs at gmail.com
Wed Aug 15 19:51:01 PDT 2012


Bruce Dubbs wrote:
> Bruce Dubbs wrote:
>> Ken Moffat wrote:
>>> On Wed, Aug 15, 2012 at 04:56:06PM +0100, Ken Moffat wrote:
>>>>   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.
>>>>
>>>   Bad news, I get the same regex error with perl-5.14.2.
>>
>> I don't think it's a perl issue.
>
> The script is reading /sources/glibc-build/soversions.mk.  The important
> part here is
>
> if (/^ld\.so/) {
>        ($ld_so_name, $ld_so_version)= /=(.*)\.so\.(.*)$/;
> }
>
> where the input line is:
>
> ld.so-version=$(if $(abi-64-ld-soname),$(abi-64-ld-soname),ld.so.1)
>
> What perl is doing is setting two variables, $ld_so_name and
> $ld_so_version according to the regular expression /=(.*)\.so\.(.*)$/
>
> So the first variable, $ld_so_name is
> $(if $(abi-64-ld-soname),$(abi-64-ld-soname),ld
>
> And the second, $ld_so_version, is 1
>
> This is clearly wrong.  So what we have is that soversions.mk is not
> being generated correctly.  It should be
>
> ld.so-version=ld-linux-x86-64.so.2.  Then the variables would be
> ld-linux-x86-64 and 2 respectively.
>
> For a 32-bit system we should have ld.so-version=ld-linux.so.2 and the
> variables are then ld-linux and the version is still 2.
>
>>>   I think that means our build process is no longer adequate for this
>>> version of glibc.
>
> That's overstating things a bit.  I'm looking at how soversions.mk is
> generated.  There are several possibilities, scripts/soversions.awk,
> glibc-build/soversions.i, configure, and Makeconfig.  I'll keep looking
> and let you know what's going on.

soversions.mk is created in make, not make install.  The suspect code is 
in Makeconfig around line 839:

echo "$$lib.so-version=\$$(if 
\$$(abi-$(default-abi)-$$lib-soname),\$$(abi-$(default-abi)-$$lib-soname),$$number)"

This is using make syntax.  $$ is a literal dollar sign here, but I 
don't understand the \$$ construct.  Perhaps it gets reduced to \$ by 
make and then to just $ by echo.

$(default-abi) is defined to be the ABI for the current glibc build, 
either 32 or 64.

$$lib (translated to $lib) is set in the environment and is defined at 
line 832 from the read of soversions.i as 'ld'. Likewise $$number is 
'ld.so.1' from the same read.  Translating, we get:

echo "$$lib.so-version=\$$(if 
\$$(abi-64-ld-soname),\$$(abi-64-ld-soname),ld.so.1)"

abi-64-ld-soname (and abi-32-ld-soname) is defined in 
sysdeps/unix/sysv/linux/x86/Makefile.

I think I've narrowed down where the problem is, but a fix would 
probably be a sed.  This is really a complex mechanism, and fixing the 
generation of soversions.mk really isn't necessary if we just delete the 
unneeded call to test-installation.pl (as done now in svn).  I don't see 
any other use of soversions.mk in the code.

Another possible fix is to sed soversions.mk after make.

   -- Bruce



More information about the lfs-dev mailing list