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
