Bug 50342 - gcc/configure fails on Mac OS X Lion/Xcode 4.1 with recent GCCs
Summary: gcc/configure fails on Mac OS X Lion/Xcode 4.1 with recent GCCs
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.6.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-09 13:48 UTC by simon
Modified: 2013-12-21 23:12 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2011-09-09 00:00:00


Attachments
May help to demonstrate failure mode (306 bytes, application/octet-stream)
2011-09-09 13:48 UTC, simon
Details

Note You need to log in before you can comment on or make changes to this bug.
Description simon 2011-09-09 13:48:03 UTC
Created attachment 25234 [details]
May help to demonstrate failure mode

When building with --enable-languages=c,ada you have to use an Ada-capable compiler, so you can't use Apple's. I used GCC 4.6.0.

This fails in gcc/configure; eg, from config.log,

    configure:5860: checking size of long long
    configure:5865: gcc -o conftest -g -fkeep-inline-functions conftest.c  >&5
    Undefined symbols for architecture x86_64:
      "___builtin___stpncpy_chk", referenced from:
          ___inline_stpncpy_chk in ccgrb5E9.o
    ld: symbol(s) not found for architecture x86_64

because Apple's gcc (4.2.1) has the builtin and GCC 4.6.0 doesn't.

I found that if I remove the -fkeep-inline-functions the configure succeeds (make check-ada, check-fortran, check-c++ were OK, I chopped check-c because it was swapping unacceptably).

I expect that if I could figure a way of passing -D_FORTIFY_SOURCE=0 to the gcc call at configure:5865 (presumably to other gcc calls as well; I know the 'checking size of' ones all fail but not so immediately fatally, you just get size of long = 0).

<string.h> says

#if defined (__GNUC__) && _FORTIFY_SOURCE > 0 && !defined (__cplusplus)
/* Security checking functions.  */
#include <secure/_string.h>
#endif

<_types.h> says

#ifndef _FORTIFY_SOURCE
#  if defined(__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__) && ((__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__-0) < 1050)
#    define _FORTIFY_SOURCE 0
#  else
#    define _FORTIFY_SOURCE 2	/* on by default */
#  endif
#endif

The attached code fails as above if compiled with FSF GCC and -fkeep-inline-functions unless you say -D_FORTIFY_SOURCE=0 .
Comment 1 Jack Howarth 2011-09-09 14:04:06 UTC
Apple's macports developers had similar comments in their recommendations for porting to Lion...

http://lists.macosforge.org/pipermail/macports-dev/2011-July/015263.html

5) Building with a compiler that doesn't support newer __builtins

If your port uses MacPorts compilers rather than the default compiler, you may run into trouble with string functions.  You'll see errors at link time about undefined __builtin_* functions.  If this happens, you may want to compile with -D_FORTIFY_SOURCE=0 to tell the headers to use unfortified versions which do not use compiler builtins.
Comment 2 Eric Botcazou 2011-09-09 15:19:35 UTC
Nothing to do with Ada per se.
Comment 3 Jack Howarth 2011-09-09 16:11:58 UTC
(In reply to comment #2)
> Nothing to do with Ada per se.

Other than only building ada triggers the bug. Should an separate enhancement request PR be opened for the addition of these new builtins to FSF gcc? I believe this was Mike Stump's recommendation awhile back when I first ran into this issue on Lion.
Comment 4 Eric Botcazou 2011-09-09 18:09:00 UTC
> Other than only building ada triggers the bug.

Huh?  How could Ada have something to do with the toplevel configure?
Comment 5 simon 2011-09-09 18:46:46 UTC
(In reply to comment #4)
> > Other than only building ada triggers the bug.
> 
> Huh?  How could Ada have something to do with the toplevel configure?

The problem only happens in gcc/configure (well, perhaps in other lower-level configures too).

It happens because if Ada's involved you must use an Ada-capable compiler, i.e. (FSF) GCC. For other languages, the response to this PR would rightly be "so use Apple's compiler".

Is there an approved way of getting CFLAGS="-D_FORTIFY_SOURCE=0" into the configure process? (there isn't AFAICT a problem with the actual build). I've tried

  ../gcc-4.6.1/configure host_configargs="CFLAGS=\"-D_FORTIFY_SOURCE=0\"" .....

which seems to work but is I think undocumented? (and hairy)

On the other hand, we could reconsider -fkeep-inline-functions in the configure scripts? The problem arises because the unsupported inlined builtin call is (effectively) in <string.h>, so we don't need to actually call it.
Comment 6 simon 2011-09-09 18:49:27 UTC
(In reply to comment #3)

> Should an separate enhancement
> request PR be opened for the addition of these new builtins to FSF gcc? I
> believe this was Mike Stump's recommendation awhile back when I first ran into
> this issue on Lion.

That would have to be separate, I think, because it wouldn't fix the bootstrap issue this time round.
Comment 7 Eric Botcazou 2011-09-09 18:56:19 UTC
> Is there an approved way of getting CFLAGS="-D_FORTIFY_SOURCE=0" into the
> configure process? (there isn't AFAICT a problem with the actual build). I've
> tried
> 
>   ../gcc-4.6.1/configure host_configargs="CFLAGS=\"-D_FORTIFY_SOURCE=0\"" .....
> 
> which seems to work but is I think undocumented? (and hairy)

Try CC="gcc -D_FORTIFY_SOURCE=0" $srcdir/configure

> On the other hand, we could reconsider -fkeep-inline-functions in the configure
> scripts? The problem arises because the unsupported inlined builtin call is
> (effectively) in <string.h>, so we don't need to actually call it.

On Darwin, possibly, but otherwise I don't see any good reason to do that.
Comment 8 simon 2011-09-09 19:50:05 UTC
(In reply to comment #7)

> Try CC="gcc -D_FORTIFY_SOURCE=0" $srcdir/configure

Works. Works better if you say

  $srcdir/configure CC="gcc -D_FORTIFY_SOURCE=0"

(then you don't need to say 'CC="gcc -D_FORTIFY_SOURCE=0" make').

> > On the other hand, we could reconsider -fkeep-inline-functions in the configure
> > scripts? The problem arises because the unsupported inlined builtin call is
> > (effectively) in <string.h>, so we don't need to actually call it.
> 
> On Darwin, possibly, but otherwise I don't see any good reason to do that.

I suppose it might happen if say Red Hat decided to add builtins to their system compiler/includes. But I agree, fairly unlikely. Also, I see you went through a lot of pain in PR bootstrap/18058 putting -fkeep-inline-functions into configure!
Comment 9 simon 2012-05-07 21:13:48 UTC
(In reply to comment #8)

>   $srcdir/configure CC="gcc -D_FORTIFY_SOURCE=0”

Unfortunately doing this means that “gcc -v” with the built compiler contains the ‘CC="gcc -D_FORTIFY_SOURCE=0”’ text in the Configured with: line, which confuses gprconfig (part of AdaCore’s gprbuild tool). So the way I’ve adopted for 4.7.0 is to start by

$ export CC="gcc -D_FORTIFY_SOURCE=0”
$ $srcdir/configure ...
$ make
Comment 10 mrs@gcc.gnu.org 2012-05-08 01:36:11 UTC
I'm wondering if you could add:

# Work around PR50342
BOOT_CFLAGS += -D_FORTIFY_SOURCE=0

to config/mh-darwin and fix the issue.  If so, I think that might be the best solution for now.  I think this should be safe for ppc and older and newer OSes.  If there comes a time when everything just works, the line can be removed later.  Let me know.
Comment 11 simon 2012-05-08 20:01:50 UTC
(In reply to comment #10)
> I'm wondering if you could add:
> 
> # Work around PR50342
> BOOT_CFLAGS += -D_FORTIFY_SOURCE=0
> 
> to config/mh-darwin and fix the issue.  If so, I think that might be the best
> solution for now.  I think this should be safe for ppc and older and newer
> OSes.  If there comes a time when everything just works, the line can be
> removed later.  Let me know.

Tried that and it made no difference. This is in a 4.7.0 download. Should I have re-run any of the autoconf etc tools after changing mh-darwin? Or is it that the problem occurs during gcc/configure rather than in the compiler bootstrap?
Comment 12 Matt Fago 2013-01-14 19:35:43 UTC
FYI, I recently ran into this issue as well building gcc 4.7.2 on MacOS 10.7.5 with XCode 4.1 installed.

Configured via:
../gcc-4.7.2/configure --enable-languages=c,c++,fortran --enable-lto \
  --program-suffix=-4.7 --enable-checking=release

This command will use Apple's gcc 4.2.1. Bootstrap fails due to an ICE (I believe during the glibc build). 

First setting:

export CC="gcc-4.4"
export CXX="g++-4.4"

fails with the error described in this bug report, while including -D_FORTIFY_SOURCE=0 in the above exports allows gcc to bootstrap.
Comment 13 Jack Howarth 2013-01-14 21:58:40 UTC
(In reply to comment #12)
> FYI, I recently ran into this issue as well building gcc 4.7.2 on MacOS 10.7.5
> with XCode 4.1 installed.
> 
> Configured via:
> ../gcc-4.7.2/configure --enable-languages=c,c++,fortran --enable-lto \
>   --program-suffix=-4.7 --enable-checking=release
> 
> This command will use Apple's gcc 4.2.1. Bootstrap fails due to an ICE (I
> believe during the glibc build). 
> 
> First setting:
> 
> export CC="gcc-4.4"
> export CXX="g++-4.4"
> 
> fails with the error described in this bug report, while including
> -D_FORTIFY_SOURCE=0 in the above exports allows gcc to bootstrap.

Make sure you have run 'make check' on the gmp build you installed. The earlier gmp 5.0.x releases had issues with the change to the llvm-gcc compiler in Xcode 4.1. FYI, since you are on Lion, you can upgrade to Xcode 4.5.2 which provides a very stable clang compiler as the system cc/cxx compiler.
Comment 14 simon 2013-01-31 20:35:01 UTC
The original problem doesn't occur with gcc version 4.8.0 20130131 (experimental) [trunk revision 195611] (GCC), built with GNAT GPL 2012.
Comment 15 Jack Howarth 2013-01-31 21:00:22 UTC
(In reply to comment #14)
> The original problem doesn't occur with gcc version 4.8.0 20130131
> (experimental) [trunk revision 195611] (GCC), built with GNAT GPL 2012.

Probably fixed at http://gcc.gnu.org/viewcvs?view=revision&revision=182378.
Comment 16 Dominique d'Humieres 2013-12-21 23:12:28 UTC
(In reply to comment #15)
> > The original problem doesn't occur with gcc version 4.8.0 20130131
> > (experimental) [trunk revision 195611] (GCC), built with GNAT GPL 2012.
>
> Probably fixed at http://gcc.gnu.org/viewcvs?view=revision&revision=182378.

Working link http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=182378.

So closing as FIXED.