ICA/Farce

Ken Moffat ken at linuxfromscratch.org
Mon Oct 27 08:24:48 PDT 2008


On Mon, Oct 27, 2008 at 06:51:38AM -0700, Dan Nicholson wrote:
> On Sun, Oct 26, 2008 at 2:00 PM, Greg Schafer <gschafer at zip.com.au> wrote:
> >
> > I've never looked at jhalfs but I understand it implements my ICA
> > algorithms. My own scripts have been getting exceptionally clean
> > results lately now that the randomness in GCC builds has apparently gone
> > as of GCC 4.3. I'll happily check any results you can post up.
> 
> I'm obviously out of the loop on building toolchains, but the most
> recent ICA issues with gcc was that a checksum of the .o files was
> built into the gcc binary. Since DIY uses LDFLAGS="-s", the .o files
> are stripped as they're linked. The checksum for the .o files is then
> always the same since the debug symbols are gone when the checksum is
> taken. In LFS, the stripping is always done after the fact, but by
> then the checksum has been built into the binary. But, that was a
> couple releases ago.
> 
 I no longer remember the details (it was too long ago), but I
_think_ what I was seeing was different object code somewhere (I had
the impression it might be moving things at random).  Perhaps only
on 64-bit builds.  I got rid of all my local farce workfiles earlier
this month, so I have no data. [ engages brain, goes off to look for
the mail from archaic to see if it will help ... ]

 Archaic saw unresolved differences for x86 with gcc-4.1.2.
Actually, looking at his results (they're at ~/archaic) they look
pretty good - blkid.tab.old and locale-archive should probably now
be expected to differ, and they were the only differences between
his second and third builds.

 Between his first and second builds, he also had differences in cc1
and cc1plus (maybe down to the checksums), libstdc++.la and
libsupc++.la (the path on one pair has some unnecessary repeats),
nscd, and coreutils.info.  The info file was encoding
the version of makeinfo it was using, and build one seems to have
used the host's version.  I think we maybe altered something to fix
that.  Nscd is a different matter.

 My own notes show that c++ programs and libraries were showing
differences I couldn't adequately explain, and I was marking these
as 'expected' for programs like lynx (it's not in the base LFS).

 I'm not sure I like building with LDFLAGS=-s for general use,
anything that helps get a backtrace might be valuable.  But for a
system only used for analysis, it wouldn't be a problem.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce



More information about the lfs-dev mailing list