Re: [Ltib] build with C library from glibc fails at base_libs and elsewhere

[Aaron Wegner]

Hi Stuart.  I'm using freescale-powerpc-linux-gnu-2011.03-38.i686.rpm
(Sourcery G++ Lite 2011.03-38) for my cross-toolchain and that comes with
a glibc version numbered 2.13.  I came across a problem running perl that
was giving me a printout like the following.

ld.so: dl-deps.c: 622: _dl_map_object_deps: Assertion
`nlist > 1' failed!

Found a thread suggesting that it was a problem with 2.13 and fixed at
some point in time.

http://sourceware.org/bugzilla/show_bug.cgi?id=12454

So, I decided to compile glibc-2.14 and that worked for me and I could run
perl normally.  However, like I said I had to add a bunch of junk to the
fake-provides.  It's clear that the glibc binary RPM does provide a full
set of libraries and ELF symbol versions that the base_libs and other
packages end up requesting.  Somehow this does not get written correctly
in the glibc binary RPM, so the list of things that it advertises that it
provides is less than what it actually does provide, causing base_libs and
subsequent packages to fail in the build process.  I had tried this before
a couple of years ago (C library package from glibc not toolchain) and
encountered the same situation.  Anyone else compiled a glibc in a similar
manner?  At this point it's looking closer to a necessity for the project
I'm working on, assuming that perl is required.


> Hi Aaron,
>
> You should not need to "fiddle" the provides/includes.  The way it works
> is that rpm runs a script that effectively does an "nm" to see what is
> required/provided, it works on ltib via the spoofing mechanism that
> makes it use the cross-tools (IIRC).  What it parses is everything under
> the rpm staging area after it has run the install.
>
> Are you building glibc? if so why, that is possible but not normal.
> Normally I'd expect base_libs to be used to extract the
> headers/libraries from the toolchain.
>
> Regards, Stuart
>
> On 19/03/13 19:23, Aaron Wegner wrote:
>> Hi Stuart.  I'm trying to understand how RPM packages generate their
>> provides and requires sections, and in particular why my glibc-2.14
>> seems
>> to not list in the provides section things that it does provide, and
>> hence
>> causes other packages later in the build to fail to deploy.  I have
>> attached a log file of my build breaking at the base_libs package.  As
>> an
>> iterative process, if I insert lines into the fake-provides.spec,
>> eventually all my packages build and run normally.  The list of lines I
>> had to insert for my particular case are below.
>>
>> Provides : ld.so.1(GLIBC_2.1)
>> Provides : ld.so.1(GLIBC_2.3)
>> Provides : libc.so.6(GLIBC_2.0)
>> Provides : libc.so.6(GLIBC_2.1)
>> Provides : libc.so.6(GLIBC_2.1.3)
>> Provides : libc.so.6(GLIBC_2.2)
>> Provides : libc.so.6(GLIBC_2.2.4)
>> Provides : libc.so.6(GLIBC_2.3)
>> Provides : libc.so.6(GLIBC_2.3.2)
>> Provides : libc.so.6(GLIBC_2.4)
>> Provides : libm.so.6(GLIBC_2.0)
>> Provides : libm.so.6(GLIBC_2.4)
>> Provides : libc.so.6(GLIBC_2.1.1)
>> Provides : libc.so.6(GLIBC_2.2.1)
>> Provides : libc.so.6(GLIBC_2.2.3)
>> Provides : libc.so.6(GLIBC_2.3.3)
>> Provides : libc.so.6(GLIBC_2.3.4)
>> Provides : libdl.so.2(GLIBC_2.0)
>> Provides : libdl.so.2(GLIBC_2.1)
>> Provides : libc.so.6(GLIBC_2.7)
>> Provides : libc.so.6(GLIBC_2.12)
>> Provides : libnsl.so.1(GLIBC_2.0)
>> Provides : libcrypt.so.1(GLIBC_2.0)
>> Provides : libutil.so.1(GLIBC_2.0)
>> Provides : libthread_db.so.1(GLIBC_2.1.3)
>> Provides : libthread_db.so.1(GLIBC_2.2.3)
>> Provides : libthread_db.so.1(GLIBC_2.3)
>>
>> However, there must be a smoother way to do this.  For instance, the
>> glibc
>> rpm after deployment does provide
>>
>> $ ls -l rootfs/lib/libthread_db.so.1
>>
>> and I can see the version GLIBC_2.1.3 using readelf.
>>
>>
>> Thanks,
>>
>> Aaron
>>
>>
>>
>> _______________________________________________
>> LTIB home page: http://ltib.org
>>
>> Ltib mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/ltib
>>
>