On 9/10/22 11:42, Arve Barsnes wrote:

On Sat, 10 Sept 2022 at 17:28, Jack <ostroffjh@users.sourceforge.net> wrote:

Any thoughts or suggestions?

I feel like this is an error that tends to pop up when your toolchain
is broken. Are you able to re-emerge gcc?

Reasonable thought.  I've just kicked of a re-emerge of gcc. I'll post
back when it's done - likely an hour or two.

What's odd is that I've done plenty of other successful emerges since I
first got this error, although I certainly realize that different
packages use very different subsets of the total tool chain.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I now get this error trying to emerge two different packages:
libofx-0.10.7 and gnupg (both 2.2.39 and 2.3.6).  It might also be the
same problem for a few bugs on b.g.o found by searching on "cannot
create exectuables."

The relevant lines from build.log are

checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
checking whether the C compiler works... no
configure: error: in `/var/tmp/portage/dev-libs/libofx-0.10.7/work/libofx-0.10.7':
configure: error: C compiler cannot create executables
See `config.log' for more details

and from config.log:

Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.3.0 (Gentoo 11.3.0 p4)
configure:2952: $? = 0
configure:2941: x86_64-pc-linux-gnu-gcc -V >&5
x86_64-pc-linux-gnu-gcc: error: unrecognized command-line option '-V' x86_64-pc-linux-gnu-gcc: fatal error: no input files
compilation terminated.
configure:2952: $? = 1
configure:2941: x86_64-pc-linux-gnu-gcc -qversion >&5
x86_64-pc-linux-gnu-gcc: error: unrecognized command-line option
'-qversion'; did you mean '--version'?
x86_64-pc-linux-gnu-gcc: fatal error: no input files
compilation terminated.
configure:2952: $? = 1
configure:2972: checking whether the C compiler works
configure:2994: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -og
-ggdb  -Wl,-O1 -Wl,--as-needed conftest.c  >&5
configure:2998: $? = 0
configure:3036: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "libofx"
| #define PACKAGE_TARNAME "libofx"
| #define PACKAGE_VERSION "0.10.7"
| #define PACKAGE_STRING "libofx 0.10.7"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:3041: error: in `/var/tmp/portage/dev-libs/libofx-0.10.7/work/libofx-0.10.7':
configure:3043: error: C compiler cannot create executables
See `config.log' for more details

The thing I find curious is that it appears to me that the output of the
test compile is a file called "g" which I don't recall ever seeing, and
so I wonder if the problem is that something has changed with gcc
defaults and configure does not yet recognize that change.  I also don't
know the  significance of the two "fatal error: no input files".

The fact that this happens with two unrelated packages suggests that
it's  not specific to either of them, but something in my system or configuration.

Any thoughts or suggestions?

Jack

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On Sat, 10 Sep 2022, Jack wrote:

I now get this error trying to emerge two different packages: libofx-0.10.7 >and gnupg (both 2.2.39 and 2.3.6).� It might also be the same problem for a >few bugs on b.g.o found by searching on "cannot create exectuables."

The relevant lines from build.log are

checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
checking whether the C compiler works... no
configure: error: in >`/var/tmp/portage/dev-libs/libofx-0.10.7/work/libofx-0.10.7':
configure: error: C compiler cannot create executables
See `config.log' for more details

and from config.log:

configure:2941: x86_64-pc-linux-gnu-gcc -V >&5
x86_64-pc-linux-gnu-gcc: error: unrecognized command-line option '-V' >x86_64-pc-linux-gnu-gcc: fatal error: no input files
compilation terminated.
configure:2952: $? = 1
configure:2941: x86_64-pc-linux-gnu-gcc -qversion >&5 >x86_64-pc-linux-gnu-gcc: error: unrecognized command-line option '-qversion'; >did you mean '--version'?
x86_64-pc-linux-gnu-gcc: fatal error: no input files
compilation terminated.
configure:2952: $? = 1

These tests are normal fails with gcc, they are version checks for
other compilers.

configure:2972: checking whether the C compiler works
configure:2994: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -og -ggdb� >-Wl,-O1 -Wl,--as-needed conftest.c� >&5
configure:2998: $? = 0
configure:3036: result: no
configure: failed program was:

[..boilerplate..]

configure:3041: error: in >`/var/tmp/portage/dev-libs/libofx-0.10.7/work/libofx-0.10.7':
configure:3043: error: C compiler cannot create executables
See `config.log' for more details

The thing I find curious is that it appears to me that the output of the test >compile is a file called "g" which I don't recall ever seeing, and so I >wonder if the problem is that something has changed with gcc defaults and >configure does not yet recognize that change.� I also don't know the� >significance of the two "fatal error: no input files".

The fact that this happens with two unrelated packages suggests that it's� >not specific to either of them, but something in my system or configuration.

And it's a standard autoconf macro, namely AC_PROG_CC that results in
the error and the stuff before that is also standard. And as no
autoreconf is called, autotools versions should not matter.

Any thoughts or suggestions?

I use gcc 11.3.0 here as well, and have no problem. Check for the
variables CC, CFLAGS, CPPFLAGS, LDFLAGS and LIBS in /var/tmp/portage/dev-libs/libofx-0.10.7/temp/environment.

Somehow, that '-og' must have crept in there.

HTH,
-dnh

--
printk("%s: Boo!\n", dev->name);
linux-2.6.19/drivers/net/depca.c

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.
On 9/10/22 11:42, Arve Barsnes wrote:

On Sat, 10 Sept 2022 at 17:28, Jack<ostroffjh@users.sourceforge.net> wrote:

Any thoughts or suggestions?

I feel like this is an error that tends to pop up when your toolchain
is broken. Are you able to re-emerge gcc?

gcc11.3.0 re-emerge with no errors, bug the problem remains.

I note that in configure, line 2977 is 'ac_files="a.out conftest.exe
conftest a.exe a_out.exe b.out conftest.*"' but the test compilation
creates the output file "g" so configure seems to think that the compile
didn't produce any executable.  Using the same compile line but
switching x86_64-pc-linux-gnu-gcc to gcc produces a.out.  Further
searching makes me wonder if the configure itself for these two packages
is just based on some starting point too old for gcc11, but  that line
is the same in every package I currently still have present in /var/tmp/portage.

This leaves me wondering why gcc and x86_64-pc-linux-gnu-gcc use
different default output file names.

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 9/10/22 11:42, Arve Barsnes wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAJjrzcXkZQyhDJ6+kHkGfjeXne62F7ZeVA-9BfTaxZX6w2VGNw@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">On Sat, 10 Sept 2022 at 17:28, Jack <a class="moz-txt-link-rfc2396E" href="mailto:ostroffjh@users.sourceforge.net">&lt;ostroffjh@users.sourceforge.net&gt;</a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Any thoughts or suggestions?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I feel like this is an error that tends to pop up when your toolchain
is broken. Are you able to re-emerge gcc?</pre>
</blockquote>
<p>gcc11.3.0 re-emerge with no errors, bug the problem remains.</p>
<p>I note that in configure, line 2977 is 'ac_<span
style="font-family:monospace"><span
style="color:#000000;background-color:#ffffff;">files="a.out
conftest.exe conftest a.exe a_out.exe b.out conftest.*"' </span></span><span
style="color:#000000;background-color:#ffffff;">but the test
compilation creates the output file "g" so configure seems to
think that the compile didn't produce any executable.  Using the
same compile line but switching </span><span
style="color:#000000;background-color:#ffffff;"><span
style="color:#000000;background-color:#ffffff;">x86_64-pc-linux-gnu-gcc
to gcc produces a.out.</span>  Further searching makes me
wonder if the configure itself for these two packages is just
based on some starting point too old for gcc11, but  that line
is the same in every package I currently still have present in
/var/tmp/portage.</span></p>
<p>This leaves me wondering why gcc and x86_64-pc-linux-gnu-gcc use
different default output file names.<span
style="font-family:monospace"><span
style="color:#000000;background-color:#ffffff;"><span
style="font-family:monospace"><br>
</span></span></span></p>
</body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/10/22 14:49, Dale wrote:

Jack wrote:

I now get this error trying to emerge two different packages:
libofx-0.10.7 and gnupg (both 2.2.39 and 2.3.6).  It might also be the
same problem for a few bugs on b.g.o found by searching on "cannot
create exectuables."

The relevant lines from build.log are

checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
checking whether the C compiler works... no
configure: error: in
`/var/tmp/portage/dev-libs/libofx-0.10.7/work/libofx-0.10.7':
configure: error: C compiler cannot create executables
See `config.log' for more details

and from config.log:

Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.3.0 (Gentoo 11.3.0 p4)
configure:2952: $? = 0
configure:2941: x86_64-pc-linux-gnu-gcc -V >&5
x86_64-pc-linux-gnu-gcc: error: unrecognized command-line option '-V'
x86_64-pc-linux-gnu-gcc: fatal error: no input files
compilation terminated.
configure:2952: $? = 1
configure:2941: x86_64-pc-linux-gnu-gcc -qversion >&5
x86_64-pc-linux-gnu-gcc: error: unrecognized command-line option
'-qversion'; did you mean '--version'?
x86_64-pc-linux-gnu-gcc: fatal error: no input files
compilation terminated.
configure:2952: $? = 1
configure:2972: checking whether the C compiler works
configure:2994: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -og
-ggdb  -Wl,-O1 -Wl,--as-needed conftest.c  >&5
configure:2998: $? = 0
configure:3036: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "libofx"
| #define PACKAGE_TARNAME "libofx"
| #define PACKAGE_VERSION "0.10.7"
| #define PACKAGE_STRING "libofx 0.10.7"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:3041: error: in
`/var/tmp/portage/dev-libs/libofx-0.10.7/work/libofx-0.10.7':
configure:3043: error: C compiler cannot create executables
See `config.log' for more details

The thing I find curious is that it appears to me that the output of
the test compile is a file called "g" which I don't recall ever
seeing, and so I wonder if the problem is that something has changed
with gcc defaults and configure does not yet recognize that change.  I
also don't know the  significance of the two "fatal error: no input
files".

The fact that this happens with two unrelated packages suggests that
it's  not specific to either of them, but something in my system or
configuration.

Any thoughts or suggestions?

Jack

I ran into this ages ago.  I think the fix was to reset which compiler
it is set to use.  I used to keep two installed, in case one would fail
or some package couldn't build with a newer version yet.  If I recall correctly, I would list the available options with gcc-config -l and
then if two are available, set to older one and then change back or if
only one is installed, just set it to the one you have.  It's been a
good while and it could be that the cause of the problem has changed but
I don't think it will hurt anything to try this.  I think some settings
gets messed up and resetting it fixes it.

Hope that helps.  If not, clueless.  :/

Thanks Dale, but I only have one version of gcc installed and both
gcc-config and binutils-config show only one option.

I do believe that David Haller pegged the problem, and I'll respond to
his post after confirming.

Jack

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Jack wrote:

I now get this error trying to emerge two different packages:
libofx-0.10.7 and gnupg (both 2.2.39 and 2.3.6).  It might also be the
same problem for a few bugs on b.g.o found by searching on "cannot
create exectuables."

The relevant lines from build.log are

checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
checking whether the C compiler works... no
configure: error: in `/var/tmp/portage/dev-libs/libofx-0.10.7/work/libofx-0.10.7':
configure: error: C compiler cannot create executables
See `config.log' for more details

and from config.log:

Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.3.0 (Gentoo 11.3.0 p4)
configure:2952: $? = 0
configure:2941: x86_64-pc-linux-gnu-gcc -V >&5
x86_64-pc-linux-gnu-gcc: error: unrecognized command-line option '-V' x86_64-pc-linux-gnu-gcc: fatal error: no input files
compilation terminated.
configure:2952: $? = 1
configure:2941: x86_64-pc-linux-gnu-gcc -qversion >&5 x86_64-pc-linux-gnu-gcc: error: unrecognized command-line option
'-qversion'; did you mean '--version'?
x86_64-pc-linux-gnu-gcc: fatal error: no input files
compilation terminated.
configure:2952: $? = 1
configure:2972: checking whether the C compiler works
configure:2994: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -og
-ggdb  -Wl,-O1 -Wl,--as-needed conftest.c  >&5
configure:2998: $? = 0
configure:3036: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "libofx"
| #define PACKAGE_TARNAME "libofx"
| #define PACKAGE_VERSION "0.10.7"
| #define PACKAGE_STRING "libofx 0.10.7"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:3041: error: in `/var/tmp/portage/dev-libs/libofx-0.10.7/work/libofx-0.10.7':
configure:3043: error: C compiler cannot create executables
See `config.log' for more details

The thing I find curious is that it appears to me that the output of
the test compile is a file called "g" which I don't recall ever
seeing, and so I wonder if the problem is that something has changed
with gcc defaults and configure does not yet recognize that change.  I
also don't know the  significance of the two "fatal error: no input
files".

The fact that this happens with two unrelated packages suggests that
it's  not specific to either of them, but something in my system or configuration.

Any thoughts or suggestions?

Jack

I ran into this ages ago.  I think the fix was to reset which compiler
it is set to use.  I used to keep two installed, in case one would fail
or some package couldn't build with a newer version yet.  If I recall correctly, I would list the available options with gcc-config -l and
then if two are available, set to older one and then change back or if
only one is installed, just set it to the one you have.  It's been a
good while and it could be that the cause of the problem has changed but
I don't think it will hurt anything to try this.  I think some settings
gets messed up and resetting it fixes it. 

Hope that helps.  If not, clueless.  :/

Dale

:-)  :-) 

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022.09.10 13:56, David Haller wrote:

Hello,

On Sat, 10 Sep 2022, Jack wrote:

I now get this error trying to emerge two different packages: libofx-0.10.7
and gnupg (both 2.2.39 and 2.3.6).� It might also be the same

problem for a

few bugs on b.g.o found by searching on "cannot create exectuables."

The relevant lines from build.log are

checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
checking whether the C compiler works... no
configure: error: in >`/var/tmp/portage/dev-libs/libofx-0.10.7/work/libofx-0.10.7':
configure: error: C compiler cannot create executables
See `config.log' for more details

and from config.log:

configure:2941: x86_64-pc-linux-gnu-gcc -V >&5
x86_64-pc-linux-gnu-gcc: error: unrecognized command-line option '-V' >x86_64-pc-linux-gnu-gcc: fatal error: no input files
compilation terminated.
configure:2952: $? = 1
configure:2941: x86_64-pc-linux-gnu-gcc -qversion >&5 >x86_64-pc-linux-gnu-gcc: error: unrecognized command-line option '-qversion';
did you mean '--version'?
x86_64-pc-linux-gnu-gcc: fatal error: no input files
compilation terminated.
configure:2952: $? = 1

These tests are normal fails with gcc, they are version checks for
other compilers.

configure:2972: checking whether the C compiler works
configure:2994: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -og

-ggdb�

-Wl,-O1 -Wl,--as-needed conftest.c� >&5
configure:2998: $? = 0
configure:3036: result: no
configure: failed program was:

[..boilerplate..]

configure:3041: error: in >`/var/tmp/portage/dev-libs/libofx-0.10.7/work/libofx-0.10.7': >configure:3043: error: C compiler cannot create executables
See `config.log' for more details

The thing I find curious is that it appears to me that the output of

the test

compile is a file called "g" which I don't recall ever seeing, and

so I

wonder if the problem is that something has changed with gcc

defaults and

configure does not yet recognize that change.� I also don't know the� >significance of the two "fatal error: no input files".

The fact that this happens with two unrelated packages suggests that

it's�

not specific to either of them, but something in my system or configuration.

And it's a standard autoconf macro, namely AC_PROG_CC that results in
the error and the stuff before that is also standard. And as no
autoreconf is called, autotools versions should not matter.

Any thoughts or suggestions?

I use gcc 11.3.0 here as well, and have no problem. Check for the
variables CC, CFLAGS, CPPFLAGS, LDFLAGS and LIBS in /var/tmp/portage/dev-libs/libofx-0.10.7/temp/environment.

Somehow, that '-og' must have crept in there.

David - thank you, thank you, thank you.

No wonder my recent debugging wasn't doing what I expected. That stray
"-og" was supposed to be "-Og" (upper instead of lower case) and it is
in /etc/portage/env/debug.conf, which is referenced in /etc/portage/package.env for those packages I wish to compile with
various debugging related compiler settings, as well as not deleting
the build dir, even on success.

It shows what a fresh pair of eyes can do. When looking at the various
error related files, I really just saw -Og, and when you pointed that
out, my first thought was why any debugging setting would possible
cause this type of failure. Of course in hindsight, it now all makes
sense.

Thanks again to the list for all sorts of ongoing assistance.

Jack

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)