Rebuilding RHEL3 libc.so from source

Jarod Wilson jarod at wilsonet.com
Sat Jul 14 01:47:28 EDT 2007


On Jul 13, 2007, at 17:50, Ben Scott wrote:

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

While you're playing around, rpmbuild -bb is probably sufficient, as - 
ba will write out a new srpm every time, which may just be wasted  
time. I generally prod a spec, do what needs doing, rpmbuild -bb a  
few times until I've got exactly what I'm after, then do an rpmbuild - 
bs to immortalize it in a new srpm. Well, actually, most of the time,  
I'm working from our cvs repo, so I just commit the changes and throw  
a build at the build system, but then I'm talking about work on some  
of the official packages that come out of Red Hat... :) (I've been  
VERY busy with our kernel spec file of late...)

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

If you do a diff on the package list between RHEL3 GA and Red Hat  
Linux 9 GA, you'll find an amazing number of packages with the exact  
same name-version-release, and in fact, they *are* the same bits...  
And a lot of RHEL3 was built on Red Hat Linux 9, and/or on the  
development tree leading up to FC1.

Similar case with RHEL5. During the pre-release RHEL5 development  
cycle, pre-Fedora Core 6 rawhide and to-be-RHEL5 were built from the  
exact same bits, the only real difference being the kernel. They were  
then forked at some point, and Fedora kept on rolling forward with  
new bits, while RHEL5 started stabilizing the bits we froze on. If  
there's a big toolchain change (big update to glibc, gcc, etc),  
everything will get rebuilt with the latest toolchain, but yeah,  
stuff sometimes gets built against earlier versions of other stuff  
that winds up being slightly different than what you'd get if you  
rebuilt against the released stuff. Fun, eh? :)

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

It largely boils down to mock these days. A srpm gets thrown at a  
build server, which ultimately calls mock to populate a build chroot  
from a given package tree, based on minimal buildroot specs and the  
BuildRequires of the srpm, then builds the package. The current  
public build system for Fedora 7 and rawhide, called koji, the old  
FC6-extras build system, called plague, and Red Hat's internal build  
system, called brew, all ultimately make the same calls to mock. (nb:  
koji and brew are almost identical, but brew as-is wasn't possible to  
release to the world).

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

I suspect a combination of maybe not applying all the patches and  
other possible tweaks from the %prep section of the spec, and then  
using a different set of compile flags probably were the cause. Most  
packages are configured using the %configure macro, which auto- 
expands to a bunch of stuff... (grep around in /usr/lib/rpm to see  
the full expansion, which includes CFLAGS/CPPFLAGS/LDFLAGS, etc).


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

Yes, the rpmbuild process automagically strips all binaries as part  
of its %install section. These bits are pulled out and put into  
debuginfo packages. Special care is taken to make sure Makefiles and  
install commands DON'T strip anything, so that the debuginfo creation  
bits are left to handle that. If you build stuff by hand out of the  
rpm, you'll more likely than not indeed end up with unstripped binaries.


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

One can also use mock locally to generate a build chroot -- for  
example, my x86_64 Fedora 7 workstation at the office has RHEL4,  
RHEL5, FC6, F7 and rawhide, x86_64 and i386 build chroots managed by  
mock on it, so I can basically do native builds of any bits as needed...

-- 
Jarod Wilson
jarod at wilsonet.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://mail.gnhlug.org/mailman/private/gnhlug-discuss/attachments/20070714/bf6f3c04/attachment.bin 


More information about the gnhlug-discuss mailing list