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

[Aaron Wegner]

Hi Stuart.  If the platform is not the host then base_libs will be
installed by default.  In the configuration, if C library package from
toolchain only is selected then it'll grab the libc shared libraries from
the toolchain, otherwise it'll only grab libgcc and c++ shared libraries,
so it's not a compatibility issue.  The base_libs package fails because
the files

rootfs/lib/libstdc++.so.6.0.14
rootfs/lib/libgcc_s.so.1

require things like ld.so.1(GLIBC_2.3) which are provided by glibc.  When
performing the install section of the spec file of glibc there are
printouts for the Provides and Requires, and confusingly there are
libraries and versions common to both sections such as ld.so.1(GLIBC_2.3).
 You can see this in the text file I attached earlier.  The obvious
question is if a package provides something how can that package also
require it?  I tried digging into the file

/opt/ltib/usr/lib/rpm/find-requires

and was able to get the install section to only print out

Requires: /bin/bash /bin/sh /usr/bin/perl

thinking that maybe if I suppressed the requirement that the provision
would be recognized, but unfortunately this didn't work and maybe it's
just a printout and not something that gets incorporated into the RPM
database.  I'm afraid I'm a bit lost at the moment.  Might have to stick
with the fake provides hack as the quickest solution for now.  If anyone
working with C libraries from the glibc source files has encountered the
problem of provides not being recognized by other packages and can shed
some light it would be appreciated.


Thanks,

Aaron

> 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
>>>>
>>>
>>
>>
>>
>