Version 7.0-cross-lfs-20051023-x86_64

Ken Moffat ken at linuxfromscratch.org
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 
directories.

> 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 Makefile.in 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 
buildscripts.

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

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


More information about the lfs-dev mailing list