Rebuilding RHEL3 libc.so from source

[Jarod Wilson]

On Wednesday 18 July 2007 04:09:50 pm Michael ODonnell wrote:
> >> ...so I suspect that may have something to do with the differences
> >> that I mentioned between the libs I'm building versus what's in
> >> the RHAT-built RPM.  Can somebody tell me how to persuade rpmbuild
> >> to generate anything named *.i686.rpm from that SRPM?
> >
> > Ah, whoops, forgot about that.  A select few packages get built i686
> > as well as i386, with the i686 build being preferred on capable
> > systems -- those packages are glibc, openssl and the kernel,
> > I believe.  So just:
> >
> >$ rpmbuild -bb --target i686 glibc.spec
> >
> >(or rpmbuild --rebuild --target i686 glibc-*.src.rpm)
>
> Wow - what a difference!  Whoops, indeed...

I blame it on the fact I have pretty much nothing but x86_64 systems 
anymore. :)

> That little tweak resulted in just these 3 RPMs being generated:
>
>    RPMS/i686/glibc-2.3.2-95.50.i686.rpm
>    RPMS/i686/glibc-debuginfo-2.3.2-95.50.i686.rpm
>    RPMS/i686/nptl-devel-2.3.2-95.50.i686.rpm
>
> ...instead of the 10 that were getting built by default, and my
> glibc-2.3.2-95.50.i686.rpm now only differs in size from the RHAT-built
> one by a few bytes, which are explainable by the presence of my helloWorld
> debug stub in there.  It's impressive that (what would seem to be) such
> a relatively small change in the target CPU could lead to such wildly
> different sizes, contents and number of libraries.

The number of files spit out is solely dependent on %ifarch bits in the spec 
file. The file sizes are due to very different compiler flags, includes, 
etc., based on the differences between building i386 and i686.

> At any rate, this is *much* more like what I wanted - yay!

Glad to hear it.

> BTW, that cool dynamic-loader debugging trick I mentioned is this:
> invoke any program you like from the command line thus:
>
>    LD_DEBUG=help yourProgramHere
>
> ...and the dynamic loader (which is always secretly invoked when you
> run anything that uses DSOs - Dynamic Shared Objects) will describe all
> the options available to you and then exit without running your program.
>
> Change that "help" to one of the valid options (try "all") and stand back
> while the gory details of how the loader resolves every symbol reference
> and every library lookup flies by on the screen.  Or that output can be
> captured in the location specified by LD_DEBUG_OUTPUT.  Incredibly useful
> when your !@$#!! libraries are b0rken.       (guess how I know...)

Ooh, much fun be there...

> Thanks again to all for the help.

On behalf of all who helped, no problem, always happy to help. :)

-- 
Jarod Wilson
jarod at wilsonet.com