Re: kernel panic!
Mauricio Casanova wrote: VFS: Cannot open root device hda3 or unknown-block(0,0) Please append a correct root= boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) Do you have SATA? I had problems with grub/SATA once, because Gentoo's livecd recognized the harddisk as hda, but grub wouldn't. The solution for me was to enable SCSI disk and emulation support. Now the disk is beeing accessed as /dev/sda. My menu.lst is: title Gentoo GNU/Linux root(hd0,0) kernel /boot/vmlinuz root=/dev/sda1 Regards, Philipp -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
tls tests fail of gcc-4.0.3 and glibc errors in nptl; what to do now?
Hallo! I'm trying to compile a gcc-4.0.3 to compile glibc-2.3.6 but gcc-4.0.3 tests have tls failures, see attachment test_summary01.out. I ran into problems while trying to upgrade my glibc from 2.3.3-lfs to 2.3.6 (because of x264 using sched_getaffinity() with 2 parms, glibc not beeing executable and now wine segfaulting). There I got errors (see below). Are they related to the gcc tls failures? What can I do with gcc and glibc? Can these problems be related to the kernel 2.6.19.1? My system is an LFS 5.1.1 with upgraded versions of gcc and binutils (binutils-2.15.94.0.2.2 - binutils-2.17.50.0.1) and not 2.4-kernel but 2.6.19.1. I fear that the default gcc (4.1.1) of my system had tls failures too. Thanks for any help, Lynx with gcc-4.0.3: grep Error glibc-check-log0 make[2]: [/usr/src/glibc/glibc-build/posix/annexc.out] Error 1 (ignored) make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancel17.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx4.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx5.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx16.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx17.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx20.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx21.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cleanupx4.out] Error 1 make[1]: *** [nptl/tests] Error 2 make: *** [check] Error 2 with gcc-4.1.1: grep Error glibc-check-log0 make[2]: [/usr/src/glibc/glibc-build/posix/annexc.out] Error 1 (ignored) make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancel17.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx4.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx5.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx16.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx17.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx20.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx21.out] Error 1 make[1]: *** [nptl/tests] Error 2 make[2]: *** [/usr/src/glibc/glibc-build/resolv/tst-leaks.out] Error 1 make[1]: *** [resolv/tests] Error 2 make: *** [check] Error 2 cat 'EOF' | LAST_UPDATED: Obtained from SVN: tags/gcc_4_0_3_release revision 111908 Native configuration is i686-pc-linux-gnu === g++ tests === Running target unix FAIL: g++.dg/tls/static-1.C execution test XPASS: g++.old-deja/g++.other/init5.C execution test === g++ Summary === # of expected passes11462 # of unexpected failures1 # of unexpected successes 1 # of expected failures 69 # of unsupported tests 56 /usr/src/gcc-403/gcc-build/gcc/testsuite/../g++ version 4.0.3 === gcc tests === Running target unix FAIL: gcc.dg/tls/opt-11.c execution test FAIL: gcc.dg/tls/pr24428-2.c execution test FAIL: gcc.dg/tls/pr24428.c execution test XPASS: gcc.dg/vect/vect-22.c scan-tree-dump-times vectorized 3 loops 1 === gcc Summary === # of expected passes35541 # of unexpected failures3 # of unexpected successes 1 # of expected failures 94 # of untested testcases 28 # of unsupported tests 326 /usr/src/gcc-403/gcc-build/gcc/xgcc version 4.0.3 === libmudflap tests === Running target unix === libmudflap Summary === # of expected passes1288 === libstdc++ tests === Running target unix XPASS: 22_locale/locale/cons/12658_thread-1.cc execution test XPASS: 26_numerics/cmath/c99_classification_macros_c.cc (test for excess errors) === libstdc++ Summary === # of expected passes3713 # of unexpected successes 2 # of expected failures 12 Compiler version: 4.0.3 Platform: i686-pc-linux-gnu configure flags: --prefix=/opt/gcc-4.0.3 --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ EOF Mail -s Results for 4.0.3 testsuite on i686-pc-linux-gnu [EMAIL PROTECTED] mv /usr/src/gcc-403/gcc-build/./gcc/testsuite/g++.sum /usr/src/gcc-403/gcc-build/./gcc/testsuite/g++.sum.sent mv /usr/src/gcc-403/gcc-build/./gcc/testsuite/gcc.sum /usr/src/gcc-403/gcc-build/./gcc/testsuite/gcc.sum.sent mv /usr/src/gcc-403/gcc-build/./i686-pc-linux-gnu/libmudflap/testsuite/libmudflap.sum /usr/src/gcc-403/gcc-build/./i686-pc-linux-gnu/libmudflap/testsuite/libmudflap.sum.sent mv /usr/src/gcc-403/gcc-build/./i686-pc-linux-gnu/libstdc++-v3/testsuite/libstdc++.sum /usr/src/gcc-403/gcc-build/./i686-pc-linux-gnu/libstdc++-v3/testsuite/libstdc++.sum.sent mv /usr/src/gcc-403/gcc-build/./gcc/testsuite/g++.log /usr/src/gcc-403/gcc-build/./gcc/testsuite/g++.log.sent mv /usr/src/gcc-403/gcc-build/./gcc/testsuite/gcc.log
Re: gcc testsuite failure
On Sun, Jan 07, 2007 at 07:52:55AM -0800, Zeb Packard wrote:
I'm using the more_control helpers method of package management with
6.2 on running 'make -k check' on gcc my gcc summary is as such:
=== gcc Summary ===
# of expected passes35543
# of unexpected failures1
# of unexpected successes 3
# of expected failures 92
# of untested testcases 28
# of unsupported tests 326
I think that 1 failure from 35544 tests (or pedantically 1 difference
from the log you are comparing to) is no big deal. If you see 10,
perhaps. The key phrase in the LFS book is Unless the test
results are vastly different from those at the above URL, it is safe
to continue.
The unexpected failure deviates from the build logs for 6.2 tracing
the output leads to:
Running /sources/gcc-4.0.3/gcc/testsuite/gcc.dg/cpp/cpp.exp ...
FAIL: gcc.dg/cpp/_Pragma3.c (test for excess errors)
My experience is that 'test for excess errors' is usually the
result of a failure to compile (and for this there is usually an
error message - perhaps the error is on stderr and you missed the
'21' to capture it, or perhaps your case was different). But
again, I'm not inclined to worry about a _single_ failure just
because others haven't seen it. Perhaps, your host system is
unusual, or maybe the host kernel is the problem.
_Pragma3.c contains:
/* { dg-do preprocess } */
/* Pragma buffers have a NULL inc member, which we would dereference
when getting a file's date and time.
Based on PR 7526. 14 Aug 2002. */
#define GCC_PRAGMA(x) _Pragma (#x)
GCC_PRAGMA(GCC dependency mi1c.h)
mi1c.h contains:
/* Redundant header include test with C comments at top. */
# /* And a null directive at the top. */
#ifndef CPP_MIC_H
#define CPP_MIC_H
int a;
#endif
# /* And at the end, too! */
/* And at the end too! */
I'm not sure what this means, I checked the permissions and the
files/directories are all owned by gcc. I'm not much of a c/c++
programmer and I don't know if this is something I can live without or
not.
Thanks in advance.
The gcc bugzilla [ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7526
] shows the original problem was cpp0 dumping core. If that's the
case, the test presumably dumped core, so it would fail to compile.
That doesn't change my view that a single extra failure is almost
certainly not a big deal. Of course, if you build the system and
it then starts dumping core when it encounters _Pragma operations,
that will just prove I'm sometimes wrong ;-)
You've checked the ownership and permissions, so (as someone who
doesn't use the package management method), I think lfs-support
would have been the correct place for this.
ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: gcc testsuite failure
That was my first inclination just install it, but then I read the
warning and decided to look at stuff. After looking, I actually
thought that it was handling comments improperly. I rebuilt it without
'unexpected errors' and I was just about to post a nevermind, but
thanks for looking at it. Checking the package site for open bugs was
definitely something I hadn't thought of.
As far as which list to post to, I figured I had about a 50% chance of
getting that right cause I had no clue what the problem was. :)
On 1/7/07, Ken Moffat [EMAIL PROTECTED] wrote:
On Sun, Jan 07, 2007 at 07:52:55AM -0800, Zeb Packard wrote:
I'm using the more_control helpers method of package management with
6.2 on running 'make -k check' on gcc my gcc summary is as such:
=== gcc Summary ===
# of expected passes35543
# of unexpected failures1
# of unexpected successes 3
# of expected failures 92
# of untested testcases 28
# of unsupported tests 326
I think that 1 failure from 35544 tests (or pedantically 1 difference
from the log you are comparing to) is no big deal. If you see 10,
perhaps. The key phrase in the LFS book is Unless the test
results are vastly different from those at the above URL, it is safe
to continue.
The unexpected failure deviates from the build logs for 6.2 tracing
the output leads to:
Running /sources/gcc-4.0.3/gcc/testsuite/gcc.dg/cpp/cpp.exp ...
FAIL: gcc.dg/cpp/_Pragma3.c (test for excess errors)
My experience is that 'test for excess errors' is usually the
result of a failure to compile (and for this there is usually an
error message - perhaps the error is on stderr and you missed the
'21' to capture it, or perhaps your case was different). But
again, I'm not inclined to worry about a _single_ failure just
because others haven't seen it. Perhaps, your host system is
unusual, or maybe the host kernel is the problem.
_Pragma3.c contains:
/* { dg-do preprocess } */
/* Pragma buffers have a NULL inc member, which we would dereference
when getting a file's date and time.
Based on PR 7526. 14 Aug 2002. */
#define GCC_PRAGMA(x) _Pragma (#x)
GCC_PRAGMA(GCC dependency mi1c.h)
mi1c.h contains:
/* Redundant header include test with C comments at top. */
# /* And a null directive at the top. */
#ifndef CPP_MIC_H
#define CPP_MIC_H
int a;
#endif
# /* And at the end, too! */
/* And at the end too! */
I'm not sure what this means, I checked the permissions and the
files/directories are all owned by gcc. I'm not much of a c/c++
programmer and I don't know if this is something I can live without or
not.
Thanks in advance.
The gcc bugzilla [ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7526
] shows the original problem was cpp0 dumping core. If that's the
case, the test presumably dumped core, so it would fail to compile.
That doesn't change my view that a single extra failure is almost
certainly not a big deal. Of course, if you build the system and
it then starts dumping core when it encounters _Pragma operations,
that will just prove I'm sometimes wrong ;-)
You've checked the ownership and permissions, so (as someone who
doesn't use the package management method), I think lfs-support
would have been the correct place for this.
ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: tls tests fail of gcc-4.0.3 and glibc errors in nptl; what to do now?
On Sun, Jan 07, 2007 at 07:31:16PM +0100, [EMAIL PROTECTED] wrote: Hallo! I'm trying to compile a gcc-4.0.3 to compile glibc-2.3.6 but gcc-4.0.3 tests have tls failures, see attachment test_summary01.out. I ran into problems while trying to upgrade my glibc from 2.3.3-lfs to 2.3.6 (because of x264 using sched_getaffinity() with 2 parms, glibc not beeing executable and now wine segfaulting). There I got errors (see below). Are they related to the gcc tls failures? What can I do with gcc and glibc? Can these problems be related to the kernel 2.6.19.1? My system is an LFS 5.1.1 with upgraded versions of gcc and binutils (binutils-2.15.94.0.2.2 - binutils-2.17.50.0.1) and not 2.4-kernel but 2.6.19.1. I fear that the default gcc (4.1.1) of my system had tls failures too. Thanks for any help, Lynx I'm unclear exactly what you are trying to do, or what toolchains you have available. At first, I thought 'LFS 5.1.1' was a typo for 'LFS 6.1.1', but when you mention '2.4-kernel' I'm not so sure. I'm not familiar with x264 (nor multiprocessors, nor wine), but if you are intending to upgrade glibc on a running system, you have a good chance of breaking things. If you build from source, you should expect to build a new system from time to time. I can't find sched_affinity in any headers on my current system, so I guess it is a kernel syscall - in that case, and given that it apparently doesn't work for you with 2.6.19.1, maybe it's the include/linux headers which cause the compiler to call it with the wrong args. If so, upgrading glibc is unlikely to help, and changing include/linux under a running system is likely to break things. You also say you are trying to compile a gcc-4.0.3, but then you appear to already have a version of gcc-4.0.3, which you have use to build gcc: with gcc-4.0.3: grep Error glibc-check-log0 make[2]: [/usr/src/glibc/glibc-build/posix/annexc.out] Error 1 (ignored) make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancel17.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx4.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx5.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx16.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx17.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx20.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx21.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cleanupx4.out] Error 1 make[1]: *** [nptl/tests] Error 2 make: *** [check] Error 2 as well as a version of gcc-4.1.1: with gcc-4.1.1: grep Error glibc-check-log0 make[2]: [/usr/src/glibc/glibc-build/posix/annexc.out] Error 1 (ignored) make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancel17.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx4.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx5.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx16.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx17.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx20.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx21.out] Error 1 make[1]: *** [nptl/tests] Error 2 make[2]: *** [/usr/src/glibc/glibc-build/resolv/tst-leaks.out] Error 1 make[1]: *** [resolv/tests] Error 2 make: *** [check] Error 2 [ I've snipped the gcc test results here, because I'm getting totally confused - you only seem to have a _few_ failures, which should be no big deal ] The glibc test failures look like the sort of things we all see from time to time - search the archives and I'm sure you'll see most of these, although not necessarily so many of them together. My best advice to you is to consider if it's time to rebuild your LFS system completely. But, I'd better add that glibc-2.5 has some similar errors in the nptl tests (at least on the combinations of kernel-binutils-gcc-headers that I've tried so far). ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: tls tests fail of gcc-4.0.3 and glibc errors in nptl; what to do now?
On 07/01/07 19:40:50, Ken Moffat wrote: On Sun, Jan 07, 2007 at 07:31:16PM +0100, [EMAIL PROTECTED] wrote: Hallo! I'm trying to compile a gcc-4.0.3 to compile glibc-2.3.6 but gcc-4.0.3 tests have tls failures, see attachment test_summary01.out. I ran into problems while trying to upgrade my glibc from 2.3.3-lfs to 2.3.6 (because of x264 using sched_getaffinity() with 2 parms, glibc not beeing executable and now wine segfaulting). There I got errors (see below). Are they related to the gcc tls failures? What can I do with gcc and glibc? Can these problems be related to the kernel 2.6.19.1? My system is an LFS 5.1.1 with upgraded versions of gcc and binutils (binutils-2.15.94.0.2.2 - binutils-2.17.50.0.1) and not 2.4-kernel but 2.6.19.1. I fear that the default gcc (4.1.1) of my system had tls failures too. Thanks for any help, Lynx I'm unclear exactly what you are trying to do, or what toolchains you have available. At first, I thought 'LFS 5.1.1' was a typo for 'LFS 6.1.1', but when you mention '2.4-kernel' I'm not so sure. Thanks for the quick reply. I'm sorry my mail is not clear. I have an LFS 5.1.1 nearly three years old and pretty big, so I'm not happy with doing a new LFS if I can't use what I did in BLFS sinc then. I'm not familiar with x264 (nor multiprocessors, nor wine), but if you are intending to upgrade glibc on a running system, you have a good chance of breaking things. If you build from source, you should expect to build a new system from time to time. Well I already got some info on upgrading glibc micro versions (upgrade of libc-2.3.3.so to libc-2.3.6.so problematic? at the list). It should work if the new glibc has no errors. I can't find sched_affinity in any headers on my current system, so I guess it is a kernel syscall - in that case, and given that it apparently doesn't work for you with 2.6.19.1, maybe it's the include/linux headers which cause the compiler to call it with the wrong args. If so, upgrading glibc is unlikely to help, and changing include/linux under a running system is likely to break things. I can't say where I found the info about sched_affinity but it said that only glibc-2.3.3 had it with 3 params and newer versions with only 2 again. But this isn't a big problem at all. More the thing with wine. You also say you are trying to compile a gcc-4.0.3, but then you appear to already have a version of gcc-4.0.3, which you have use to build gcc: The error grep is from glibc-2.3.6 compilation onec done with my default gcc-4.1.1 and once with the gcc-4.0.3 in /opt with its tls failures. with gcc-4.0.3: grep Error glibc-check-log0 make[2]: [/usr/src/glibc/glibc-build/posix/annexc.out] Error 1 (ignored) make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancel17.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx4.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx5.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx16.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx17.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx20.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx21.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cleanupx4.out] Error 1 make[1]: *** [nptl/tests] Error 2 make: *** [check] Error 2 as well as a version of gcc-4.1.1: with gcc-4.1.1: grep Error glibc-check-log0 make[2]: [/usr/src/glibc/glibc-build/posix/annexc.out] Error 1 (ignored) make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancel17.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx4.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx5.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx16.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx17.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx20.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx21.out] Error 1 make[1]: *** [nptl/tests] Error 2 make[2]: *** [/usr/src/glibc/glibc-build/resolv/tst-leaks.out] Error 1 make[1]: *** [resolv/tests] Error 2 make: *** [check] Error 2 [ I've snipped the gcc test results here, because I'm getting totally confused - you only seem to have a _few_ failures, which should be no big deal ] The glibc test failures look like the sort of things we all see from time to time - search the archives and I'm sure you'll see most of these, although not necessarily so many of them together. My best advice to you is to consider if it's time to rebuild your LFS system completely. But, I'd better add that glibc-2.5 has some similar errors in the nptl tests (at least on the combinations of kernel-binutils-gcc-headers that I've tried so far). Well more
Adding emacs/erc to original install
After something like 14 years, I'm looking to change my Linux distribution for an increasingly numerous list of beefs I burned the LFS ISO and looked around somewhat and skimmed through the books What I see so far impresses me most favourably However, I am not vi literate and need to know how difficult it will be to install emacs/gnus/erc as I am heavily dependent upon the emacs appz Thanks in advance -- Regards, Slackrat [Bill Henderson] [No _4Q_ for direct email] -- Don't let Bush or Bliar take your Guns - Never Disarm -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: tls tests fail of gcc-4.0.3 and glibc errors in nptl; what to do now?
On Sun, Jan 07, 2007 at 09:05:51PM +0100, [EMAIL PROTECTED] wrote: I'm sorry my mail is not clear. I have an LFS 5.1.1 nearly three years old and pretty big, so I'm not happy with doing a new LFS if I can't use what I did in BLFS sinc then. Upgrading is the one thing we probably don't cover well in the LFS book. For a server, you can go years with only security fixes, but for a desktop (at least, for gnome and kde), a lot of things only a year old are antiquated. If you have a spare partition on a desktop, you can use what you have to build the new system, and then perhaps dual-boot between the new and old until the new desktop is finished. If you can't do that, upgrading is less convenient (or even totally painful). But, all source-built distros eventually exceed their time to live. I'm not familiar with x264 (nor multiprocessors, nor wine), but if you are intending to upgrade glibc on a running system, you have a good chance of breaking things. If you build from source, you should expect to build a new system from time to time. Well I already got some info on upgrading glibc micro versions (upgrade of libc-2.3.3.so to libc-2.3.6.so problematic? at the list). It should work if the new glibc has no errors. Sure. Personally, I wouldn't attempt it - I've seen too many problems caused by people branching out on their own and upgrading the toolchain (me included, but at least I've got enough systems to always have something that works). I can't find sched_affinity in any headers on my current system, so I guess it is a kernel syscall - in that case, and given that it apparently doesn't work for you with 2.6.19.1, maybe it's the include/linux headers which cause the compiler to call it with the wrong args. If so, upgrading glibc is unlikely to help, and changing include/linux under a running system is likely to break things. I can't say where I found the info about sched_affinity but it said that only glibc-2.3.3 had it with 3 params and newer versions with only 2 again. But this isn't a big problem at all. More the thing with wine. Well, you might do better asking on blfs-support about wine, although I doubt there are many people who use it. You also say you are trying to compile a gcc-4.0.3, but then you appear to already have a version of gcc-4.0.3, which you have use to build gcc: The error grep is from glibc-2.3.6 compilation onec done with my default gcc-4.1.1 and once with the gcc-4.0.3 in /opt with its tls failures. [...] Well more detailed parts of glibc-check-log0: GCONV_PATH=/usr/src/glibc/glibc-build/iconvdata LC_ALL=C /usr/src/glibc/glibc-build/elf/ld-linux.so.2--library-path /usr/src/glibc/glibc-build:/usr/src/glibc/glibc- build/math:/usr/src/glibc/glibc-build/elf:/usr/src/glibc/glibc- build/dlfcn:/usr/src/glibc/glibc-build/nss:/usr/src/glibc/glibc- build/nis:/usr/src/glibc/glibc-build/rt:/usr/src/glibc/glibc- build/resolv:/usr/src/glibc/glibc-build/crypt:/usr/src/glibc/glibc-build/nptl /usr/src/glibc/glibc-build/nptl/tst-cancel17/usr/src/glibc/glibc- build/nptl/tst-cancel17.out Didn't expect signal from child: got `Segmentation fault' make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancel17.out] Error 1 [...] make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx4.out] Error 1 Where as in /usr/src/glibc/glibc-build/nptl/tst-cancelx4.out and others similar: packageglibc:/usr/src/glibc/glibc-build cat /usr/src/glibc/glibc- build/nptl/tst-cancelx4.out cleanup handler not called for 'read' cleanup handler not called for 'readv' cleanup handler not called for 'select' [...] cleanup handler not called for 'msgrcv' early cancel test of 'read' successful [...] Ah, to me those results (not the segmentation fault, which might be something to worry about) look eerily similar to the sort of results I've seen from glibc-2.5 (development book). Scary, but I've not seen any problems I can blame on it. Full disclosure: I'm using athlon64s for LFS - since I moved one of them back to x86 from clfs (using the LFS-6.1 I'd initially used to build my first pure64 system) I've had a number of spontaneous reboots in LFS, now with kernel 2.6.19.1 I get what appear to be oops's (in X) although nothing ever gets to the logs - doesn't seem any _worse_ with glibc-2.5 and its nptl test failures, but who knows for sure? Ditto the second machine, which was ok with clfs-1.0.0 (x86) [ glibc-2.4 ] and 2.6.17.x but again flashes the keyboard LEDs at me from time to time on the glibc-2.5 system. The 'successful' messages are OK, it's the 'not called' which are the failures. After looking at results from glibc-2.5, I suspect the c++ compiler, or the kernel, doesn't do what the test expects. But, as with most toolchain issues, I should be regarded as 'ignorant'. And in /usr/src/glibc/glibc-build/nptl/tst-cleanupx4.out:
Re: Adding emacs/erc to original install
On Sun, Jan 07, 2007 at 09:40:57PM +0100, Slackrat wrote: However, I am not vi literate and need to know how difficult it will be to install emacs/gnus/erc as I am heavily dependent upon the emacs appz For emacs itself, see http://www.linuxfromscratch.org/blfs/view/svn/postlfs/emacs.html - I don't think gnus and erc are in blfs, so no idea about those. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Adding emacs/erc to original install
Ken Moffat [EMAIL PROTECTED] writes: On Sun, Jan 07, 2007 at 09:40:57PM +0100, Slackrat wrote: However, I am not vi literate and need to know how difficult it will be to install emacs/gnus/erc as I am heavily dependent upon the emacs appz For emacs itself, see http://www.linuxfromscratch.org/blfs/view/svn/postlfs/emacs.html - I don't think gnus and erc are in blfs, so no idea about those. Thanks - if emacs will install, gnus is packaged with emacs and erc is simply a few lisp files that need to be added plus my randomquote.el and shakespeare.el - see my full-headers -- Regards, Slackrat [Bill Henderson] [No _4Q_ for direct email] - Sovereignty over any foreign land is insecure.: - Lucius Annaeus Seneca : 4 BC-65. Roman philosopher and playwright -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
coreutils patches
I'm not sure if this is the right place to post this, but the patches I got for coreutils are generally failing to find the right files. It's not a big problem (I don't think) it just seems like the patches point to the wrong version. For instance coreutils-5.96-suppress_uptime_kill_su-1.patch looks for 'coreutils-5.94/src/Makefile.in' It asks me for the file to patch then I tell it to look for v 5.96 and all is ok. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: coreutils patches
On Monday 08 January 2007 01:36, Zeb Packard wrote: coreutils-5.96-suppress_uptime_kill_su-1.patch looks for 'coreutils-5.94/src/Makefile.in' It asks me for the file to patch then I tell it to look for v 5.96 and all is ok. On the first hand, you're right and it should be 5.96. On the other hand, when applying a patch the book uses the command like this: patch -Np1 patch-name.patch According to the man page quoted below, this means the first part of the file name including the first slash (coreutils-5.94/) will be stripped before applying the patch. So, your having an error means your doing something wrong. Particularly, you must be in the source directory to use the patch command in the way suggested in the book. man patch gives the following: MAN_BEGIN -pnum or --strip=num Strip the smallest prefix containing num leading slashes from each file name found in the patch file. A sequence of one or more adjacent slashes is counted as a single slash. This controls how file names found in the patch file are treated, in case you keep your files in a different directory than the person who sent out the patch. For example, supposing the file name in the patch file was /u/howard/src/blurfl/blurfl.c setting -p0 gives the entire file name unmodified, -p1 gives u/howard/src/blurfl/blurfl.c without the leading slash, -p4 gives blurfl/blurfl.c and not specifying -p at all just gives you blurfl.c. MAN_END -- Nothing but perfection pv -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: coreutils patches
A lot of these patches can be applied even though the version referenced in the patch is an older version. There is no sense re-inventing the wheel if the current patch works. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
tcl problem
Hi, This is my first try with the LFS project. I am stuck at the first pass (5.10 in the book) with the installation of TCL-8.4.7. I ran the test for the compiler and linker and it seems fine. I get the following output when running the configure command (./configure --prefix=/tools in the unix folder): --- loading cache ./config.cache checking whether to use symlinks for manpages... no checking compression for manpages... no checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... yes checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for building with threads... no (default) checking if the compiler understands -pipe... yes checking how to run the C preprocessor... gcc -pipe -E checking for sin... no checking for main in -lieee... yes checking for main in -linet... no checking for net/errno.h... no checking for connect... yes checking for gethostbyname... yes checking how to build libraries... shared checking for ranlib... ranlib checking if 64bit support is requested... no checking if 64bit Sparc VIS support is requested... no checking system version (for dynamic loading)... Checking system version (for dynamic loading)... ./configure: line 7163:syntax error, near unexpected token ')' ./configure: line 7163: ' OSF*)' --- Any ideas? Thanks, Yoav -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
