Re: [lfs-support] Compile error glibc2.33
On Mon, Feb 08, 2021 at 11:14:22AM +0800, xry...@mengyan1223.wang wrote: >Please help me to test my glibc workaround in this thread. If it works, >crt1.o should have no "needed" ISA markers (even x86-64-baseline should >not be there). Then we can add it as a note in the book. >If it was on binutils sid, it should be diagnosticed already in the >editors' builds. We use -march in GMP and libffi so their test suites >would immediately fail, if it was a binutils issue. >I think it's not glibc devs, just other packagers or distro maintainers >like us thought it was a binutils issue. I actually left a wrong comment >in the BZ. No way to delete it :(. >Sorry again for the bad formatting on my phone. Thanks for reminding me of that workaround, I'd lost sight of it. To quote you from upthread - | You can turn off ISA marker with "libc_cv_include_x86_isa_level=no". | Just append it to glibc configure line, like: ../configure --prefix=/usr\ --disable-werror \ --enable-kernel=3.2 \ --enable-stack-protector=strong \ --with-headers=/usr/include \ libc_cv_slibdir=/lib libc_cv_include_x86_isa_level=no I've started the native build, but the machine is slow (i3, slow DRAM) and I'm not sure it will get very far before I go to bed. My revised plan is to wait for it to fail, whether that is failign the build or failing to boot. Assuming it does fail, I'll start again with that workaround. ĸen -- Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout. -- rfc 2324 (1st April 1998) -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Compile error glibc2.33
On Mon, Feb 08, 2021 at 10:25:27AM +0800, Xi Ruoyao wrote: > On 2021-02-07 18:43 +, Ken Moffat wrote: > > On Sat, Feb 06, 2021 at 10:46:18PM +0800, Xi Ruoyao wrote: > > > On 2021-02-06 14:56 +0100, Frans de Boer wrote: > > > > > > No, the tests do not stop because I use the 'make -k' option. But can't > > > > run anything afterwards because of this error. > > > > BTW, I just tried the --with-cpu=amdfam10 to configure. It halts > > > > stating > > > > that this "subspecies" is not supported. > > > > > > > > So, it seems that the glibc dev where playing god and decided that > > > > anything less then the newest processors should have no means to exist > > > > anymore. So, I stick for now with the glib-2.32 version and continue > > > > later. > > > > Maybe someone will figure out how to get rid of this absurd ISA level > > > > check, blocking millions to billions of systems from future updates!! > > > > > > Don't assume the upstream is trying to "fight against you". > > > > > > It's now reported and the upstream is trying to find a solution: > > > https://sourceware.org/bugzilla/show_bug.cgi?id=27318 > > > > > > For now the best workaround seems "don't use -march". > > > > It's a shame that the thread on bug 27318 seems to have ground to a > > halt last Wednesday, at > > https://sourceware.org/pipermail/libc-alpha/2021-February/122280.html > > > > Quoting from Florian Weimer at the end of the thread. > > > > > It's not correct due to the way the check is implemented: failing to > > > load -march=sandybridge binaries on Sandybridge CPUs is clearly wrong. > > [...] > > > If you want checks, doing them against an incorrect ABI level that can > > > never fully match the host CPU is wrong. > > > > He then goes on to sketch an alternative approach, which sounds as > > if it will need a significant rewrite of what was posted. > > > > Earlier in the thread, > > https://sourceware.org/pipermail/libc-alpha/2021-February/122290.html > > Joeseph Myers wrote (replying to HJL) > > > > > That's bad. Since glibc supports execution on Sandy Bridge processors, > > > compilation with -march=sandybridge should (a) work, with no special > > > configure options needed and (b) produce a glibc that works on Sandy > > > Bridge, with no special configure options needed. I understand that bug > > > 27318 is reporting that (b) fails at present. We need to fix (b) without > > > breaking (a). > > > > > > This is not specific at all to x86_64. It applies to all architectures > > > and processors supported by glibc: compiling with a compiler that > > > defaults > > > to any such processor should just work, regardless of how that processor > > > relates to particular ISA levels in the glibc-hwcaps machinery. > > > > > > > We can add a configure option, --disable-isa-level, to unset > > > > INCLUDE_X86_ISA_LEVEL. The resulting libc.so doesn't have a marker > > > > and won't run on all machines. > > > > > > No special configure option should be needed for (a) and (b) to hold. > > > They are general principles for any processor supported by glibc, for any > > > architecture. > > > > > > To me, this sounds as if the current binutils releases are a severe > > regression in that what was supposed to help better optimization > > prevents use of the minimal "build for this specific variant" > > option. > > > > On LFS we do not need the new hwcapabilities (which appears to be a > > framework for letting distros ship alternate binary versions of some > > of the libs optimized for different hardware versions). > > > > I'm not entirely convinced that I'm going to use current binutils on > > my own machines if it can't use sensible -march= on the older ones. > > Hi Ken, > > Binutils (assembler "as" and linker "ld") doesn't set ISA "needed" markers by > default. It can be set using special linker option "-z x86-64-v[234]", or > assembly pesudo instructions. > > In glibc building process, crt1.o sets its ISA markers by inline assembly. > Then > its ISA marker just "propagates" to all over the system since most programs > link > to it. > > So the problem is on Glibc side, not Binutils side. Hi Xi, thanks for that - fun, fun, fun. So the glibc devs are, or were, saying that the binutils devs were doing it wrong. I'll shortly be starting a -march=native build on my skylake box, to see if that replicates the problem (that is currently my oldest usable machine). But I'm quite prepared for a throwaway build if it doesn't run. ;-) ĸen -- Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout. -- rfc 2324 (1st April 1998) -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A:
Re: [lfs-support] Compile error glibc2.33
On 2/7/21 9:52 PM, Ken Moffat wrote: On Mon, Feb 08, 2021 at 11:14:22AM +0800, xry...@mengyan1223.wang wrote: Please help me to test my glibc workaround in this thread. If it works, crt1.o should have no "needed" ISA markers (even x86-64-baseline should not be there). Then we can add it as a note in the book. If it was on binutils sid, it should be diagnosticed already in the editors' builds. We use -march in GMP and libffi so their test suites would immediately fail, if it was a binutils issue. I think it's not glibc devs, just other packagers or distro maintainers like us thought it was a binutils issue. I actually left a wrong comment in the BZ. No way to delete it :(. Sorry again for the bad formatting on my phone. Thanks for reminding me of that workaround, I'd lost sight of it. To quote you from upthread - | You can turn off ISA marker with "libc_cv_include_x86_isa_level=no". | Just append it to glibc configure line, like: ../configure --prefix=/usr\ --disable-werror \ --enable-kernel=3.2 \ --enable-stack-protector=strong \ --with-headers=/usr/include \ libc_cv_slibdir=/lib libc_cv_include_x86_isa_level=no Just a minor tweak. I had to read this closely to understand it: ../configure --prefix=/usr\ --disable-werror\ --enable-kernel=3.2 \ --enable-stack-protector=strong \ --with-headers=/usr/include \ libc_cv_slibdir=/lib\ libc_cv_include_x86_isa_level=no -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] fatal error: bits/c++config.h: No such file or directory
On Sunday, February 7, 2021 2:54:42 PM CST Paul rogers wrote:
> On Sunday, February 7, 2021 2:33:02 PM CST Pierre Labastie wrote:
> > On Sun, 2021-02-07 at 13:20 -0600, paul rogers wrote:
> > > On Sunday, February 7, 2021 12:11:09 PM CST Pierre Labastie wrote:
> > > > On Sun, 2021-02-07 at 11:26 -0600, paul rogers wrote:
> > > > > On Sunday, February 7, 2021 6:26:29 AM CST Pierre Labastie wrote:
> > > > > > On Sun, 2021-02-07 at 01:18 -0600, p...@kemascraft.com wrote:
> > > > > > > I'm working through the LFS 10.0 book. I got the error: "
> > > > > > > fatal
> > > > > > > error: bits/c+
> > > > > > > +config.h: No such file or directory". The file exist. I'm at
> > > > > > > 8.6.1. Installation of DejaGNU. and ran the "make check."
> > > > > > > command.
> > > > > > > I'm trying
> > > > > > > to install with the "User Based Management " Package
> > > > > > > Management
> > > > > > > system.
> > > > > > > Goggle didn't help much. i found a suggestion to "export
> > > > > > > CPLUS_INCLUDE_PATH=/
> > > > > > > usr/include/", but no luck. any help would be appreciated.
> > > > > >
> > > > > > Hard to say anything without a more detailed error message
> > > > > > (what
> > > > > > does
> > > > > > it say just above, what was the command that failed, not the
> > > > > > one
> > > > > > you
> > > > > > ran, but the one that "make" ran, etc).
> > > > > >
> > > > > > Using CPLUS_INCLUDE_PATH (or any include path) pointing to
> > > > > > /usr/include
> > > > > > is dangerous, because it changes the order of the include
> > > > > > directories.
> > > > > > This order is important when using the #include_next directive,
> > > > > > which
> > > > > > happens in several packages.
> > > > > >
> > > > > > Pierre
> > > > >
> > > > > this is the output of make check 1>check.log
> > > > > "Done. Now run 'make install'.
> > > > > make unit
> > > > > make[1]: Entering directory '/usr/src/dejagnu/dejagnu-1.6.2'
> > > > > depbase=`echo testsuite/libdejagnu/unit.o | sed
> > > > > 's|[^/]*$|.deps/&|;s|\.o$||'`;
> > > > > \
> > > > > g++ -DPACKAGE_NAME=\"GNU\ DejaGnu\" -DPACKAGE_TARNAME=\"dejagnu\"
> > > > > -
> > > > > DPACKAGE_VERSION=\"1.6.2\" -DPACKAGE_STRING=\"GNU\ DejaGnu\
> > > > > 1.6.2\" -
> > > > > DPACKAGE_BUGREPORT=\"bug-deja...@gnu.org\" -
> > > > > DPACKAGE_URL=\"http://www.gnu.org/
> > > > > software/dejagnu/\" -DPACKAGE=\"dejagnu\" -DVERSION=\"1.6.2\" -
> > > > > I.
> > > > > -I. -g -g
> > > > > -O2 -MT testsuite/libdejagnu/unit.o -MD -MP -MF $depbase.Tpo -c -
> > > > > o
> > > > > testsuite/
> > > > > libdejagnu/unit.o testsuite/libdejagnu/unit.cc &&\
> > > > > mv -f $depbase.Tpo $depbase.Po
> > > > > make[1]: Leaving directory '/usr/src/dejagnu/dejagnu-1.6.2'"
> > > > >
> > > > > This is the output of make check 2>check.err
> > > > > "In file included from testsuite/libdejagnu/unit.cc:21:
> > > > > /usr/include/c++/10.2.0/iostream:38:10: fatal error:
> > > > > bits/c++config.h: No such
> > > > > file or directory
> > > > >
> > > > >38 | #include
> > > > >
> > > > > | ^~
> > > > >
> > > > > compilation terminated.
> > > > > make[1]: *** [Makefile:656: testsuite/libdejagnu/unit.o] Error 1
> > > > > make: *** [Makefile:1202: check-am] Error 2"
> > > > >
> > > > > Thank you for your time Pierre.
> > > >
> > > > Ok, so this is in an include, so no "include_next" wizardry. On my
> > > > machine, this file is at /usr/include/c++/10.2.0/x86_64-pc-linux-
> > > > gnu/bits/c++config.h
> > > >
> > > > Do you have it? Is it readable by the user that runs the dejagnu
> > > > tests?
> > > > What is the output of "echo main'(){}' | g++ -xc++ --verbose -"
> > > > (the
> > > > lines after "#include "..." search starts here)?
> > > >
> > > > I have:
> > > > #include "..." search starts here:
> > > >
> > > > #include <...> search starts here:
> > > > /usr/lib/gcc/x86_64-pc-linux-
> > > >
> > > > gnu/10.2.0/../../../../include/c++/10.2.0
> > > >
> > > > /usr/lib/gcc/x86_64-pc-linux-
> > > >
> > > > gnu/10.2.0/../../../../include/c++/10.2.0/x86_64-pc-linux-gnu
> > > >
> > > > /usr/lib/gcc/x86_64-pc-linux-
> > > >
> > > > gnu/10.2.0/../../../../include/c++/10.2.0/backward
> > > >
> > > > /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include
> > > > /usr/local/include
> > > > /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include-fixed
> > > > /usr/include
> > > >
> > > > End of search list.
> > > >
> > > > Pierre
> > >
> > > Your file /usr/include/c++/10.2.0/x86_64-pc-linux-
> > > gnu/bits/c++config.h
> > > Mine is /usr/include/c++/10.2.0/x86_64-lfs-linux-
> > > gnu/bits/c++config.h
> > >
> > > #include "..." search starts here:
> > >
> > > #include <...> search starts here:
> > > /usr/lib/gcc/x86_64-pc-linux-
> > >
> > > gnu/10.2.0/../../../../include/c++/10.2.0
> > >
> > > /usr/lib/gcc/x86_64-pc-linux-
> > >
> > > gnu/10.2.0/../../../../include/c++/10.2.0/
> > > backward
> > >
> > > /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include
> > > /usr/local/include
> > > /usr/l
Re: [lfs-support] Compile error glibc2.33
Please help me to test my glibc workaround in this thread. If it works, crt1.o should have no "needed" ISA markers (even x86-64-baseline should not be there). Then we can add it as a note in the book. If it was on binutils sid, it should be diagnosticed already in the editors' builds. We use -march in GMP and libffi so their test suites would immediately fail, if it was a binutils issue.I think it's not glibc devs, just other packagers or distro maintainers like us thought it was a binutils issue. I actually left a wrong comment in the BZ. No way to delete it :(. Sorry again for the bad formatting on my phone. -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Compile error glibc2.33
On 2021-02-07 18:43 +, Ken Moffat wrote: > On Sat, Feb 06, 2021 at 10:46:18PM +0800, Xi Ruoyao wrote: > > On 2021-02-06 14:56 +0100, Frans de Boer wrote: > > > > No, the tests do not stop because I use the 'make -k' option. But can't > > > run anything afterwards because of this error. > > > BTW, I just tried the --with-cpu=amdfam10 to configure. It halts stating > > > that this "subspecies" is not supported. > > > > > > So, it seems that the glibc dev where playing god and decided that > > > anything less then the newest processors should have no means to exist > > > anymore. So, I stick for now with the glib-2.32 version and continue > > > later. > > > Maybe someone will figure out how to get rid of this absurd ISA level > > > check, blocking millions to billions of systems from future updates!! > > > > Don't assume the upstream is trying to "fight against you". > > > > It's now reported and the upstream is trying to find a solution: > > https://sourceware.org/bugzilla/show_bug.cgi?id=27318 > > > > For now the best workaround seems "don't use -march". > > It's a shame that the thread on bug 27318 seems to have ground to a > halt last Wednesday, at > https://sourceware.org/pipermail/libc-alpha/2021-February/122280.html > > Quoting from Florian Weimer at the end of the thread. > > > It's not correct due to the way the check is implemented: failing to > > load -march=sandybridge binaries on Sandybridge CPUs is clearly wrong. > [...] > > If you want checks, doing them against an incorrect ABI level that can > > never fully match the host CPU is wrong. > > He then goes on to sketch an alternative approach, which sounds as > if it will need a significant rewrite of what was posted. > > Earlier in the thread, > https://sourceware.org/pipermail/libc-alpha/2021-February/122290.html > Joeseph Myers wrote (replying to HJL) > > > That's bad. Since glibc supports execution on Sandy Bridge processors, > > compilation with -march=sandybridge should (a) work, with no special > > configure options needed and (b) produce a glibc that works on Sandy > > Bridge, with no special configure options needed. I understand that bug > > 27318 is reporting that (b) fails at present. We need to fix (b) without > > breaking (a). > > > > This is not specific at all to x86_64. It applies to all architectures > > and processors supported by glibc: compiling with a compiler that defaults > > to any such processor should just work, regardless of how that processor > > relates to particular ISA levels in the glibc-hwcaps machinery. > > > > > We can add a configure option, --disable-isa-level, to unset > > > INCLUDE_X86_ISA_LEVEL. The resulting libc.so doesn't have a marker > > > and won't run on all machines. > > > > No special configure option should be needed for (a) and (b) to hold. > > They are general principles for any processor supported by glibc, for any > > architecture. > > > To me, this sounds as if the current binutils releases are a severe > regression in that what was supposed to help better optimization > prevents use of the minimal "build for this specific variant" > option. > > On LFS we do not need the new hwcapabilities (which appears to be a > framework for letting distros ship alternate binary versions of some > of the libs optimized for different hardware versions). > > I'm not entirely convinced that I'm going to use current binutils on > my own machines if it can't use sensible -march= on the older ones. Hi Ken, Binutils (assembler "as" and linker "ld") doesn't set ISA "needed" markers by default. It can be set using special linker option "-z x86-64-v[234]", or assembly pesudo instructions. In glibc building process, crt1.o sets its ISA markers by inline assembly. Then its ISA marker just "propagates" to all over the system since most programs link to it. So the problem is on Glibc side, not Binutils side. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Compile error glibc2.33
On Sat, Feb 06, 2021 at 10:46:18PM +0800, Xi Ruoyao wrote: > On 2021-02-06 14:56 +0100, Frans de Boer wrote: > > No, the tests do not stop because I use the 'make -k' option. But can't > > run anything afterwards because of this error. > > BTW, I just tried the --with-cpu=amdfam10 to configure. It halts stating > > that this "subspecies" is not supported. > > > > So, it seems that the glibc dev where playing god and decided that > > anything less then the newest processors should have no means to exist > > anymore. So, I stick for now with the glib-2.32 version and continue later. > > Maybe someone will figure out how to get rid of this absurd ISA level > > check, blocking millions to billions of systems from future updates!! > > Don't assume the upstream is trying to "fight against you". > > It's now reported and the upstream is trying to find a solution: > https://sourceware.org/bugzilla/show_bug.cgi?id=27318 > > For now the best workaround seems "don't use -march". It's a shame that the thread on bug 27318 seems to have ground to a halt last Wednesday, at https://sourceware.org/pipermail/libc-alpha/2021-February/122280.html Quoting from Florian Weimer at the end of the thread. | It's not correct due to the way the check is implemented: failing to | load -march=sandybridge binaries on Sandybridge CPUs is clearly wrong. [...] | If you want checks, doing them against an incorrect ABI level that can | never fully match the host CPU is wrong. He then goes on to sketch an alternative approach, which sounds as if it will need a significant rewrite of what was posted. Earlier in the thread, https://sourceware.org/pipermail/libc-alpha/2021-February/122290.html Joeseph Myers wrote (replying to HJL) | That's bad. Since glibc supports execution on Sandy Bridge processors, | compilation with -march=sandybridge should (a) work, with no special | configure options needed and (b) produce a glibc that works on Sandy | Bridge, with no special configure options needed. I understand that bug | 27318 is reporting that (b) fails at present. We need to fix (b) without | breaking (a). | | This is not specific at all to x86_64. It applies to all architectures | and processors supported by glibc: compiling with a compiler that defaults | to any such processor should just work, regardless of how that processor | relates to particular ISA levels in the glibc-hwcaps machinery. | | > We can add a configure option, --disable-isa-level, to unset | > INCLUDE_X86_ISA_LEVEL. The resulting libc.so doesn't have a marker | > and won't run on all machines. | | No special configure option should be needed for (a) and (b) to hold. | They are general principles for any processor supported by glibc, for any | architecture. To me, this sounds as if the current binutils releases are a severe regression in that what was supposed to help better optimization prevents use of the minimal "build for this specific variant" option. On LFS we do not need the new hwcapabilities (which appears to be a framework for letting distros ship alternate binary versions of some of the libs optimized for different hardware versions). I'm not entirely convinced that I'm going to use current binutils on my own machines if it can't use sensible -march= on the older ones. ĸen -- Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout. -- rfc 2324 (1st April 1998) -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] fatal error: bits/c++config.h: No such file or directory
On Sunday, February 7, 2021 2:33:02 PM CST Pierre Labastie wrote:
> On Sun, 2021-02-07 at 13:20 -0600, paul rogers wrote:
> > On Sunday, February 7, 2021 12:11:09 PM CST Pierre Labastie wrote:
> > > On Sun, 2021-02-07 at 11:26 -0600, paul rogers wrote:
> > > > On Sunday, February 7, 2021 6:26:29 AM CST Pierre Labastie wrote:
> > > > > On Sun, 2021-02-07 at 01:18 -0600, p...@kemascraft.com wrote:
> > > > > > I'm working through the LFS 10.0 book. I got the error: "
> > > > > > fatal
> > > > > > error: bits/c+
> > > > > > +config.h: No such file or directory". The file exist. I'm at
> > > > > > 8.6.1. Installation of DejaGNU. and ran the "make check."
> > > > > > command.
> > > > > > I'm trying
> > > > > > to install with the "User Based Management " Package
> > > > > > Management
> > > > > > system.
> > > > > > Goggle didn't help much. i found a suggestion to "export
> > > > > > CPLUS_INCLUDE_PATH=/
> > > > > > usr/include/", but no luck. any help would be appreciated.
> > > > >
> > > > > Hard to say anything without a more detailed error message
> > > > > (what
> > > > > does
> > > > > it say just above, what was the command that failed, not the
> > > > > one
> > > > > you
> > > > > ran, but the one that "make" ran, etc).
> > > > >
> > > > > Using CPLUS_INCLUDE_PATH (or any include path) pointing to
> > > > > /usr/include
> > > > > is dangerous, because it changes the order of the include
> > > > > directories.
> > > > > This order is important when using the #include_next directive,
> > > > > which
> > > > > happens in several packages.
> > > > >
> > > > > Pierre
> > > >
> > > > this is the output of make check 1>check.log
> > > > "Done. Now run 'make install'.
> > > > make unit
> > > > make[1]: Entering directory '/usr/src/dejagnu/dejagnu-1.6.2'
> > > > depbase=`echo testsuite/libdejagnu/unit.o | sed
> > > > 's|[^/]*$|.deps/&|;s|\.o$||'`;
> > > > \
> > > > g++ -DPACKAGE_NAME=\"GNU\ DejaGnu\" -DPACKAGE_TARNAME=\"dejagnu\"
> > > > -
> > > > DPACKAGE_VERSION=\"1.6.2\" -DPACKAGE_STRING=\"GNU\ DejaGnu\
> > > > 1.6.2\" -
> > > > DPACKAGE_BUGREPORT=\"bug-deja...@gnu.org\" -
> > > > DPACKAGE_URL=\"http://www.gnu.org/
> > > > software/dejagnu/\" -DPACKAGE=\"dejagnu\" -DVERSION=\"1.6.2\" -
> > > > I.
> > > > -I. -g -g
> > > > -O2 -MT testsuite/libdejagnu/unit.o -MD -MP -MF $depbase.Tpo -c -
> > > > o
> > > > testsuite/
> > > > libdejagnu/unit.o testsuite/libdejagnu/unit.cc &&\
> > > > mv -f $depbase.Tpo $depbase.Po
> > > > make[1]: Leaving directory '/usr/src/dejagnu/dejagnu-1.6.2'"
> > > >
> > > > This is the output of make check 2>check.err
> > > > "In file included from testsuite/libdejagnu/unit.cc:21:
> > > > /usr/include/c++/10.2.0/iostream:38:10: fatal error:
> > > > bits/c++config.h: No such
> > > > file or directory
> > > >38 | #include
> > > > | ^~
> > > > compilation terminated.
> > > > make[1]: *** [Makefile:656: testsuite/libdejagnu/unit.o] Error 1
> > > > make: *** [Makefile:1202: check-am] Error 2"
> > > >
> > > > Thank you for your time Pierre.
> > >
> > > Ok, so this is in an include, so no "include_next" wizardry. On my
> > > machine, this file is at /usr/include/c++/10.2.0/x86_64-pc-linux-
> > > gnu/bits/c++config.h
> > >
> > > Do you have it? Is it readable by the user that runs the dejagnu
> > > tests?
> > > What is the output of "echo main'(){}' | g++ -xc++ --verbose -"
> > > (the
> > > lines after "#include "..." search starts here)?
> > >
> > > I have:
> > > #include "..." search starts here:
> > > #include <...> search starts here:
> > > /usr/lib/gcc/x86_64-pc-linux-
> > > gnu/10.2.0/../../../../include/c++/10.2.0
> > > /usr/lib/gcc/x86_64-pc-linux-
> > > gnu/10.2.0/../../../../include/c++/10.2.0/x86_64-pc-linux-gnu
> > > /usr/lib/gcc/x86_64-pc-linux-
> > > gnu/10.2.0/../../../../include/c++/10.2.0/backward
> > > /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include
> > > /usr/local/include
> > > /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include-fixed
> > > /usr/include
> > > End of search list.
> > >
> > > Pierre
> >
> > Your file /usr/include/c++/10.2.0/x86_64-pc-linux-
> > gnu/bits/c++config.h
> > Mine is /usr/include/c++/10.2.0/x86_64-lfs-linux-
> > gnu/bits/c++config.h
> >
> > #include "..." search starts here:
> > #include <...> search starts here:
> > /usr/lib/gcc/x86_64-pc-linux-
> > gnu/10.2.0/../../../../include/c++/10.2.0
> > /usr/lib/gcc/x86_64-pc-linux-
> > gnu/10.2.0/../../../../include/c++/10.2.0/
> > backward
> > /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include
> > /usr/local/include
> > /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include-fixed
> > /usr/include
> >
> > So it looks like its looking for x86_64-pc-linux-gnu instead of
> > x86_64-lfs-
> > linux. so whats the best solution? Did i miss a command some where?
>
> Well, first I must apologize, I've shown the includes on a completed
> system, they might be different before recompiling gcc in chapter 8.
>
> Second, /usr/include/c++/10.2.0/x86_64-lfs-linux-gnu/bits/
Re: [lfs-support] fatal error: bits/c++config.h: No such file or directory
On Sun, 2021-02-07 at 13:20 -0600, paul rogers wrote:
> On Sunday, February 7, 2021 12:11:09 PM CST Pierre Labastie wrote:
> > On Sun, 2021-02-07 at 11:26 -0600, paul rogers wrote:
> > > On Sunday, February 7, 2021 6:26:29 AM CST Pierre Labastie wrote:
> > > > On Sun, 2021-02-07 at 01:18 -0600, p...@kemascraft.com wrote:
> > > > > I'm working through the LFS 10.0 book. I got the error: "
> > > > > fatal
> > > > > error: bits/c+
> > > > > +config.h: No such file or directory". The file exist. I'm at
> > > > > 8.6.1. Installation of DejaGNU. and ran the "make check."
> > > > > command.
> > > > > I'm trying
> > > > > to install with the "User Based Management " Package
> > > > > Management
> > > > > system.
> > > > > Goggle didn't help much. i found a suggestion to "export
> > > > > CPLUS_INCLUDE_PATH=/
> > > > > usr/include/", but no luck. any help would be appreciated.
> > > >
> > > > Hard to say anything without a more detailed error message
> > > > (what
> > > > does
> > > > it say just above, what was the command that failed, not the
> > > > one
> > > > you
> > > > ran, but the one that "make" ran, etc).
> > > >
> > > > Using CPLUS_INCLUDE_PATH (or any include path) pointing to
> > > > /usr/include
> > > > is dangerous, because it changes the order of the include
> > > > directories.
> > > > This order is important when using the #include_next directive,
> > > > which
> > > > happens in several packages.
> > > >
> > > > Pierre
> > >
> > > this is the output of make check 1>check.log
> > > "Done. Now run 'make install'.
> > > make unit
> > > make[1]: Entering directory '/usr/src/dejagnu/dejagnu-1.6.2'
> > > depbase=`echo testsuite/libdejagnu/unit.o | sed
> > > 's|[^/]*$|.deps/&|;s|\.o$||'`;
> > > \
> > > g++ -DPACKAGE_NAME=\"GNU\ DejaGnu\" -DPACKAGE_TARNAME=\"dejagnu\"
> > > -
> > > DPACKAGE_VERSION=\"1.6.2\" -DPACKAGE_STRING=\"GNU\ DejaGnu\
> > > 1.6.2\" -
> > > DPACKAGE_BUGREPORT=\"bug-deja...@gnu.org\" -
> > > DPACKAGE_URL=\"http://www.gnu.org/
> > > software/dejagnu/\" -DPACKAGE=\"dejagnu\" -DVERSION=\"1.6.2\" -
> > > I.
> > > -I. -g -g
> > > -O2 -MT testsuite/libdejagnu/unit.o -MD -MP -MF $depbase.Tpo -c -
> > > o
> > > testsuite/
> > > libdejagnu/unit.o testsuite/libdejagnu/unit.cc &&\
> > > mv -f $depbase.Tpo $depbase.Po
> > > make[1]: Leaving directory '/usr/src/dejagnu/dejagnu-1.6.2'"
> > >
> > > This is the output of make check 2>check.err
> > > "In file included from testsuite/libdejagnu/unit.cc:21:
> > > /usr/include/c++/10.2.0/iostream:38:10: fatal error:
> > > bits/c++config.h: No such
> > > file or directory
> > > 38 | #include
> > > | ^~
> > > compilation terminated.
> > > make[1]: *** [Makefile:656: testsuite/libdejagnu/unit.o] Error 1
> > > make: *** [Makefile:1202: check-am] Error 2"
> > >
> > > Thank you for your time Pierre.
> >
> > Ok, so this is in an include, so no "include_next" wizardry. On my
> > machine, this file is at /usr/include/c++/10.2.0/x86_64-pc-linux-
> > gnu/bits/c++config.h
> >
> > Do you have it? Is it readable by the user that runs the dejagnu
> > tests?
> > What is the output of "echo main'(){}' | g++ -xc++ --verbose -"
> > (the
> > lines after "#include "..." search starts here)?
> >
> > I have:
> > #include "..." search starts here:
> > #include <...> search starts here:
> > /usr/lib/gcc/x86_64-pc-linux-
> > gnu/10.2.0/../../../../include/c++/10.2.0
> > /usr/lib/gcc/x86_64-pc-linux-
> > gnu/10.2.0/../../../../include/c++/10.2.0/x86_64-pc-linux-gnu
> > /usr/lib/gcc/x86_64-pc-linux-
> > gnu/10.2.0/../../../../include/c++/10.2.0/backward
> > /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include
> > /usr/local/include
> > /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include-fixed
> > /usr/include
> > End of search list.
> >
> > Pierre
> Your file /usr/include/c++/10.2.0/x86_64-pc-linux-
> gnu/bits/c++config.h
> Mine is /usr/include/c++/10.2.0/x86_64-lfs-linux-
> gnu/bits/c++config.h
>
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/lib/gcc/x86_64-pc-linux-
> gnu/10.2.0/../../../../include/c++/10.2.0
> /usr/lib/gcc/x86_64-pc-linux-
> gnu/10.2.0/../../../../include/c++/10.2.0/
> backward
> /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include
> /usr/local/include
> /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include-fixed
> /usr/include
>
> So it looks like its looking for x86_64-pc-linux-gnu instead of
> x86_64-lfs-
> linux. so whats the best solution? Did i miss a command some where?
>
Well, first I must apologize, I've shown the includes on a completed
system, they might be different before recompiling gcc in chapter 8.
Second, /usr/include/c++/10.2.0/x86_64-lfs-linux-gnu/bits/c++config.h
is not in the search list, and not even replacing lfs with pc (it's not
in a subdirectory of /usr/lib), so there must be something missing...
Wild guess, have you run "make install" at the end of libstdc++-pass2?
I need to launch a build and stop just before dejagnu to be able to
check what the includ
Re: [lfs-support] fatal error: bits/c++config.h: No such file or directory
On Sunday, February 7, 2021 12:11:09 PM CST Pierre Labastie wrote:
> On Sun, 2021-02-07 at 11:26 -0600, paul rogers wrote:
> > On Sunday, February 7, 2021 6:26:29 AM CST Pierre Labastie wrote:
> > > On Sun, 2021-02-07 at 01:18 -0600, p...@kemascraft.com wrote:
> > > > I'm working through the LFS 10.0 book. I got the error: " fatal
> > > > error: bits/c+
> > > > +config.h: No such file or directory". The file exist. I'm at
> > > > 8.6.1. Installation of DejaGNU. and ran the "make check."
> > > > command.
> > > > I'm trying
> > > > to install with the "User Based Management " Package Management
> > > > system.
> > > > Goggle didn't help much. i found a suggestion to "export
> > > > CPLUS_INCLUDE_PATH=/
> > > > usr/include/", but no luck. any help would be appreciated.
> > >
> > > Hard to say anything without a more detailed error message (what
> > > does
> > > it say just above, what was the command that failed, not the one
> > > you
> > > ran, but the one that "make" ran, etc).
> > >
> > > Using CPLUS_INCLUDE_PATH (or any include path) pointing to
> > > /usr/include
> > > is dangerous, because it changes the order of the include
> > > directories.
> > > This order is important when using the #include_next directive,
> > > which
> > > happens in several packages.
> > >
> > > Pierre
> >
> > this is the output of make check 1>check.log
> > "Done. Now run 'make install'.
> > make unit
> > make[1]: Entering directory '/usr/src/dejagnu/dejagnu-1.6.2'
> > depbase=`echo testsuite/libdejagnu/unit.o | sed
> > 's|[^/]*$|.deps/&|;s|\.o$||'`;
> > \
> > g++ -DPACKAGE_NAME=\"GNU\ DejaGnu\" -DPACKAGE_TARNAME=\"dejagnu\" -
> > DPACKAGE_VERSION=\"1.6.2\" -DPACKAGE_STRING=\"GNU\ DejaGnu\ 1.6.2\" -
> > DPACKAGE_BUGREPORT=\"bug-deja...@gnu.org\" -
> > DPACKAGE_URL=\"http://www.gnu.org/
> > software/dejagnu/\" -DPACKAGE=\"dejagnu\" -DVERSION=\"1.6.2\" -I.
> > -I. -g -g
> > -O2 -MT testsuite/libdejagnu/unit.o -MD -MP -MF $depbase.Tpo -c -o
> > testsuite/
> > libdejagnu/unit.o testsuite/libdejagnu/unit.cc &&\
> > mv -f $depbase.Tpo $depbase.Po
> > make[1]: Leaving directory '/usr/src/dejagnu/dejagnu-1.6.2'"
> >
> > This is the output of make check 2>check.err
> > "In file included from testsuite/libdejagnu/unit.cc:21:
> > /usr/include/c++/10.2.0/iostream:38:10: fatal error:
> > bits/c++config.h: No such
> > file or directory
> >38 | #include
> > | ^~
> > compilation terminated.
> > make[1]: *** [Makefile:656: testsuite/libdejagnu/unit.o] Error 1
> > make: *** [Makefile:1202: check-am] Error 2"
> >
> > Thank you for your time Pierre.
>
> Ok, so this is in an include, so no "include_next" wizardry. On my
> machine, this file is at /usr/include/c++/10.2.0/x86_64-pc-linux-
> gnu/bits/c++config.h
>
> Do you have it? Is it readable by the user that runs the dejagnu tests?
> What is the output of "echo main'(){}' | g++ -xc++ --verbose -" (the
> lines after "#include "..." search starts here)?
>
> I have:
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0
> /usr/lib/gcc/x86_64-pc-linux-
> gnu/10.2.0/../../../../include/c++/10.2.0/x86_64-pc-linux-gnu
> /usr/lib/gcc/x86_64-pc-linux-
> gnu/10.2.0/../../../../include/c++/10.2.0/backward
> /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include
> /usr/local/include
> /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include-fixed
> /usr/include
> End of search list.
>
> Pierre
Your file /usr/include/c++/10.2.0/x86_64-pc-linux-gnu/bits/c++config.h
Mine is /usr/include/c++/10.2.0/x86_64-lfs-linux-gnu/bits/c++config.h
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/
backward
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include-fixed
/usr/include
So it looks like its looking for x86_64-pc-linux-gnu instead of x86_64-lfs-
linux. so whats the best solution? Did i miss a command some where?
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Problem with grub and patch to dev.
On 07/02/2021 18:19, Bruce Dubbs wrote: On 2/7/21 8:11 AM, Pierre Labastie wrote: On Sun, 2021-02-07 at 14:15 +0100, Pierre Labastie wrote: On Sun, 2021-02-07 at 13:38 +0100, Frans de Boer wrote: LS, Finally had a change to finish the LFS build. Alas, the grub- install reported the old error "Decompression is too big". Here is the solution to add to the section to compile grub: # Patch gentpl.py to avoid an error from grub-mkinstall "Decompressor is too big" # Source: https://www.mail-archive.com/grub-devel@gnu.org/msg29840.html # sed -i -E "s@(.*-R .note.gnu.gold-version -R)(.*)@\1 .note.gnu.property -R\2@" gentpl.py ln -fs /usr/bin/python3 /usr/bin/python # grub needs 'python' ./autogen.sh rm -f /usr/bin/python Very interesting, thanks! There are several hundreds of commits in grub repositories since the last release. I hope we'll see a release soon... For us, instead of running autogen, can't the generated file be patched directly? I looks like gentpl.py generates Makefile.*.am, and my guess is that this ends up in Makefile.*.in after running autofu... Will look more closely Yes this can be simplified to (sorry for format, need to fit into 80 chars per line): sed -i -E \ "s@(.*-R .note.gnu.gold-version -R)(.*)@\1 .note.gnu.property -R\2@" \ Makefile.in grub-core/Makefile.in I think it can be made shorter: "/(version -R)/s/\1 .note.gnu.property -R/" But not tested. -- Bruce before running configure. Results: - without the sed, after make: -- $ ls -l grub-core/lzma* -rwxr-xr-x 1 pierre pierre 4972 7 févr. 15:01 grub- core/lzma_decompress.image -rwxr-xr-x 1 pierre pierre 134479612 7 févr. 15:01 grub- core/lzma_decompress.img -- - with the sed, after make: -- $ ls -l grub-core/lzma* -rwxr-xr-x 1 pierre pierre 4972 7 févr. 15:09 grub- core/lzma_decompress.image -rwxr-xr-x 1 pierre pierre 2848 7 févr. 15:09 grub- core/lzma_decompress.img -- If nobody speaks up, will add that tomorrow to grub page. Pierre Pierre has a one line solution devised to be applied to the recipient file: Can be further simplified to: sed -e 's/\.note\.gnu\.gold-version/& -R .note.gnu.property/' \ -i Makefile.in grub-core/Makefile.in Just before configure (no need to run autogen, nor to relink python) It works too and is confirmed by at least two people ;) BTW: the sed -e ... can be changed to sed The -e is only required when there is more then one command to be executed by sed. --- Frans. -- A: Yes, just like thatA: Ja, net zo Q: Oh, Just like reading a book backwards Q: Oh, net als een boek achterstevoren lezen A: Because it upsets the natural flow of a story A: Omdat het de natuurlijke gang uit het verhaal haalt Q: Why is top-posting annoying? Q: Waarom is Top-posting zo irritant? -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] fatal error: bits/c++config.h: No such file or directory
On Sun, 2021-02-07 at 11:26 -0600, paul rogers wrote:
> On Sunday, February 7, 2021 6:26:29 AM CST Pierre Labastie wrote:
> > On Sun, 2021-02-07 at 01:18 -0600, p...@kemascraft.com wrote:
> > > I'm working through the LFS 10.0 book. I got the error: " fatal
> > > error: bits/c+
> > > +config.h: No such file or directory". The file exist. I'm at
> > > 8.6.1. Installation of DejaGNU. and ran the "make check."
> > > command.
> > > I'm trying
> > > to install with the "User Based Management " Package Management
> > > system.
> > > Goggle didn't help much. i found a suggestion to "export
> > > CPLUS_INCLUDE_PATH=/
> > > usr/include/", but no luck. any help would be appreciated.
> >
> > Hard to say anything without a more detailed error message (what
> > does
> > it say just above, what was the command that failed, not the one
> > you
> > ran, but the one that "make" ran, etc).
> >
> > Using CPLUS_INCLUDE_PATH (or any include path) pointing to
> > /usr/include
> > is dangerous, because it changes the order of the include
> > directories.
> > This order is important when using the #include_next directive,
> > which
> > happens in several packages.
> >
> > Pierre
> this is the output of make check 1>check.log
> "Done. Now run 'make install'.
> make unit
> make[1]: Entering directory '/usr/src/dejagnu/dejagnu-1.6.2'
> depbase=`echo testsuite/libdejagnu/unit.o | sed
> 's|[^/]*$|.deps/&|;s|\.o$||'`;
> \
> g++ -DPACKAGE_NAME=\"GNU\ DejaGnu\" -DPACKAGE_TARNAME=\"dejagnu\" -
> DPACKAGE_VERSION=\"1.6.2\" -DPACKAGE_STRING=\"GNU\ DejaGnu\ 1.6.2\" -
> DPACKAGE_BUGREPORT=\"bug-deja...@gnu.org\" -
> DPACKAGE_URL=\"http://www.gnu.org/
> software/dejagnu/\" -DPACKAGE=\"dejagnu\" -DVERSION=\"1.6.2\" -I.
> -I. -g -g
> -O2 -MT testsuite/libdejagnu/unit.o -MD -MP -MF $depbase.Tpo -c -o
> testsuite/
> libdejagnu/unit.o testsuite/libdejagnu/unit.cc &&\
> mv -f $depbase.Tpo $depbase.Po
> make[1]: Leaving directory '/usr/src/dejagnu/dejagnu-1.6.2'"
>
> This is the output of make check 2>check.err
> "In file included from testsuite/libdejagnu/unit.cc:21:
> /usr/include/c++/10.2.0/iostream:38:10: fatal error:
> bits/c++config.h: No such
> file or directory
> 38 | #include
> | ^~
> compilation terminated.
> make[1]: *** [Makefile:656: testsuite/libdejagnu/unit.o] Error 1
> make: *** [Makefile:1202: check-am] Error 2"
>
> Thank you for your time Pierre.
>
Ok, so this is in an include, so no "include_next" wizardry. On my
machine, this file is at /usr/include/c++/10.2.0/x86_64-pc-linux-
gnu/bits/c++config.h
Do you have it? Is it readable by the user that runs the dejagnu tests?
What is the output of "echo main'(){}' | g++ -xc++ --verbose -" (the
lines after "#include "..." search starts here)?
I have:
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0
/usr/lib/gcc/x86_64-pc-linux-
gnu/10.2.0/../../../../include/c++/10.2.0/x86_64-pc-linux-gnu
/usr/lib/gcc/x86_64-pc-linux-
gnu/10.2.0/../../../../include/c++/10.2.0/backward
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include-fixed
/usr/include
End of search list.
Pierre
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] fatal error: bits/c++config.h: No such file or directory
On Sunday, February 7, 2021 6:26:29 AM CST Pierre Labastie wrote: > On Sun, 2021-02-07 at 01:18 -0600, p...@kemascraft.com wrote: > > I'm working through the LFS 10.0 book. I got the error: " fatal > > error: bits/c+ > > +config.h: No such file or directory". The file exist. I'm at > > 8.6.1. Installation of DejaGNU. and ran the "make check." command. > > I'm trying > > to install with the "User Based Management " Package Management > > system. > > Goggle didn't help much. i found a suggestion to "export > > CPLUS_INCLUDE_PATH=/ > > usr/include/", but no luck. any help would be appreciated. > > Hard to say anything without a more detailed error message (what does > it say just above, what was the command that failed, not the one you > ran, but the one that "make" ran, etc). > > Using CPLUS_INCLUDE_PATH (or any include path) pointing to /usr/include > is dangerous, because it changes the order of the include directories. > This order is important when using the #include_next directive, which > happens in several packages. > > Pierre this is the output of make check 1>check.log "Done. Now run 'make install'. make unit make[1]: Entering directory '/usr/src/dejagnu/dejagnu-1.6.2' depbase=`echo testsuite/libdejagnu/unit.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; \ g++ -DPACKAGE_NAME=\"GNU\ DejaGnu\" -DPACKAGE_TARNAME=\"dejagnu\" - DPACKAGE_VERSION=\"1.6.2\" -DPACKAGE_STRING=\"GNU\ DejaGnu\ 1.6.2\" - DPACKAGE_BUGREPORT=\"bug-deja...@gnu.org\" -DPACKAGE_URL=\"http://www.gnu.org/ software/dejagnu/\" -DPACKAGE=\"dejagnu\" -DVERSION=\"1.6.2\" -I.-I. -g -g -O2 -MT testsuite/libdejagnu/unit.o -MD -MP -MF $depbase.Tpo -c -o testsuite/ libdejagnu/unit.o testsuite/libdejagnu/unit.cc &&\ mv -f $depbase.Tpo $depbase.Po make[1]: Leaving directory '/usr/src/dejagnu/dejagnu-1.6.2'" This is the output of make check 2>check.err "In file included from testsuite/libdejagnu/unit.cc:21: /usr/include/c++/10.2.0/iostream:38:10: fatal error: bits/c++config.h: No such file or directory 38 | #include | ^~ compilation terminated. make[1]: *** [Makefile:656: testsuite/libdejagnu/unit.o] Error 1 make: *** [Makefile:1202: check-am] Error 2" Thank you for your time Pierre. -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Problem with grub and patch to dev.
On 2/7/21 8:11 AM, Pierre Labastie wrote: On Sun, 2021-02-07 at 14:15 +0100, Pierre Labastie wrote: On Sun, 2021-02-07 at 13:38 +0100, Frans de Boer wrote: LS, Finally had a change to finish the LFS build. Alas, the grub- install reported the old error "Decompression is too big". Here is the solution to add to the section to compile grub: # Patch gentpl.py to avoid an error from grub-mkinstall "Decompressor is too big" # Source: https://www.mail-archive.com/grub-devel@gnu.org/msg29840.html # sed -i -E "s@(.*-R .note.gnu.gold-version -R)(.*)@\1 .note.gnu.property -R\2@" gentpl.py ln -fs /usr/bin/python3 /usr/bin/python # grub needs 'python' ./autogen.sh rm -f /usr/bin/python Very interesting, thanks! There are several hundreds of commits in grub repositories since the last release. I hope we'll see a release soon... For us, instead of running autogen, can't the generated file be patched directly? I looks like gentpl.py generates Makefile.*.am, and my guess is that this ends up in Makefile.*.in after running autofu... Will look more closely Yes this can be simplified to (sorry for format, need to fit into 80 chars per line): sed -i -E \ "s@(.*-R .note.gnu.gold-version -R)(.*)@\1 .note.gnu.property -R\2@" \ Makefile.in grub-core/Makefile.in I think it can be made shorter: "/(version -R)/s/\1 .note.gnu.property -R/" But not tested. -- Bruce before running configure. Results: - without the sed, after make: -- $ ls -l grub-core/lzma* -rwxr-xr-x 1 pierre pierre 4972 7 févr. 15:01 grub- core/lzma_decompress.image -rwxr-xr-x 1 pierre pierre 134479612 7 févr. 15:01 grub- core/lzma_decompress.img -- - with the sed, after make: -- $ ls -l grub-core/lzma* -rwxr-xr-x 1 pierre pierre 4972 7 févr. 15:09 grub- core/lzma_decompress.image -rwxr-xr-x 1 pierre pierre 2848 7 févr. 15:09 grub- core/lzma_decompress.img -- If nobody speaks up, will add that tomorrow to grub page. Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Problem with grub and patch to dev.
On 2/7/21 7:15 AM, Pierre Labastie wrote: On Sun, 2021-02-07 at 13:38 +0100, Frans de Boer wrote: LS, Finally had a change to finish the LFS build. Alas, the grub-install reported the old error "Decompression is too big". Here is the solution to add to the section to compile grub: # Patch gentpl.py to avoid an error from grub-mkinstall "Decompressor is too big" # Source: https://www.mail-archive.com/grub-devel@gnu.org/msg29840.html # sed -i -E "s@(.*-R .note.gnu.gold-version -R)(.*)@\1 .note.gnu.property -R\2@" gentpl.py ln -fs /usr/bin/python3 /usr/bin/python # grub needs 'python' ./autogen.sh rm -f /usr/bin/python Very interesting, thanks! There are several hundreds of commits in grub repositories since the last release. I hope we'll see a release soon... Soon is relative. I follow the grub mailing list and a release is still several months away. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Problem with grub and patch to dev.
On 2/7/21 8:50 AM, Pierre Labastie wrote: On Sun, 2021-02-07 at 08:26 -0600, Jim Martin wrote: On 2/7/21 6:38 AM, Frans de Boer wrote: LS, Finally had a change to finish the LFS build. Alas, the grub- install reported the old error "Decompression is too big". Here is the solution to add to the section to compile grub: # Patch gentpl.py to avoid an error from grub-mkinstall "Decompressor is too big" # Source: https://www.mail-archive.com/grub-devel@gnu.org/msg29840.html # sed -i -E "s@(.*-R .note.gnu.gold-version -R)(.*)@\1 .note.gnu.property -R\2@" gentpl.py ln -fs /usr/bin/python3 /usr/bin/python # grub needs 'python' ./autogen.sh rm -f /usr/bin/python ./configure ... --- Frans. Thanks for this Frans ! I just ran across this same error yesterday working with LFS - Version 20210206-systemd. I also noticed that the grub-install actually worked in spite of this error. Much to my surprise the system actually booted ... I am working through the LFS- Version 20210206-systemd install again and will add in the fix and see how it goes... Can be further simplified to: sed -e 's/\.note\.gnu\.gold-version/& -R .note.gnu.property/' \ -i Makefile.in grub-core/Makefile.in Just before configure (no need to run autogen, nor to relink python) Pierre Pierre this worked perfectly ! No errors reported.. So: # sed -e 's/\.note\.gnu\.gold-version/& -R .note.gnu.property/' \ -i Makefile.in grub-core/Makefile.in # ./configure --prefix=/usr \ --sbindir=/sbin\ --sysconfdir=/etc \ --disable-efiemu \ --disable-werror # make # make install # mv -v /etc/bash_completion.d/grub /usr/share/bash-completion/completions Thanks ! Jim -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Problem with grub and patch to dev.
On 07/02/2021 15:26, Jim Martin wrote: On 2/7/21 6:38 AM, Frans de Boer wrote: LS, Finally had a change to finish the LFS build. Alas, the grub-install reported the old error "Decompression is too big". Here is the solution to add to the section to compile grub: # Patch gentpl.py to avoid an error from grub-mkinstall "Decompressor is too big" # Source: https://www.mail-archive.com/grub-devel@gnu.org/msg29840.html # sed -i -E "s@(.*-R .note.gnu.gold-version -R)(.*)@\1 .note.gnu.property -R\2@" gentpl.py ln -fs /usr/bin/python3 /usr/bin/python # grub needs 'python' ./autogen.sh rm -f /usr/bin/python ./configure ... --- Frans. Thanks for this Frans ! I just ran across this same error yesterday working with LFS - Version 20210206-systemd. I also noticed that the grub-install actually worked in spite of this error. Much to my surprise the system actually booted ... I am working through the LFS- Version 20210206-systemd install again and will add in the fix and see how it goes... Jim It works on sysvinit and systemd configurations. After all, the compile of grub is the same for both versions. And, yes, the systems will boot, but when using scripts to build LFS and being halted because of errors, I added the last three lines to get everything cleanly compiled and installed. Pierre is looking if there is another patch possible. For now we can work with it. --- Frans. -- A: Yes, just like thatA: Ja, net zo Q: Oh, Just like reading a book backwards Q: Oh, net als een boek achterstevoren lezen A: Because it upsets the natural flow of a story A: Omdat het de natuurlijke gang uit het verhaal haalt Q: Why is top-posting annoying? Q: Waarom is Top-posting zo irritant? -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Problem with grub and patch to dev.
On Sun, 2021-02-07 at 08:26 -0600, Jim Martin wrote: > On 2/7/21 6:38 AM, Frans de Boer wrote: > > LS, > > > > Finally had a change to finish the LFS build. Alas, the grub- > > install > > reported the old error "Decompression is too big". > > Here is the solution to add to the section to compile grub: > > > > # Patch gentpl.py to avoid an error from grub-mkinstall > > "Decompressor > > is too big" > > # Source: > > https://www.mail-archive.com/grub-devel@gnu.org/msg29840.html > > # > > sed -i -E "s@(.*-R .note.gnu.gold-version -R)(.*)@\1 > > .note.gnu.property -R\2@" gentpl.py > > ln -fs /usr/bin/python3 /usr/bin/python # grub needs 'python' > > ./autogen.sh > > rm -f /usr/bin/python > > > > ./configure ... > > > > --- Frans. > > > Thanks for this Frans ! I just ran across this same error yesterday > working with LFS - Version 20210206-systemd. > > I also noticed that the grub-install actually worked in spite of this > error. > > Much to my surprise the system actually booted ... > > I am working through the LFS- Version 20210206-systemd install again > and > will add in the fix and see how it goes... > Can be further simplified to: sed -e 's/\.note\.gnu\.gold-version/& -R .note.gnu.property/' \ -i Makefile.in grub-core/Makefile.in Just before configure (no need to run autogen, nor to relink python) Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Problem with grub and patch to dev.
On 2/7/21 6:38 AM, Frans de Boer wrote: LS, Finally had a change to finish the LFS build. Alas, the grub-install reported the old error "Decompression is too big". Here is the solution to add to the section to compile grub: # Patch gentpl.py to avoid an error from grub-mkinstall "Decompressor is too big" # Source: https://www.mail-archive.com/grub-devel@gnu.org/msg29840.html # sed -i -E "s@(.*-R .note.gnu.gold-version -R)(.*)@\1 .note.gnu.property -R\2@" gentpl.py ln -fs /usr/bin/python3 /usr/bin/python # grub needs 'python' ./autogen.sh rm -f /usr/bin/python ./configure ... --- Frans. Thanks for this Frans ! I just ran across this same error yesterday working with LFS - Version 20210206-systemd. I also noticed that the grub-install actually worked in spite of this error. Much to my surprise the system actually booted ... I am working through the LFS- Version 20210206-systemd install again and will add in the fix and see how it goes... Jim -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Problem with grub and patch to dev.
On Sun, 2021-02-07 at 14:15 +0100, Pierre Labastie wrote: > On Sun, 2021-02-07 at 13:38 +0100, Frans de Boer wrote: > > LS, > > > > Finally had a change to finish the LFS build. Alas, the grub- > > install > > reported the old error "Decompression is too big". > > Here is the solution to add to the section to compile grub: > > > > # Patch gentpl.py to avoid an error from grub-mkinstall > > "Decompressor > > is > > too big" > > # Source: > > https://www.mail-archive.com/grub-devel@gnu.org/msg29840.html > > # > > sed -i -E "s@(.*-R .note.gnu.gold-version -R)(.*)@\1 > > .note.gnu.property > > -R\2@" gentpl.py > > ln -fs /usr/bin/python3 /usr/bin/python # grub needs 'python' > > ./autogen.sh > > rm -f /usr/bin/python > > > > Very interesting, thanks! There are several hundreds of commits in > grub > repositories since the last release. I hope we'll see a release > soon... > > For us, instead of running autogen, can't the generated file be > patched > directly? I looks like gentpl.py generates Makefile.*.am, and my > guess > is that this ends up in Makefile.*.in after running autofu... > > Will look more closely Yes this can be simplified to (sorry for format, need to fit into 80 chars per line): sed -i -E \ "s@(.*-R .note.gnu.gold-version -R)(.*)@\1 .note.gnu.property -R\2@" \ Makefile.in grub-core/Makefile.in before running configure. Results: - without the sed, after make: -- $ ls -l grub-core/lzma* -rwxr-xr-x 1 pierre pierre 4972 7 févr. 15:01 grub- core/lzma_decompress.image -rwxr-xr-x 1 pierre pierre 134479612 7 févr. 15:01 grub- core/lzma_decompress.img -- - with the sed, after make: -- $ ls -l grub-core/lzma* -rwxr-xr-x 1 pierre pierre 4972 7 févr. 15:09 grub- core/lzma_decompress.image -rwxr-xr-x 1 pierre pierre 2848 7 févr. 15:09 grub- core/lzma_decompress.img -- If nobody speaks up, will add that tomorrow to grub page. Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Problem with grub and patch to dev.
On Sun, 2021-02-07 at 13:38 +0100, Frans de Boer wrote: > LS, > > Finally had a change to finish the LFS build. Alas, the grub-install > reported the old error "Decompression is too big". > Here is the solution to add to the section to compile grub: > > # Patch gentpl.py to avoid an error from grub-mkinstall "Decompressor > is > too big" > # Source: > https://www.mail-archive.com/grub-devel@gnu.org/msg29840.html > # > sed -i -E "s@(.*-R .note.gnu.gold-version -R)(.*)@\1 > .note.gnu.property > -R\2@" gentpl.py > ln -fs /usr/bin/python3 /usr/bin/python # grub needs 'python' > ./autogen.sh > rm -f /usr/bin/python > Very interesting, thanks! There are several hundreds of commits in grub repositories since the last release. I hope we'll see a release soon... For us, instead of running autogen, can't the generated file be patched directly? I looks like gentpl.py generates Makefile.*.am, and my guess is that this ends up in Makefile.*.in after running autofu... Will look more closely Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
[lfs-support] Problem with grub and patch to dev.
LS, Finally had a change to finish the LFS build. Alas, the grub-install reported the old error "Decompression is too big". Here is the solution to add to the section to compile grub: # Patch gentpl.py to avoid an error from grub-mkinstall "Decompressor is too big" # Source: https://www.mail-archive.com/grub-devel@gnu.org/msg29840.html # sed -i -E "s@(.*-R .note.gnu.gold-version -R)(.*)@\1 .note.gnu.property -R\2@" gentpl.py ln -fs /usr/bin/python3 /usr/bin/python # grub needs 'python' ./autogen.sh rm -f /usr/bin/python ./configure ... --- Frans. -- A: Yes, just like thatA: Ja, net zo Q: Oh, Just like reading a book backwards Q: Oh, net als een boek achterstevoren lezen A: Because it upsets the natural flow of a story A: Omdat het de natuurlijke gang uit het verhaal haalt Q: Why is top-posting annoying? Q: Waarom is Top-posting zo irritant? -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] fatal error: bits/c++config.h: No such file or directory
On Sun, 2021-02-07 at 01:18 -0600, p...@kemascraft.com wrote: > I'm working through the LFS 10.0 book. I got the error: " fatal > error: bits/c+ > +config.h: No such file or directory". The file exist. I'm at > 8.6.1. Installation of DejaGNU. and ran the "make check." command. > I'm trying > to install with the "User Based Management " Package Management > system. > Goggle didn't help much. i found a suggestion to "export > CPLUS_INCLUDE_PATH=/ > usr/include/", but no luck. any help would be appreciated. Hard to say anything without a more detailed error message (what does it say just above, what was the command that failed, not the one you ran, but the one that "make" ran, etc). Using CPLUS_INCLUDE_PATH (or any include path) pointing to /usr/include is dangerous, because it changes the order of the include directories. This order is important when using the #include_next directive, which happens in several packages. Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
