ICA support status

Dan Nicholson dbn.lists at gmail.com
Mon Apr 17 08:20:10 PDT 2006


On 4/17/06, M.Canales.es <manuel at linuxfromscratch.org> wrote:
>
> Here are available the build logs and ICA/farce reports from my last 5 builds:
>
> http://www.macana-es.com/logs/
<snip>
> build4 has 2 iterations, no testsuites, no stripping, and no reinstallation
> issues.

Looks great, Manuel.  To allay any fears, these files:

Binary files iteration-1/usr/bin/perl and iteration-2/usr/bin/perl differ
Binary files iteration-1/usr/bin/perl5.8.8 and
iteration-2/usr/bin/perl5.8.8 differ
Binary files iteration-1/usr/bin/vim and iteration-2/usr/bin/vim differ
Binary files iteration-1/usr/lib/perl5/5.8.8/i686-linux/CORE/libperl.a/perl.o
and iteration-2/usr/lib/perl5/5.8.8/i686-linux/CORE/libperl.a/perl.o
differ
Binary files iteration-1/usr/sbin/nscd and iteration-2/usr/sbin/nscd differ

always differ because they have embedded timestamps.  A lot of
binaries include dates in them, so if the build goes overnight, you'll
see a lot of differences.  These guys (perl is the worst) put the time
in, too.  If you're interested, I have hacks to remove the timestamps
at build time.  I did this to be absolutely certain that the
differences were timestamp related and not build related.  I wouldn't
use the hacks on for anything more than testing, though.

This file:

Binary files iteration-1/usr/lib/locale/locale-archive and
iteration-2/usr/lib/locale/locale-archive differ

always differs, too.  Greg Schafer pointed out to me some time ago
that even if you always define the same locales, the locale-archive
file will differ.  Possibly this is due to timestamps created by
localedef.  I don't know.  I always suppress the locale installation
during ICA runs, but it probably doesn't matter.

All of the c++ files always differ, too.  Greg asked on the GCC list a
long time ago about this.  They replied that, indeed, the c++ binaries
have some random bits embedded.  I don't recall the reason.  These
files:

/usr/include/c++/4.0.3/i686-pc-linux-gnu/bits/stdc++.h.gch/O0g.gch
/usr/include/c++/4.0.3/i686-pc-linux-gnu/bits/stdc++.h.gch/O2g.gch

differ for me between the first and second runs, but not the second
and third.  I don't know the reason why.  I've always meant to look
into it, but never got around to it.  It seems like it's over my head.

Results are exactly the same as I always get.  Looks great.  I'll try
to do a jhalfs build on anduin to see if the same results come back as
with my scripts.  I don't have a timeframe for that, though.

--
Dan



More information about the alfs-discuss mailing list