On Wednesday 02 July 2008, S?rgio Durigan J?nior wrote:
> On Wed, 2008-07-02 at 16:55 +0200, Marc Haisenko wrote:
> > On Wednesday 02 July 2008, S?rgio Durigan J?nior wrote:
> > > Honestly, I don't think the '-m64' flag belongs there because it should
> > > somehow "trust" in the compiler bitness and assume that it will
> > > generate executable files with XX bits (being XX the bitness of the
> > > archtecture). Also, if the user specify its own CFLAGS, it can occur an
> > > inconsistency because of that choice made by mkmf (for example, if the
> > > user specified '-m32' in this case).
> >
> > Not quite: if Ruby is compiled with -m64 and you compile your extension
> > with -m32 I don't think it will load.
>
> Good point.
>
> > That being said, I also miss not being able to override mkmf.rb's values.
> > It's a pain e.g. on OpenSolaris where the values can be problematic (e.g.
> > CC pointing to some compiler I don't have).
>
> Hmm, my case is that: I'm running a biarch system here (64-bit kernel,
> with mixed 32- and 64-bit apps), so my compiler defaults to 32-bit
> generated objects (if I ever want to compile something for 64-bit, I
> need to provide the '-m64' flag). As a part of my job, I need to
> guarantee that some apps correctly compile over PPC *and* PPC64, that's
> why I need to switch between '-m32' and '-m64'. Therefore, I myself will
> provide those flags to the build system, and that's the reason why I
> don't want it to assume anything about bitness :-)

But the value provided by Ruby's rbconfig.rb is the one about the bitness of 
Ruby itself (those values are determined at "configure" time, IIRC), so if 
you need to compile a Ruby extension at least those flags are really 
important to pick up.

Bye,
	Marc

-- 
Marc Haisenko

Comdasys AG
R?desheimer Str. 7
80686 M?nchen
Germany

Tel.: +49 (0)89 548 433 321