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
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
