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 >>> [email protected] >>> https://lists.nongnu.org/mailman/listinfo/ltib >>> >> > > > _______________________________________________ LTIB home page: http://ltib.org Ltib mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/ltib
