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

[Stuart Hughes]

Hi Aaron,

You should not have glibc and base_libs enabled, maybe that's the issue?

It's been a long time since I build glibc with LTIB, but I have done it
and as far as I recall I did not need to "lie" in fake-provides about
the provides of glibc.

If you've turned off base_libs, and you don't want to "lie" in
fake-provides, you'll need to dig into the find/provides scripts of rpm
to figure out what's wrong.

Regards, Stuart

On 22/03/13 15:21, Aaron Wegner wrote:
> 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
>>>
>>
> 
> 
>