gcc does not support "-Wno-error=shorten-64-to-32" #325

quark-zju · 2013-03-10T07:48:27Z

ruby-build script contains following workaround for clang:

# Work around warnings building Ruby 2.0 on Clang 2.x
if type clang &>/dev/null; then
  if "${CC:-clang}" -x c /dev/null -E -Wno-error=shorten-64-to-32 &>/dev/null; then
    RUBY_CFLAGS="$RUBY_CFLAGS -Wno-error=shorten-64-to-32"
  fi
fi

If both gcc and clang installed and cc is gcc, the above workaround will be triggered wrongly and result in failing to compile anything:

configure:3741: checking whether the C compiler works
configure:3763: gcc   -Wno-error=shorten-64-to-32 -I'/home/quark/.rbenv/versions/2.0.0-p0/include'  -L'/home/quark/.rbenv/versions/2.0.0-p0/lib'  conftest.c  >&5
cc1: error: -Werror=shorten-64-to-32: no option -Wshorten-64-to-32
configure:3767: $? = 1
configure:3805: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define CANONICALIZATION_FOR_MATHN 1
| #define RUBY_BASE_NAME "ruby" !<verconf>!
| #define RUBY_VERSION_NAME RUBY_BASE_NAME"-"RUBY_LIB_VERSION !<verconf>!
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:3810: error: in `/tmp/ruby-build.20130310154119.10022/ruby-2.0.0-p0':
configure:3812: error: C compiler cannot create executables
See `config.log' for more details

How about changing ${CC:-clang} to ${CC:-cc} in the workaround script?

The text was updated successfully, but these errors were encountered:

lpar · 2013-03-14T17:29:48Z

You don't even need to have clang installed to get the problem. I hit it on Debian Stable with only GCC installed, so somehow the "type clang" stuff is being triggered even when the compiler is GCC. Nasty.

Ivoz · 2013-03-15T13:00:40Z

In short, this is a clang-specific flag; it should only be added if clang is the compiler being used, not universally. This check should be done after we know which compiler is being used.

alexspeller · 2013-03-20T01:28:18Z

I was just hit by this and spent about 6 hours uninstalling and reinstalling my toolchain because I thought that was the problem. I am an idiot :(

quark-zju · 2013-03-20T11:29:00Z

This is duplicated with #319.

The previous version of this logic was causing us to pass the flag when * clang is on the PATH, and * $CC, or 'clang' if CC unset, accepts the flag. But this is totally wrong if we have clang installed, haven't set $CC, and are going to end up using gcc. We end up passing the flag to gcc, which rejects it. The real fix is to put this in the autoconf goo in MRI upstream -- the only correct way to decide whether to pass this flag is after we know exactly what compiler we're using and can test if that compiler accepts the flag. But we can do better than before by approximating autoconf's choice of compiler as $CC if set, 'cc' otherwise (which will typically be a symlink to gcc or clang or another.) Fixes: rbenv#325

The previous version of this logic was causing us to pass the flag when * clang is on the PATH, and * $CC, or 'clang' if CC unset, accepts the flag. But this is totally wrong if we have clang installed, haven't set $CC, and are going to end up using gcc. We end up passing the flag to gcc, which rejects it. The real fix is to put this in the autoconf goo in MRI upstream -- the only correct way to decide whether to pass this flag is after we know exactly what compiler we're using and can test if that compiler accepts the flag. But we can do better than before by approximating autoconf's choice of compiler as $CC if set, 'cc' otherwise (which will typically be a symlink to gcc or clang or another.) Fixes: rbenv#319 and rbenv#325, which is a dupe.

jeremy · 2013-04-26T21:27:31Z

Fixed by #339

stantona · 2014-05-29T22:20:23Z

I am still getting this issue. When I bundle install nokogiri fails to install. My mkmf.log file looks like:

https://photos-1.dropbox.com/t/0/AAC1TjDZ0BD6O3-NxkXZi3KbFo-c4o4Fgg6-Z9gAssWkcA/12/12846094/png/1024x768/3/1401408000/0/2/Screenshot%202014-05-29%2015.18.21.png/P6xlrS6O7FWpaZFZ6w7onpd2tRS5pyWoG4yO7D0hZV0

mislav · 2014-06-01T01:59:38Z

@stantona: Compiling Nokogiri is different than compiling Ruby. This project only deals with producing working Ruby installations. For compiling Nokogiri please see its troubleshooting docs to see if there are extra steps to install the gem on your system.

markjreed · 2014-10-21T13:59:36Z

Still seeing this issue trying to build 1.9.3 on Yosemite. The check in the ruby-build script assumes that the compiler used will be either cc or $CC, but if $CC is not set, the ruby 1.9.3 configure script will explicitly look for gcc and use that instead, causing a mismatch. Had to explicitly set CC=gcc purely for ruby-build's benefit, even though the ruby distro builds fine on its own without it.

lpar · 2014-10-21T14:19:36Z

1.9.3 is EOL in March, just FYI. If you're still building it for some reason, you might want to stop.

markjreed · 2014-10-21T14:39:12Z

Thanks, Ipar. Unfortunately, I still have to support systems that still depend on Ruby 1.9 (and break on 2.x), so it's convenient to be able to use rbenv to switch to 1.9 locally on my Mac as well. (We have a team working on replacing these systems and updating the things that depend on them, but can't spend too many resources on that effort, so it's going slowly, and meanwhile we still have to keep them running.)

rmehner · 2014-10-26T13:28:18Z

@lpar this happens with newer versions like 2.2.0-preview1 as well.

$CC is not set, both clang && gcc are installed, the latter one is linked to clang. Ruby's ./configure seems to pick up gcc (explained by @gnprice right here #319 (comment)), while ruby-build sets that CFLAG. Result:

$ rbenv install 2.2.0-preview1
[...]
checking whether CFLAGS is valid... no
configure: error: something wrong with CFLAGS=" -O3 -Wno-error=shorten-64-to-32  "
make: *** No targets specified and no makefile found.  Stop.

Workaround is to explicitly set $CC to either clang or gcc, like CC=clang rbenv install 2.2.0-preview1

A solution might be that ruby-build exports CC to a known value, like it does when you use require_gcc, but I'm not sure what side effects that might have.

rmehner · 2014-10-26T13:39:13Z

Turns out this is a known issue tracked in #651, which happens if you have apple-gcc4.2 installed as well on Yosemite.

Nakilon · 2015-10-11T16:09:28Z

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

$ ruby-build --version
ruby-build 20150818

mislav · 2015-10-11T18:26:29Z

@Nakilon That's strange. This is what ruby-build has right now:

if "${CC:-cc}" -x c /dev/null -E -Wno-error=shorten-64-to-32 &>/dev/null; then
  RUBY_CFLAGS="-O3 -Wno-error=shorten-64-to-32 $RUBY_CFLAGS"
fi

What state was your file in, and what did you have to remove?

lacostenycoder · 2015-12-30T18:20:38Z

I'm now having this issue, bundle install fails.

current directory: /Users/lancejordan/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/unf_ext-0.0.7.1/ext/unf_ext
/Users/lancejordan/.rbenv/versions/2.3.0/bin/ruby -r ./siteconf20151230-25006-12oc2t3.rb extconf.rb
checking for main() in -lstdc++... yes
creating Makefile

To see why this extension failed to compile, please check the mkmf.log which can be found here:

  /Users/lancejordan/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/extensions/x86_64-darwin-13/2.3.0-static/unf_ext-0.0.7.1/mkmf.log

current directory: /Users/lancejordan/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/unf_ext-0.0.7.1/ext/unf_ext
make "DESTDIR=" clean

current directory: /Users/lancejordan/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/unf_ext-0.0.7.1/ext/unf_ext
make "DESTDIR="
compiling unf.cc
g++: error: unrecognized command line option ‘-Wshorten-64-to-32’
g++: error: unrecognized command line option ‘-Wdivision-by-zero’
g++: error: unrecognized command line option ‘-Wextra-tokens’
make: *** [unf.o] Error 1

make failed, exit code 2

and

current directory: /Users/lancejordan/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/eventmachine-1.0.7/ext
/Users/lancejordan/.rbenv/versions/2.3.0/bin/ruby -r ./siteconf20151230-25006-1kq1ce.rb extconf.rb
checking for rb_trap_immediate in ruby.h,rubysig.h... no
checking for rb_thread_blocking_region()... no
checking for ruby/thread.h... yes
checking for rb_thread_call_without_gvl() in ruby/thread.h... yes
checking for inotify_init() in sys/inotify.h... no
checking for __NR_inotify_init in sys/syscall.h... no
checking for writev() in sys/uio.h... yes
checking for rb_thread_fd_select()... yes
checking for rb_fdset_t in ruby/intern.h... yes
checking for rb_wait_for_single_fd()... yes
checking for rb_enable_interrupt()... no
checking for rb_time_new()... yes
checking for sys/event.h... yes
checking for sys/queue.h... yes
checking for clock_gettime()... no
checking for gethrtime()... no
creating Makefile

To see why this extension failed to compile, please check the mkmf.log which can be found here:

  /Users/lancejordan/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/extensions/x86_64-darwin-13/2.3.0-static/eventmachine-1.0.7/mkmf.log

current directory: /Users/lancejordan/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/eventmachine-1.0.7/ext
make "DESTDIR=" clean

current directory: /Users/lancejordan/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/eventmachine-1.0.7/ext
make "DESTDIR="
compiling binder.cpp
g++: error: unrecognized command line option ‘-Wshorten-64-to-32’
g++: error: unrecognized command line option ‘-Wdivision-by-zero’
g++: error: unrecognized command line option ‘-Wextra-tokens’
make: *** [binder.o] Error 1

make failed, exit code 2

glaszig · 2016-05-04T00:04:55Z

@lacostenycoder did you find a solution for the unf_ext compilation error?

NuLL3rr0r · 2016-10-01T07:56:49Z

@lacostenycoder did you find a solution for the unf_ext compilation error?

I'm on FreeBSD and I have the same issue when I have gcc and clang installed at the same time. The default compiler is clang. Even explicitly setting CC to clang gives the same results:

$ CC=clang RUBY_CONFIGURE_OPTS=--with-opt-dir=/usr/local ruby-build 2.3.1 ~/.rubies/ruby-2.3.1
$ cd ~/discourse
$ bundle install --deployment --without test --without development
current directory:
/usr/home/discourse/discourse/vendor/bundle/ruby/2.3.0/gems/unf_ext-0.0.7.1/ext/unf_ext
make "DESTDIR="
compiling unf.cc
g++: error: unrecognized command line option '-Wshorten-64-to-32'
g++: error: unrecognized command line option '-Wdivision-by-zero'
g++: error: unrecognized command line option '-Wextra-tokens'
*** Error code 1

config.log shows the configure script recognizes clang and g++ at the same time. I'm not sure why the configure script mix up compilers. Removing gcc fixed that though.

lacostenycoder · 2016-10-01T20:04:38Z

@glaszig @NuLL3rr0r I'm on Mac OSX with Homebrew. My solution was centered around my $PATH variable to use my system defaults loading /usr/bin/* first
If I loaded /usr/local/bin first, that's when all would fail.

~ % g++ -v
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.3.0
Thread model: posix
~ % gcc -v
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.3.0
Thread model: posix
~ % clang -v
Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.3.0
Thread model: posix
~ % which gcc
/usr/bin/gcc
~ % which g++
/usr/bin/g++
~ % which clang
/usr/bin/clang
~ % which cc
/usr/bin/cc

Not sure if that helps but hopefully it sheds some kind of light.

NuLL3rr0r · 2016-10-04T09:41:57Z

@lacostenycoder thank you so much for the info. I'll try that next time to see what happens.

Thank you.

krakatoa mentioned this issue Mar 19, 2013

PACKAGE_CFLAGS lead to fiber errors #330

Closed

gnprice mentioned this issue Apr 2, 2013

Fix build failure when clang installed and not used #339

Merged

jeremy closed this as completed Apr 26, 2013

ghost mentioned this issue May 9, 2013

flapjack 0.7.0 fails to start on a Ubuntu 12.04.2 VM - stack level too deep flapjack/flapjack#133

Closed

Nakilon mentioned this issue Sep 6, 2015

gcc-4.9: error: unrecognized command line option '-V' on rbenv install 1.8.7-p374 rbenv/rbenv#778

Closed

kpkrishnamoorthy mentioned this issue Mar 12, 2016

v8 formula fails to install on Ubuntu 14.04 Linuxbrew/legacy-linuxbrew#917

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

gcc does not support "-Wno-error=shorten-64-to-32" #325

gcc does not support "-Wno-error=shorten-64-to-32" #325

quark-zju commented Mar 10, 2013

lpar commented Mar 14, 2013

Ivoz commented Mar 15, 2013

alexspeller commented Mar 20, 2013

quark-zju commented Mar 20, 2013

jeremy commented Apr 26, 2013

stantona commented May 29, 2014

mislav commented Jun 1, 2014

markjreed commented Oct 21, 2014

lpar commented Oct 21, 2014

markjreed commented Oct 21, 2014

rmehner commented Oct 26, 2014

rmehner commented Oct 26, 2014

Nakilon commented Oct 11, 2015

mislav commented Oct 11, 2015

lacostenycoder commented Dec 30, 2015

glaszig commented May 4, 2016

NuLL3rr0r commented Oct 1, 2016

lacostenycoder commented Oct 1, 2016

NuLL3rr0r commented Oct 4, 2016

gcc does not support "-Wno-error=shorten-64-to-32" #325

gcc does not support "-Wno-error=shorten-64-to-32" #325

Comments

quark-zju commented Mar 10, 2013

lpar commented Mar 14, 2013

Ivoz commented Mar 15, 2013

alexspeller commented Mar 20, 2013

quark-zju commented Mar 20, 2013

jeremy commented Apr 26, 2013

stantona commented May 29, 2014

mislav commented Jun 1, 2014

markjreed commented Oct 21, 2014

lpar commented Oct 21, 2014

markjreed commented Oct 21, 2014

rmehner commented Oct 26, 2014

rmehner commented Oct 26, 2014

Nakilon commented Oct 11, 2015

mislav commented Oct 11, 2015

lacostenycoder commented Dec 30, 2015

glaszig commented May 4, 2016

NuLL3rr0r commented Oct 1, 2016

lacostenycoder commented Oct 1, 2016

NuLL3rr0r commented Oct 4, 2016