Bug #3002: Hardcoded "gcc" in generated Ruby Makefile

• Status: Closed
• Assignee: -
• ruby -v: ruby 1.9.1p378 (2010-01-10 revision 26273) [i386-mingw32]

[jonforums (Jon Forums)]

=begin
In the configure generated Ruby Makefile on my mingw/windows system I get

CC = gcc
...
LDSHARED = gcc -shared $(if $(filter-out -g -g0,$(debugflags)),,-s)

Nowhere else in the Makefile is "gcc" hardcoded. Is the hardcoded "gcc" in LDSHARED intentional? If yes, why? If no, please fix.

Thanks, Jon
=end

[darix (Marcus Rückert)]

=begin
On 2010-03-24 07:27:41 +0900, Jon Forums wrote:

Bug #3002: Hardcoded "gcc" in generated Ruby Makefile
http://redmine.ruby-lang.org/issues/show/3002

Author: Jon Forums
Status: Open, Priority: Normal
Category: build
ruby -v: ruby 1.9.1p378 (2010-01-10 revision 26273) [i386-mingw32]

In the configure generated Ruby Makefile on my mingw/windows system I get

CC = gcc
...
LDSHARED = gcc -shared $(if $(filter-out -g -g0,$(debugflags)),,-s)

Nowhere else in the Makefile is "gcc" hardcoded. Is the hardcoded "gcc" in LDSHARED intentional? If yes, why? If no, please fix.

i think those values come from rbconfig.rb, which is generated from the
build environment.

so nothing to fix here.

 darix

--
openSUSE - SUSE Linux is my linux
openSUSE is good for you
www.opensuse.org

=end

[luislavena (Luis Lavena)]

=begin
darix,

I would disagree on your statement.

A Makefile generated by configure (autoconf) has the options to override CC, LD, RANLIB, AR and CXX by default.

That is true to compile Ruby, and the information is collected in rbconfig for later usage by mkmf

The problem is that the generated Makefile from mkmf uses the hardcoded compiler instead of honor the override nature of the autoconf makefiles, making hard to switch gcc for llvm-gcc as compiler front-end

And yes, llvm-gcc can build and work as replacement of gcc without any change, except the above hardcoded information.

llvm-gcc has been very helpful for a couple of projects to trace pointer and possible segmentation failures during development.

The change in the way rbconfig and mkmf uses LDSHARED's compiler definition will ease that path.

Thank you

Luis Lavena

=end

[naruse (Yui NARUSE)]

=begin
extconf.rb uses runnning ruby's RbConfig::MAKEFILE_CONFIG.

Also note that you can specify compiler when you run configure with --without-gcc to compile ruby.
=end

[luislavena (Luis Lavena)]

=begin
Thank you Yui,

The question is why the usage of hardcoded gcc data in LDSHARED:

C:\Users\Luis>ruby -r rbconfig -e "puts RbConfig::MAKEFILE_CONFIG['LDSHARED']
gcc -shared $(if $(filter-out -g -g0,$(debugflags)),,-s)

Instead of $(CC) as any other sanitiez Makefile generated by autoconf

We are not talking about the Ruby configure process itself but the Makefile generates for extensions (extconf) using mkmf.

Thank you

=end

[jonforums (Jon Forums)]

=begin
Other points for consideration:

1. The requested fix is to update configure.in and/or Makefile.in to create a Makefile with the following LDSHARED. I don't speak autotools, but I believe http://github.com/ruby/ruby/blob/trunk/configure.in#L1815 and/or http://github.com/ruby/ruby/blob/trunk/Makefile.in#L61 is the place to start

   LDSHARED = $(CC) -shared $(if $(filter-out -g -g0,$(debugflags)),,-s)

2. The current autoconf/configure generated Makefile is inconsistent with respect to only CC. The requested fix simply cleans up that inconsistently in line with http://www.gnu.org/prep/standards/standards.html#Utilities-in-Makefiles I'm typically not a slavish follower of rules-for-rules-sake, I've learned the hard way of the value of these standards :)

3. Save experienced developers time and irritation. Anyone experienced with make/gcc tools that want's to experiment with different compilers will simply go in and fix the generated Makefile anyway. Any developer who has configured with one compiler but overrides the generated Makefile to use another compiler knows they're On-Their-Own :)

4. By enabling the Makefile's CC to be correctly overridden, interesting opportunities are now enabled as Luis pointed out with the llvm-gcc example.

5. I don't believe the requested fix sacrifices build safety or robustness in any way, but I'd like to hear specifics if anyone thinks it does.

Thank you for considering the requested fix.

Jon
=end

[jonforums (Jon Forums)]

=begin
Looks as if 27038 fixed it. Testing... Thanks Nobu.
=end

[nobu (Nobuyoshi Nakada)]

• Status changed from Open to Closed

=begin
fixed in r27031, r27032 and r27038.
=end