Discussion:
[lfs-support] LFS v. 8.3 : Compiler lacks asm-goto support.. Stop.
Terence Waterhouse
2018-09-15 14:50:40 UTC
Permalink
Hello all,

When running right at the start of chapter 8.3 to prepare the kernel build, I got the
following message (with no further output) :

arch/x86/Makefile:184: *** Compiler lacks asm-goto support..  Stop.

As far as I can make out this is an issue with kernels before 4.5 and the current kernel is 4.18.5. I had no
build problems with gcc-8.2.0 and no test fails.

Should I continue or is this critical ?
Many thanks in advance

Terence.
Terence Waterhouse
2018-09-15 15:13:23 UTC
Permalink
Message du 15/09/18 16:51
De : "Terence Waterhouse"
A : "lfs-support"
Objet : [lfs-support] LFS v. 8.3 : Compiler lacks asm-goto support.. Stop.
Hello all,
When running right at the start of chapter 8.3 to prepare the kernel build, I got the
arch/x86/Makefile:184: *** Compiler lacks asm-goto support..  Stop.
As far as I can make out this is an issue with kernels before 4.5 and the current kernel is 4.18.5. I had no
build problems with gcc-8.2.0 and no test fails.
Should I continue or is this critical ?
Many thanks in advance
Terence.
--
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
Of course I should have written "this is an issue with gcc versions before 4.5" sorry for that mistake.
Here is the output of gcc -v

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/usr --enable-languages=c,c++ --disable-multilib --disable-bootstrap --disable-libmpx --with-system-zlib
Thread model: posix
gcc version 8.2.0 (GCC)
--
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-m
Ken Moffat
2018-09-15 17:25:09 UTC
Permalink
Post by Terence Waterhouse
Post by Terence Waterhouse
Hello all,
When running right at the start of chapter 8.3 to prepare the kernel build, I got the
arch/x86/Makefile:184: *** Compiler lacks asm-goto support..  Stop.
As far as I can make out this is an issue with kernels before 4.5 and the current kernel is 4.18.5. I had no
build problems with gcc-8.2.0 and no test fails.
Should I continue or is this critical ?
Short answer is that you cannot continue until you are able to
determine what has gone wrong. At the moment you can't build a
kernel, so you cannot boot the new system.
Post by Terence Waterhouse
Post by Terence Waterhouse
Many thanks in advance
Of course I should have written "this is an issue with gcc versions before 4.5" sorry for that mistake.
Here is the output of gcc -v
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/usr --enable-languages=c,c++ --disable-multilib --disable-bootstrap --disable-libmpx --with-system-zlib
Thread model: posix
gcc version 8.2.0 (GCC)
I've not heard of anybody hitting this problem with recent gcc.
Google found the patch where this was proposed, the initial comment
is:

| Now that we have objtool to validate the correctness of asm-goto
| constructs we can start using it to guarantee the absence of dynamic
| branches (and thus speculation).

So the problem appears to be in objtool. We added elfutils to LFS
in 8.2 to support objtool, maybe something went wrong in your
install of that (libelf).

The test in the kernel tree is at scripts/gcc-goto.sh, but I don't
know how to run that successfully from outside the kernel build (in
particular, it needs to be persuaded to run objtool, and altered to
not discard the output).

You are using the orc unwinder ?

All I can suggest is that you run ldd on the compiled objtool in the
kernel tree (tools/objtool/objtool) to see if that reports an error
(it should report it is linked to libelf.so.1 as libz, libc, the
vdso and the loader.

Unfortunately, the kernel build system has changed this year, and
things which used to reliably trigger the expected error messages
(in my experiences, trying to change the kernel config and rebuild
the existing tree as a user after building as root, and at first boot
a typo in the bootargs root=/dev/sda76, caused failures but with
very odd error messages.

ĸen
--
Tout est bien, tout va bien, tout va pour le mieux qu'il soit possible
-- Candide, de Voltaire
(Everything is for the best, in the best of all possible worlds)
--
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
Terence Waterhouse
2018-09-15 18:10:11 UTC
Permalink
Message du 15/09/18 19:25
De : "Ken Moffat"
A : "Terence Waterhouse" , "LFS Support List"
Objet : Re: [lfs-support] LFS v. 8.3 : Compiler lacks asm-goto support.. Stop.
Post by Terence Waterhouse
Post by Terence Waterhouse
Hello all,
When running right at the start of chapter 8.3 to prepare the kernel build, I got the
arch/x86/Makefile:184: *** Compiler lacks asm-goto support..  Stop.
As far as I can make out this is an issue with kernels before 4.5 and the current kernel is 4.18.5. I had no
build problems with gcc-8.2.0 and no test fails.
Should I continue or is this critical ?
Short answer is that you cannot continue until you are able to
determine what has gone wrong. At the moment you can't build a
kernel, so you cannot boot the new system.
Post by Terence Waterhouse
Post by Terence Waterhouse
Many thanks in advance
Of course I should have written "this is an issue with gcc versions before 4.5" sorry for that mistake.
Here is the output of gcc -v
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/usr --enable-languages=c,c++ --disable-multilib --disable-bootstrap --disable-libmpx --with-system-zlib
Thread model: posix
gcc version 8.2.0 (GCC)
I've not heard of anybody hitting this problem with recent gcc.
Google found the patch where this was proposed, the initial comment
| Now that we have objtool to validate the correctness of asm-goto
| constructs we can start using it to guarantee the absence of dynamic
| branches (and thus speculation).
So the problem appears to be in objtool. We added elfutils to LFS
in 8.2 to support objtool, maybe something went wrong in your
install of that (libelf).
The test in the kernel tree is at scripts/gcc-goto.sh, but I don't
know how to run that successfully from outside the kernel build (in
particular, it needs to be persuaded to run objtool, and altered to
not discard the output).
You are using the orc unwinder ?
All I can suggest is that you run ldd on the compiled objtool in the
kernel tree (tools/objtool/objtool) to see if that reports an error
(it should report it is linked to libelf.so.1 as libz, libc, the
vdso and the loader.
Unfortunately, the kernel build system has changed this year, and
things which used to reliably trigger the expected error messages
(in my experiences, trying to change the kernel config and rebuild
the existing tree as a user after building as root, and at first boot
a typo in the bootargs root=/dev/sda76, caused failures but with
very odd error messages.
Äžen
--
Tout est bien, tout va bien, tout va pour le mieux qu'il soit possible
-- Candide, de Voltaire
(Everything is for the best, in the best of all possible worlds)
Many thanks for the reply Ken. I found the patch on google you speak of, but I'm afraid I'm out
of my depth here. I'll look into your post in detail and see where I can go. I'll just say that since I began
8.3 All went smoothly and all test suites succeeded I had no fails whatsoever so I don't have much idea as to where
to start searching. I had only one path problem probably caused by an omission on my part. (See the post:

 

chapter 6.55 v.8.3 fatal error while building e2fsprogs

 

in the support-list ) which Pierre Labastié fixed for me so perhaps I'll start there.

 

Many thanks for your reply

 

Best regards

 

Terence
Terence Waterhouse
2018-09-16 10:19:15 UTC
Permalink
Message du 15/09/18 19:25
De : "Ken Moffat"
A : "Terence Waterhouse" , "LFS Support List"
Objet : Re: [lfs-support] LFS v. 8.3 : Compiler lacks asm-goto support.. Stop.
Post by Terence Waterhouse
Post by Terence Waterhouse
Hello all,
When running right at the start of chapter 8.3 to prepare the kernel build, I got the
arch/x86/Makefile:184: *** Compiler lacks asm-goto support..  Stop.
As far as I can make out this is an issue with kernels before 4.5 and the current kernel is 4.18.5. I had no
build problems with gcc-8.2.0 and no test fails.
Should I continue or is this critical ?
Short answer is that you cannot continue until you are able to
determine what has gone wrong. At the moment you can't build a
kernel, so you cannot boot the new system.
Post by Terence Waterhouse
Post by Terence Waterhouse
Many thanks in advance
Of course I should have written "this is an issue with gcc versions before 4.5" sorry for that mistake.
Here is the output of gcc -v
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/usr --enable-languages=c,c++ --disable-multilib --disable-bootstrap --disable-libmpx --with-system-zlib
Thread model: posix
gcc version 8.2.0 (GCC)
I've not heard of anybody hitting this problem with recent gcc.
Google found the patch where this was proposed, the initial comment
| Now that we have objtool to validate the correctness of asm-goto
| constructs we can start using it to guarantee the absence of dynamic
| branches (and thus speculation).
So the problem appears to be in objtool. We added elfutils to LFS
in 8.2 to support objtool, maybe something went wrong in your
install of that (libelf).
The test in the kernel tree is at scripts/gcc-goto.sh, but I don't
know how to run that successfully from outside the kernel build (in
particular, it needs to be persuaded to run objtool, and altered to
not discard the output).
You are using the orc unwinder ?
All I can suggest is that you run ldd on the compiled objtool in the
kernel tree (tools/objtool/objtool) to see if that reports an error
(it should report it is linked to libelf.so.1 as libz, libc, the
vdso and the loader.
Unfortunately, the kernel build system has changed this year, and
things which used to reliably trigger the expected error messages
(in my experiences, trying to change the kernel config and rebuild
the existing tree as a user after building as root, and at first boot
a typo in the bootargs root=/dev/sda76, caused failures but with
very odd error messages.
Äžen
--
Tout est bien, tout va bien, tout va pour le mieux qu'il soit possible
-- Candide, de Voltaire
(Everything is for the best, in the best of all possible worlds)
Hello all and of course, Ken,

I tried your suggestions and couldn't get much (any) feedback. There are only source files in the tools/objtool directory
so ldd couldn't be much help.

I couldn't get gcc-goto.sh to run either. however, you mentioned libelf so I tried recompiling the package and it reports that
the c compiler is not working. The relevant output from config.log is as follow :

////////////////

configure:3371: checking for gcc
configure:3387: found /usr/bin/gcc
configure:3398: result: gcc
configure:3627: checking for C compiler version
configure:3636: gcc --version >&5
gcc (GCC) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:3647: $? = 0
configure:3636: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/usr --enable-languages=c,c++ --disable-multilib --disable-bootstrap --disable-libmpx --with-system-zlib
Thread model: posix
gcc version 8.2.0 (GCC)
configure:3647: $? = 0
configure:3636: gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:3647: $? = 1
configure:3636: gcc -qversion >&5
gcc: error: unrecognized command line option '-qversion'; did you mean '--version'?
gcc: fatal error: no input files
compilation terminated.
configure:3647: $? = 1
configure:3667: checking whether the C compiler works
configure:3689: gcc    conftest.c  >&5
gcc: error trying to exec 'as': execvp: No such file or directory
configure:3693: $? = 1
configure:3731: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "elfutils"
| #define PACKAGE_TARNAME "elfutils"
| #define PACKAGE_VERSION "0.173"
| #define PACKAGE_STRING "elfutils 0.173"
| #define PACKAGE_BUGREPORT "https://sourceware.org/bugzilla"
| #define PACKAGE_URL "http://elfutils.org/"
| #define PACKAGE "elfutils"
| #define VERSION "0.173"
| #define DEFAULT_AR_DETERMINISTIC false
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:3736: error: in `/sources/elfutils-0.173':
configure:3738: error: C compiler cannot create executables
See `config.log' for more details

/////////////////

I must stress that the first compile of elfutils gave no errors and the test suite was perfectly clean. Now
it would seem that gcc-8.2.0 is not working properly and the build of this also went smoothly.

Incidentally, I don't know what the orc unwinder is although there are files concerning orc in

the tools/objtool directory.

 

many thanks in advance

 

Terence
Baho Utot
2018-09-16 11:48:48 UTC
Permalink
Message du 15/09/18 19:25
Objet : Re: [lfs-support] LFS v. 8.3 : Compiler lacks asm-goto
support.. Stop.
Post by Terence Waterhouse
Post by Terence Waterhouse
Hello all,
When running right at the start of chapter 8.3 to prepare the
kernel build, I got the
Post by Terence Waterhouse
Post by Terence Waterhouse
arch/x86/Makefile:184: *** Compiler lacks asm-goto support..  Stop.
As far as I can make out this is an issue with kernels before
4.5 and the current kernel is 4.18.5. I had no
Post by Terence Waterhouse
Post by Terence Waterhouse
build problems with gcc-8.2.0 and no test fails.
Should I continue or is this critical ?
Short answer is that you cannot continue until you are able to
determine what has gone wrong. At the moment you can't build a
kernel, so you cannot boot the new system.
Post by Terence Waterhouse
Post by Terence Waterhouse
Many thanks in advance
Of course I should have written "this is an issue with gcc
versions before 4.5" sorry for that mistake.
Post by Terence Waterhouse
Here is the output of gcc -v
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Post by Terence Waterhouse
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/usr
--enable-languages=c,c++ --disable-multilib --disable-bootstrap
--disable-libmpx --with-system-zlib
Post by Terence Waterhouse
Thread model: posix
gcc version 8.2.0 (GCC)
I've not heard of anybody hitting this problem with recent gcc.
Google found the patch where this was proposed, the initial comment
| Now that we have objtool to validate the correctness of asm-goto
| constructs we can start using it to guarantee the absence of dynamic
| branches (and thus speculation).
So the problem appears to be in objtool. We added elfutils to LFS
in 8.2 to support objtool, maybe something went wrong in your
install of that (libelf).
The test in the kernel tree is at scripts/gcc-goto.sh, but I don't
know how to run that successfully from outside the kernel build (in
particular, it needs to be persuaded to run objtool, and altered to
not discard the output).
You are using the orc unwinder ?
All I can suggest is that you run ldd on the compiled objtool in the
kernel tree (tools/objtool/objtool) to see if that reports an error
(it should report it is linked to libelf.so.1 as libz, libc, the
vdso and the loader.
Unfortunately, the kernel build system has changed this year, and
things which used to reliably trigger the expected error messages
(in my experiences, trying to change the kernel config and rebuild
the existing tree as a user after building as root, and at first boot
a typo in the bootargs root=/dev/sda76, caused failures but with
very odd error messages.
ĸen
--
Tout est bien, tout va bien, tout va pour le mieux qu'il soit possible
-- Candide, de Voltaire
(Everything is for the best, in the best of all possible worlds)
Hello all and of course, Ken,
I tried your suggestions and couldn't get much (any) feedback. There
are only source files in the tools/objtool directory
so ldd couldn't be much help.
I couldn't get gcc-goto.sh to run either. however, you mentioned
libelf so I tried recompiling the package and it reports that
////////////////
configure:3371: checking for gcc
configure:3387: found /usr/bin/gcc
configure:3398: result: gcc
configure:3627: checking for C compiler version
configure:3636: gcc --version >&5
gcc (GCC) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
configure:3647: $? = 0
configure:3636: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/usr --enable-languages=c,c++
--disable-multilib --disable-bootstrap --disable-libmpx --with-system-zlib
Thread model: posix
gcc version 8.2.0 (GCC)
configure:3647: $? = 0
configure:3636: gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:3647: $? = 1
configure:3636: gcc -qversion >&5
gcc: error: unrecognized command line option '-qversion'; did you mean '--version'?
gcc: fatal error: no input files
compilation terminated.
configure:3647: $? = 1
configure:3667: checking whether the C compiler works
configure:3689: gcc    conftest.c  >&5
gcc: error trying to exec 'as': execvp: No such file or directory
configure:3693: $? = 1
configure:3731: result: no
| /* confdefs.h */
| #define PACKAGE_NAME "elfutils"
| #define PACKAGE_TARNAME "elfutils"
| #define PACKAGE_VERSION "0.173"
| #define PACKAGE_STRING "elfutils 0.173"
| #define PACKAGE_BUGREPORT "https://sourceware.org/bugzilla"
| #define PACKAGE_URL "http://elfutils.org/"
| #define PACKAGE "elfutils"
| #define VERSION "0.173"
| #define DEFAULT_AR_DETERMINISTIC false
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:3738: error: C compiler cannot create executables
See `config.log' for more details
/////////////////
I must stress that the first compile of elfutils gave no errors and
the test suite was perfectly clean. Now
it would seem that gcc-8.2.0 is not working properly and the build of
this also went smoothly.
Incidentally, I don't know what the orc unwinder is although there are
files concerning orc in
the tools/objtool directory.
many thanks in advance
Terence
Every time I get the error:

configure:3738: error: C compiler cannot create executables

Something when wrong in the Adjusting the tools chain step.

I have not found out what that was

See `config.log' for more details
--
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.or
Terence Waterhouse
2018-09-16 12:01:13 UTC
Permalink
Message du 16/09/18 13:49
De : "Baho Utot"
Objet : Re: [lfs-support] LFS v. 8.3 : Compiler lacks asm-goto support.. Stop.
On 9/16/18 6:19 AM, Terence Waterhouse wrote: > > > Message du 15/09/18 19:25 > > De : "Ken Moffat" > > A : "Terence Waterhouse" , "LFS Support List" > > > Copie à : > > Objet : Re: [lfs-support] LFS v. 8.3 : Compiler lacks asm-goto > support.. Stop. > > > > On Sat, Sep 15, 2018 at 05:13:23PM +0200, Terence Waterhouse wrote: > > > > > > > > Hello all, > > > > > > > When running right at the start of chapter 8.3 to prepare the > kernel build, I got the > > > > following message (with no further output) : > > > > > > > arch/x86/Makefile:184: *** Compiler lacks asm-goto support..  Stop. > > > > > > > As far as I can make out this is an issue with kernels before > 4.5 and the current kernel is 4.18.5. I had no > > > > build problems with gcc-8.2.0 and no test fails. > > > > > > > Should I continue or is this critical ? > > > > Short answer is that you cannot continue until you are able to > > determine what has gone wrong. At the moment you can't build a > > kernel, so you cannot boot the new system. > > > > > > Many thanks in advance > > > > > > > > > Of course I should have written "this is an issue with gcc > versions before 4.5" sorry for that mistake. > > > Here is the output of gcc -v > > > > > > gcc -v > > > Using built-in specs. > > > COLLECT_GCC=gcc > > > > COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper > > > Target: x86_64-pc-linux-gnu > > > Configured with: ../configure --prefix=/usr > --enable-languages=c,c++ --disable-multilib --disable-bootstrap > --disable-libmpx --with-system-zlib > > > Thread model: posix > > > gcc version 8.2.0 (GCC) > > > > I've not heard of anybody hitting this problem with recent gcc. > > Google found the patch where this was proposed, the initial comment > > is: > > > > | Now that we have objtool to validate the correctness of asm-goto > > | constructs we can start using it to guarantee the absence of dynamic > > | branches (and thus speculation). > > > > So the problem appears to be in objtool. We added elfutils to LFS > > in 8.2 to support objtool, maybe something went wrong in your > > install of that (libelf). > > > > The test in the kernel tree is at scripts/gcc-goto.sh, but I don't > > know how to run that successfully from outside the kernel build (in > > particular, it needs to be persuaded to run objtool, and altered to > > not discard the output). > > > > You are using the orc unwinder ? > > > > All I can suggest is that you run ldd on the compiled objtool in the > > kernel tree (tools/objtool/objtool) to see if that reports an error > > (it should report it is linked to libelf.so.1 as libz, libc, the > > vdso and the loader. > > > > Unfortunately, the kernel build system has changed this year, and > > things which used to reliably trigger the expected error messages > > (in my experiences, trying to change the kernel config and rebuild > > the existing tree as a user after building as root, and at first boot > > a typo in the bootargs root=/dev/sda76, caused failures but with > > very odd error messages. > > > > ĸen > > -- > > Tout est bien, tout va bien, tout va pour le mieux qu'il soit possible > > -- Candide, de Voltaire > > (Everything is for the best, in the best of all possible worlds) > > > > Hello all and of course, Ken, > > I tried your suggestions and couldn't get much (any) feedback. There > are only source files in the tools/objtool directory > so ldd couldn't be much help. > > I couldn't get gcc-goto.sh to run either. however, you mentioned > libelf so I tried recompiling the package and it reports that > the c compiler is not working. The relevant output from config.log is > as follow : > > //////////////// > > configure:3371: checking for gcc > configure:3387: found /usr/bin/gcc > configure:3398: result: gcc > configure:3627: checking for C compiler version > configure:3636: gcc --version >&5 > gcc (GCC) 8.2.0 > Copyright (C) 2018 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > PURPOSE. > > configure:3647: $? = 0 > configure:3636: gcc -v >&5 > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper > Target: x86_64-pc-linux-gnu > Configured with: ../configure --prefix=/usr --enable-languages=c,c++ > --disable-multilib --disable-bootstrap --disable-libmpx --with-system-zlib > Thread model: posix > gcc version 8.2.0 (GCC) > configure:3647: $? = 0 > configure:3636: gcc -V >&5 > gcc: error: unrecognized command line option '-V' > gcc: fatal error: no input files > compilation terminated. > configure:3647: $? = 1 > configure:3636: gcc -qversion >&5 > gcc: error: unrecognized command line option '-qversion'; did you mean > '--version'? > gcc: fatal error: no input files > compilation terminated. > configure:3647: $? = 1 > configure:3667: checking whether the C compiler works > configure:3689: gcc    conftest.c  >&5 > gcc: error trying to exec 'as': execvp: No such file or directory > configure:3693: $? = 1 > configure:3731: result: no > configure: failed program was: > | /* confdefs.h */ > | #define PACKAGE_NAME "elfutils" > | #define PACKAGE_TARNAME "elfutils" > | #define PACKAGE_VERSION "0.173" > | #define PACKAGE_STRING "elfutils 0.173" > | #define PACKAGE_BUGREPORT "https://sourceware.org/bugzilla" > | #define PACKAGE_URL "http://elfutils.org/" > | #define PACKAGE "elfutils" > | #define VERSION "0.173" > | #define DEFAULT_AR_DETERMINISTIC false > | /* end confdefs.h.  */ > | > | int > | main () > | { > | > |   ; > |   return 0; > | } > configure:3736: error: in `/sources/elfutils-0.173': > configure:3738: error: C compiler cannot create executables > See `config.log' for more details > > ///////////////// > > I must stress that the first compile of elfutils gave no errors and > the test suite was perfectly clean. Now > it would seem that gcc-8.2.0 is not working properly and the build of > this also went smoothly. > > Incidentally, I don't know what the orc unwinder is although there are > files concerning orc in > > the tools/objtool directory. > > many thanks in advance > > Terence > > Every time I get the error: configure:3738: error: C compiler cannot create executables Something when wrong in the Adjusting the tools chain step. I have not found out what that was See `config.log' for more details -- 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
Thank you, I'll have a close look at that passage.

Terence
--
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
Bruce Dubbs
2018-09-16 16:35:41 UTC
Permalink
Post by Terence Waterhouse
Post by Terence Waterhouse
Message du 15/09/18 19:25
[snip]
Post by Terence Waterhouse
Post by Terence Waterhouse
configure:3738: error: C compiler cannot create executables
See `config.log' for more details
/////////////////
I must stress that the first compile of elfutils gave no errors and
the test suite was perfectly clean. Now
it would seem that gcc-8.2.0 is not working properly and the build of
this also went smoothly.
Incidentally, I don't know what the orc unwinder is although there are
files concerning orc in
the tools/objtool directory.
many thanks in advance
Terence
configure:3738: error: C compiler cannot create executables
Something when wrong in the Adjusting the tools chain step.
I've seen that relatively frequently with my students. Many times I
have them restart Chapter 6 but it is tricky if Section 6.10. Adjusting
the Toolchain has been done. In that case, the changes in tools/ needs
to be reverted.

-- 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
Ken Moffat
2018-09-16 18:18:40 UTC
Permalink
Post by Bruce Dubbs
[snip]
Post by Terence Waterhouse
Post by Terence Waterhouse
configure:3738: error: C compiler cannot create executables
See `config.log' for more details
/////////////////
I must stress that the first compile of elfutils gave no errors and
the test suite was perfectly clean. Now
it would seem that gcc-8.2.0 is not working properly and the build
of this also went smoothly.
That in itself explains the original message about asm-goto - a test
is run using gcc to compile a fragment, and then the resulting
messages from a successful compile are checked for the expected
feature.

But the compile failed. The question is why, when everything in
chapter 6 compiled successfully.. The only reasons I can think of
are:

an fsck ran and put something important into lost+found.

lfs filesystem damaged by another system on the machine

file(s) deleted by root

hard drive starting to fail
Post by Bruce Dubbs
Post by Terence Waterhouse
Post by Terence Waterhouse
Incidentally, I don't know what the orc unwinder is although there
are files concerning orc in
the tools/objtool directory.
many thanks in advance
It's a better way to get call traces when the kernel oopses. I
remember Bruce saying he never sees such things, all I can say is
that he's lucky ;)
Post by Bruce Dubbs
Post by Terence Waterhouse
Post by Terence Waterhouse
Terence
configure:3738: error: C compiler cannot create executables
Something when wrong in the Adjusting the tools chain step.
I've seen that relatively frequently with my students. Many times I have
them restart Chapter 6 but it is tricky if Section 6.10. Adjusting the
Toolchain has been done. In that case, the changes in tools/ needs to be
reverted.
-- Bruce
Getting that within chapter 6, yes. But after that chapter has been
completed ? To me, that implies files or symlinks are missing or
damaged.

One of Terence's replies was unparseable for me (all the text in one
line), but I think there was something about cannot exec 'as' and
something about execvp (?).

Something in that system was working (bash, to run the commands),
but the toolchain appears to be broken.

ĸen
--
Tout est bien, tout va bien, tout va pour le mieux qu'il soit possible
-- Candide, de Voltaire
(Everything is for the best, in the best of all possible worlds)
--
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?

ht
Bruce Dubbs
2018-09-16 20:04:51 UTC
Permalink
Post by Ken Moffat
Post by Bruce Dubbs
[snip]
Post by Terence Waterhouse
Post by Terence Waterhouse
configure:3738: error: C compiler cannot create executables
See `config.log' for more details
/////////////////
I must stress that the first compile of elfutils gave no errors and
the test suite was perfectly clean. Now
it would seem that gcc-8.2.0 is not working properly and the build
of this also went smoothly.
That in itself explains the original message about asm-goto - a test
is run using gcc to compile a fragment, and then the resulting
messages from a successful compile are checked for the expected
feature.
But the compile failed. The question is why, when everything in
chapter 6 compiled successfully.. The only reasons I can think of
an fsck ran and put something important into lost+found.
lfs filesystem damaged by another system on the machine
file(s) deleted by root
hard drive starting to fail
Post by Bruce Dubbs
Post by Terence Waterhouse
Post by Terence Waterhouse
Incidentally, I don't know what the orc unwinder is although there
are files concerning orc in
the tools/objtool directory.
many thanks in advance
It's a better way to get call traces when the kernel oopses. I
remember Bruce saying he never sees such things, all I can say is
that he's lucky ;)
Post by Bruce Dubbs
Post by Terence Waterhouse
Post by Terence Waterhouse
Terence
configure:3738: error: C compiler cannot create executables
Something when wrong in the Adjusting the tools chain step.
I've seen that relatively frequently with my students. Many times I have
them restart Chapter 6 but it is tricky if Section 6.10. Adjusting the
Toolchain has been done. In that case, the changes in tools/ needs to be
reverted.
Getting that within chapter 6, yes. But after that chapter has been
completed ? To me, that implies files or symlinks are missing or
damaged.
If something is missing in Chapter 6 and the user changes the PATH so
/tools/bin is no longer used, this type of thing will show up.

-- 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_sty
Ken Moffat
2018-09-16 20:47:35 UTC
Permalink
Post by Bruce Dubbs
Post by Ken Moffat
Getting that within chapter 6, yes. But after that chapter has been
completed ? To me, that implies files or symlinks are missing or
damaged.
If something is missing in Chapter 6 and the user changes the PATH so
/tools/bin is no longer used, this type of thing will show up.
-- Bruce
Thanks. I had not considered that possibility.

ĸen
--
Tout est bien, tout va bien, tout va pour le mieux qu'il soit possible
-- Candide, de Voltaire
(Everything is for the best, in the best of all possible worlds)
--
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?
Terence Waterhouse
2018-09-17 09:45:58 UTC
Permalink
Message du 16/09/18 22:05
De : "Bruce Dubbs"
Objet : Re: [lfs-support] LFS v. 8.3 : Compiler lacks asm-goto support.. Stop.
Post by Terence Waterhouse
Post by Terence Waterhouse
Post by Ken Moffat
Post by Bruce Dubbs
[snip]
configure:3738: error: C compiler cannot create executables
See `config.log' for more details
/////////////////
Post by Terence Waterhouse
Post by Ken Moffat
Post by Bruce Dubbs
I must stress that the first compile of elfutils gave no errors and
the test suite was perfectly clean. Now
it would seem that gcc-8.2.0 is not working properly and the build
of this also went smoothly.
Post by Terence Waterhouse
Post by Ken Moffat
That in itself explains the original message about asm-goto - a test
is run using gcc to compile a fragment, and then the resulting
messages from a successful compile are checked for the expected
feature.
But the compile failed. The question is why, when everything in
chapter 6 compiled successfully.. The only reasons I can think of
an fsck ran and put something important into lost+found.
lfs filesystem damaged by another system on the machine
file(s) deleted by root
hard drive starting to fail
I can't imagine any of these reasons being responsible, except files having been deleted.
I'm running the latest version of OpenSuse Leap 42.3 as host on an Asus X45U with a hd of 1To
and 8Go of Ram which has never had a single glitch, nor even crash of any kind.
However, I was not happy at the stripping and cleaning stage at the end of chapter 6. As advised
I was very careful, and, I'm fairly sure, precise with the commands,but who knows. For example
I deleted the directory but if something went wrong while adjusting the toolchain earlier on
I could well be missing some executables. . .
Post by Terence Waterhouse
Post by Terence Waterhouse
Incidentally, I don't know what the orc unwinder is although there
are files concerning orc in
the tools/objtool directory.
many thanks in advance
It's a better way to get call traces when the kernel oopses. I
remember Bruce saying he never sees such things, all I can say is > that he's lucky ;)
Thanks that's handy to know. Indeed it is one of the problems here.
Post by Terence Waterhouse
Terence
Post by Terence Waterhouse
Post by Ken Moffat
configure:3738: error: C compiler cannot create executables
Something when wrong in the Adjusting the tools chain step.
I've seen that relatively frequently with my students. Many times I have
them restart Chapter 6 but it is tricky if Section 6.10. Adjusting the
Toolchain has been done. In that case, the changes in tools/ needs to be
reverted.
Getting that within chapter 6, yes. But after that chapter has been
completed ? To me, that implies files or symlinks are missing or
damaged. If something is missing in Chapter 6 and the user changes the PATH so /tools/bin is no longer used,
this type of thing will show up.
-- Bruce --
This re-enforces the idea that the toolchain adjustment is the key area but as Bruce said, it seems
to me very tricky to undo this part.
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
Hello Ken, hello Bruce, hello all,
Thanks to your remarks we seem to be getting to the heart of the problem : the adjustment of the
tool chain at the beginning of chapter 6.
I received your messages this morning after starting an analysis of my install from the beginning of
chapter two and am already finding one or two things. For example after running the host system version-check
I got the message at the end but on more careful examination LFS 8.3 requires
GCC-4.9 and my version is 4.8.5, so maybe I have to update ? I continued on account of the
message.

Anyway, I'm considering formatting the drives and starting again. It may well be quicker than seeking a solution
that may itself be only partial. I have gained a lot of experience in this build and feel capable of much more
control over the build process.

I insist : I am not giving up! The educational experience is very rich and I am l learning a lot.

Many thanks for the great work, I will keep you posted.

 

Terence

P.S. The most surprising thing was the smoothness of the build and the success of all the tests, I really

wasn't expecting such a sudden stop.

 

Loading...