Version 7.0-cross-lfs-20051023-x86_64

Ken Moffat ken at
Mon Oct 24 07:43:47 PDT 2005

On Mon, 24 Oct 2005, Duncan Webb wrote:

>>> wouldn't it be better to say:
>>> echo "am_cv_func_working_getline=yes" > config.cache
>>> because if the configure has already been run then the cache file should 
>>> be truncated.
>>  I've assumed that _some_ architectures already write to config.cache in 
>> these cases, but I haven't looked too deeply (the aim is to keep the text 
>> common between the different architectures, so e.g. the multilib/foo-64.xml 
>> will include chunks from common/foo.xml).  Maybe there is a better way to 
>> set it out ? - obviously just '>config.cache' would do it in all cases 
>> where it is needed, but it would look clunky.
> Wouldn't think that it would make any difference which architecture you use 
> there shouldn't be a config.cache until either one in initialised as 
> described or configure has been run once.

  I'll rephrase - I think that an arch I don't have (probably sparc, or 
mips, or just one of their variants) has *already* echoed something into 
config.cache before adding the am_cv_func_working_getline.  Therefore, 
for that arch the >> is necessary.  This only causes you a problem if 
you rebuild, or retry after an error, without deleting the source/build 

> 9.4. Expect-5.43.0
> I think the configure line should be:
> CC="gcc ${BUILD64}" ./configure --prefix=/tools --with-tcl=/tools/lib \
>  --with-tclinclude=$TCLPATH --with-x=no
> because the tools have not yet been built to default to 64bit.

  No, in the previous section where you build tcl you should have used a 
sed on to force lib64, and also passed --libdir=/tools/lib64.
But please read the rest of my reply!

> 10.3. Glibc-20050926
> Got an error during make check, did make install and then make check again, 
> the check had no error after the install, odd behaviour.

  Your *next* point, and the absence of 32-bit in this package name, 
make me think you've switched to pure64 (x86_64-64) AFTER following the 
multilib book in the initial chapters.  Perhaps, you came back to it and 
mixed the different architectures ?

  FWIW, in 20050926 64-bit I see *an* error (in wcsmbs, from memory - my 
logs are on another box).  Haven't tried running check after installing 
the 64-bit libc, but the error seems to have gone in last week's 
snapshot.  For 32-bit libc I'm getting a mass of errors in make check, 
but nobody else has commented on them, so it could be an error in my 

> Hope this helps
> 10.5. Binutils-2.16.1
> I'm getting there errors which running check, any idea what I should do?
> Running /sources/binutils-2.16.1/ld/testsuite/ld-bootstrap/bootstrap.exp ...
> FAIL: bootstrap
> FAIL: bootstrap with strip
> FAIL: bootstrap with --traditional-format
> FAIL: bootstrap with --no-keep-memory
> FAIL: bootstrap with --relax
> Running /sources/binutils-2.16.1/ld/testsuite/ld-cdtest/cdtest.exp ...
> FAIL: cdtest
> FAIL: cdtest with -Ur
  In pure64 (at least for x86_64-64) this seems "normal".  I spent an 
hour or two looking at the ld test suites last week after confirming 
that multilib passes all of the binutils tests, but so far I haven't 
even identified what is failing, or why.

  Hopefully, I won't offend you when I say that you need to follow ONE 
architecture (multilib, or pure64) at a time, and when I point out that 
pure64 on amd64 works reasonably well _except_ for grub, and that 
multilib x86_64 has some issues with perl (see Ryan's reply to me last 
week on this list).

  das eine Mal als Tragödie, das andere Mal als Farce

More information about the lfs-dev mailing list