From: Eric Sunshine <sunshine@...>
Date: 2003-11-30T19:12:31+09:00
Subject: Re: configure.in: do not override CCDLDFLAGS, LDFLAGS, XLDFLAGS

Hello,

On Sun, 30 Nov 2003 09:33:03 +0000, eban wrote:
> * configure.in: XCFLAGS for compiling ruby itself.  ARCH_FLAG is
> reflected in CFLAGS.

Unfortunately, this change breaks the Apple/NeXT builds when the  
--enable-fat-binary configure option is used.  The problem is that that  
ARCH_FLAGS is only valid when invoking the compiler (cc).  It is not valid  
when invoking the C-preprocessor (cpp or cc -E), and causes the pre-processor  
to abort prematurely.  For example:

% cc -E -arch i386 -arch m68k foo.c
cc: Cannot use -E, -M, -MM, or -S with multiple architectures

% /lib/cpp -E -arch i386 -arch m68k foo.c
/lib/cpp: more than one -arch option (not allowed)

This problem manifests when extconf.rb scripts invoke have_header(); in  
fact, it causes all tests which ultimately invoke mkmf.rb's cpp_command(),  
such as macro_defined?, egrep_cpp(), etc., to fail.  As a result, this change  
will prevent most extension modules from building when -enable-fat-binary is  
used.

There are at least two obvious solutions for this problem:

(1) Keep ARCH_FLAGS (or XCFLAGS) separate; do not merge it into CFLAGS.   
This allows mkmf's cpp_command() to use only CFLAGS, while cc_command() can  
use both CFLAGS and ARCH_FLAGS (or XCFLAGS).

(2) Augment cpp_command() to filter out values from ARCH_FLAGS.  This seems  
like a nasty, special-case hack.

When submitting the patch to revive the NeXT ports, I chose option #1 in  
order to solve this problem.  If option #1 is indeed not acceptable, then  
perhaps some other solution can be devised?

-- ES