configure: error: C compiler cannot create executables

[jrgifford]

I see this with any version of the C ruby family.

https://gist.github.com/jrgifford/5057327

However, when I revert ruby-build to 84820db, it works.

OS: Ubuntu 12.10, 32 bit.

[jrgifford]

Fails on 06d7994 as well.

[sferik]

@sstephenson The only relevant changes between 84820db1c0793239ad20a36a10ac3e74c1a73a0d and master at the moment are the CFLAGS changes you made yesterday. Any idea why those may be causing this issue?

[sstephenson]

@jrgifford It sounds like you have both clang and gcc installed. ruby-build detects clang and adds -Wno-error=shorten-64-to-32 to CFLAGS accordingly (#290).

You can work around this error by running CC=gcc rbenv install ...

The question is, why does Ruby's configure pick gcc instead of clang? /cc @jeremy

[jeremy]

@sstephenson This is because Ruby does the gcc-4.2/clang/gcc/cc check on darwin only.

On other platforms, --with-gcc, --without-gcc, and manually-set CC decide the compiler.

So if clang is available on Ubuntu, we'll break unless the user passed CC=clang or RUBY_CONFIGURE_OPTS=--without-gcc

Argh. Sounds better to limit our test to darwin.

[jrgifford]

Correct that I can run CC=gcc rbenv install ....

I do have both clang and gcc installed.

James Gifford
cell: 2162238574

On Thu, Feb 28, 2013 at 9:42 PM, Jeremy Kemper [email protected]:

@sstephenson https://github.com/sstephenson This is because Ruby does
the gcc-4.2/clang/gcc/cc check on darwin only.

On other platforms, --with-gcc, --without-gcc, and manually-set CC decide
the compiler.

So if clang is available on Ubuntu, we'll break unless the user passed
CC=clang or RUBY_CONFIGURE_OPTS=--without-gcc

Argh. Sounds better to limit our test to darwin.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/319#issuecomment-14270556
.

[sgharms]

Just got bit by this one today. Sam's workaround was successful though.

[jrgifford]

This should get fixed soon, I was playing with a potential fix last week.
I'll test some more and see if it solves it.

James Gifford
cell: 2162238574
Snowy Penguin Solutions, LLC | http://snowypenguinsolutions.com
On Mar 31, 2013 12:22 PM, "Steven G. Harms" [email protected]
wrote:

Just got bit by this one today. Sam's workaround was successful though.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/319#issuecomment-15693593
.

[gnprice]

Just submitted a fix as #339.

@jeremy, @sstephenson, I don't think that explanation of why MRI's configure script picks gcc is right. The case statement mentioning gcc-4.2, gcc, cc, and clang doesn't affect the C compiler used -- it's only reading $CC, and setting $CXX (the C++ compiler) correspondingly. It looks like quite a kludge, but it doesn't touch the C compiler.

Later on, the script invokes the standard Autoconf macro AC_PROG_CC. That's documented like so:

If CC is not already set in the environment, check for gcc and cc, then for other C compilers. Set output variable CC to the name of the compiler found. [... then much more detail ...]
http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/C-Compiler.html

So GCC will be chosen because it's the preference embedded into Autoconf. The environment variable $CC overrides that preference; if you're building MRI with clang, you're doing so either by setting $CC directly; or setting it through the --without-gcc flag to this configure script, which sets $CC to cc; or setting it by some other means I've missed.

This highlights how tough it is to accurately guess from the outside what configure is going to do! In fact, even the documentation (as I quoted) doesn't nail down just how AC_PROG_CC finds a C compiler, if its first three choices don't exist. So as I said in the pull request and commit message, the real fix is to handle this in the actual configure script upstream, where we can piggyback off of Autoconf's actual choices rather than try to predict them. But pending that, I think my change should make the workaround clearer and prevent it from causing problems for most people.

[jeremy]

Fixed by #339

[jrgifford]

Yay! 😄

[Nakilon]

Despite this issue is two years old I had to do this patch manually a month ago.

$ ruby-build --version
ruby-build 20150818