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
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
