Finished First Pass

Jan-Christoph Bornschlegel trollfood at
Wed Feb 3 00:26:48 PST 2010

Mike McCarty schrieb:
> I don't think you'd be very satisfied if you used, say RHEL,
> and downloaded the source they claimed was that of the compiler
> they used to build, and when you built it using the copy you
> have on your machine, the results were different.

Erm, maybe you underestimate the distros here :)

Can't speak for RHEL, but in the openSUSE/SLE? world there's a similar
bootstrapping in the build system which makes sure the distributed
compiler is build "with itself", and since the RPM build produces
gcc-x.y.z.rpm and gcc-x.y.z.src.rpm at the same step it's pretty safe
that if you install the corresponding source package (same release
number, or query rpm --qf '%{SOURCE}' <name> and the like to be sure),
you can reproduce the same binary, as long as the version numbers of the
required tools didn't change for some updates and the like.

Most distros only release the updated binutils, for example, but don't
update everything else -- although the root tree of the build system
rebuilds all the depending packages, which means "ALL" in case of gcc,
glibc, binutils and so on, which is why the gcc developers tend to
submit new versions on Thursday or friday, to let the system settle by
monday :)

The reason? Hm, not sure, I think maybe most "customers" don't want to
update all installed packages just for a bugfix in, say, "yes".
If you desire that, there are so called "factory" repositories you can
subscribe to for bleeding edge distro, but with a certain chance of
broken packages.

There may be distro-specific patches, bugfixes and the like, but those
are included in the source package.


More information about the lfs-support mailing list