Rebuilding RHEL3 libc.so from source

[Ben Scott]

On 7/13/07, Michael ODonnell <michael.odonnell at comcast.net> wrote:
> I've modified my approach somewhat.  I had first naively
> thought I could just explode the source RPM and run a
> build that would leave all the resultant objs and libs
> in the build area ...

  "rpmbuild -ba" should do that, more or less.  It will also package
whatever the spec says to package, but that shouldn't hurt.

> ... the libc.so that I ended up with seems to be wildly different
> from the pre-built version(s) ...

  That's what worries me.  It should match the official binaries, more
or less.  Some things do occur to me though:

  1. Build environment.

  Binaries are very dependent on their build environment.  While RPM
lets the packager specify build dependencies and such, that process is
as error-prone as any other part of software development is.

  Building the system library is especially tricky.  Chicken-and-egg
problem.  How did Red Hat build the first RHEL3 system library, since
there wasn't a RHEL3 yet?  It must have been on a non-RHEL3 system.
But you're on a RHEL3 system.  But...

  I don't know if the glibc spec file alone is "smart enough" to take
care of all the subtleties that could arise in the above.  It may be
that Red Hat has some external framework to automate the bootstrap
process in the above.  Indeed, I'd be surprised if they didn't.
Unfortunately, I have no clue as to help you find out on this one.

  2. Build options.

  It's possible to specify conditions in a spec file, and define
macros on the rpmbuild command line to trigger them, such that the
same spec file can build very different binaries.  Same idea as with
the C pre-processor.  But again, I have no clue as to specifics.

  3. Symbols

  This strikes me as rather unlikely, but: I wonder if strip(1) is
being built-in to the RPM packaging process, and thus leaving you with
unstripped binaries under BUILD, but stripped binaries in the package.
 I don't think so, but I can't say for sure that isn't what's going
on.  You can use rpm2cpio(1) and cpio(1) to extract the plain old
files from an RPM package to any given directory, and check them that
way.

>  - Explode the RPM
>  - Make local modifications.
>  - Generate patch file reflecting those changes.
>  - Mention that patch file in a local spec file derived
>    from the one originally in the SRPM.
>  - rpmbuild a new RPM from the SRPM
>  - Install (or something) from that new RPM
>  - crash

  That's roughly the right idea.

  One thing you may want to explore is the "--root" option to rpm(8).
You can use it to create a nearly-complete copy of a Red Hat system in
a subdirectory, and then use chroot(1) to switch into that system.
Kind of like a virtual machine, but without all the
separate-partition-and-kernel grief.

  HTH,

-- Ben