http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
Jackie Rosen jackie.rosen at hushmail dot com changed:
What|Removed |Added
CC|
--- Comment #33 from pinskia at gcc dot gnu dot org 2009-09-30 19:40
---
*** Bug 41525 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #34 from pinskia at gcc dot gnu dot org 2009-09-30 19:41
---
Fixed in 4.4.2.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #31 from fxcoudert at gcc dot gnu dot org 2009-09-09 08:15
---
Subject: Bug 41180
Author: fxcoudert
Date: Wed Sep 9 08:14:36 2009
New Revision: 151554
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151554
Log:
PR bootstrap/41180
*
--- Comment #32 from fxcoudert at gcc dot gnu dot org 2009-09-09 08:46
---
Subject: Bug 41180
Author: fxcoudert
Date: Wed Sep 9 08:46:32 2009
New Revision: 151555
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151555
Log:
PR bootstrap/41180
*
--- Comment #28 from joseph at codesourcery dot com 2009-09-03 11:04
---
Subject: Re: can not build gcc 4.4.1 on Snow Leopard
Mac OS X 10.6
On Thu, 3 Sep 2009, howarth at nitro dot med dot uc dot edu wrote:
Mike,
Regarding passing -m32 within the x86_64 host case, I was
--- Comment #30 from mrs at apple dot com 2009-09-04 01:49 ---
I admit that having gcc automagically add -m32 isn't strictly needed, the user
can do that. The problem is when they don't do that. What behavior do we
want? We can pick:
1) Just work.
2) Fail immediately, telling
--- Comment #21 from mrs at apple dot com 2009-09-02 20:37 ---
The patch in #19 is wrong. If you configure a x86-ppc64 compile, it would
want to use -m32, which is wrong. We experimented with a change like that in
#20 and it resulted in failures; I can't imagine any good coming from
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2009-09-02
21:44 ---
I should clarify that the proposed change in comment 20 only triggers if the
host is x86_64-apple-darwin* (which would be the case once the config,guess
change goes in) and will in that case only add -m32
--- Comment #22 from howarth at nitro dot med dot uc dot edu 2009-09-02
21:41 ---
Mike,
The fix in comment 20 originated from your email to me...
On Aug 28, 2009, at 8:48 AM, Jack Howarth wrote:
Can you take a look at PR41180 (specifically
comment 9). I think we should propose a
--- Comment #24 from howarth at nitro dot med dot uc dot edu 2009-09-02
22:22 ---
We could also add (as a separate patch) a change identical to what Apple uses
in their gcc which only triggers on the i[[3456789]]86-*-darwin* host and
target but this should be unnecessary after the
--- Comment #25 from howarth at nitro dot med dot uc dot edu 2009-09-02
23:37 ---
Mike,
I double checked and using tentative_cc doesn't results in a failure in
configure at...
checking for correct version of gmp.h... yes
checking for correct version of mpfr.h... yes
checking for
--- Comment #26 from mrs at apple dot com 2009-09-03 00:20 ---
First, config.guess is orthogonal to the entire discussion, because of that, we
never need to mention it again.
Next, we do a case analysis of every combination of host/target and buildÂ… We
engineer each case to work as
--- Comment #27 from howarth at nitro dot med dot uc dot edu 2009-09-03
00:56 ---
Mike,
Regarding passing -m32 within the x86_64 host case, I was considering the
case of trying to cross compile the i686-apple-darwin10 target on the
x86_64-apple-darwin10 host. While this sounds
--- Comment #16 from mrs at apple dot com 2009-08-31 17:37 ---
Oops, I mean #12 and #13. For #13, make sure there isn't an existing entry
already. If there is, the code should be added to it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
--- Comment #15 from mrs at apple dot com 2009-08-31 17:35 ---
#13 looks fine. #14 needs a build to confirm it works. I've tested the style
of #14 in the gcc-4.2.1 tree and it works as expected.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
--- Comment #17 from howarth at nitro dot med dot uc dot edu 2009-08-31
18:04 ---
Mike,
No, there isn't any host cases for i[[3456789]]86-*-darwin* in that section
of configure.ac only...
powerpc-*-darwin*)
host_makefile_frag=config/mh-ppc-darwin
;;
Interestingly, while
--- Comment #18 from mrs at apple dot com 2009-08-31 20:37 ---
That file just has:
# APPLE LOCAL file dynamic-no-pic
# The -mdynamic-no-pic ensures that the compiler executable is built without
# position-independent-code -- the usual default on Darwin.
BOOT_CFLAGS=-g -O2
--- Comment #19 from howarth at nitro dot med dot uc dot edu 2009-09-01
04:00 ---
Actually comment 14 has it backwards. If we implement the config.guess
correction so that the host reports the default code generation and execution
as x86_64-apple-darwin*, we would need something
--- Comment #20 from howarth at nitro dot med dot uc dot edu 2009-09-01
04:23 ---
This appears to do what we want on Snow Leopard in combination with the
config.guess patch...
Index: configure.ac
===
--- configure.ac
--- Comment #3 from redi at gcc dot gnu dot org 2009-08-28 10:23 ---
Changing component, nothing to do with c++ front end
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-08-28
13:28 ---
Remember that the compilers in Snow Leopard will execute as x86_64 code and
generate the same by default on EMT64 capable hardware. However the uname
output
will still report i386 unless you are running
--- Comment #5 from dmarkman at mac dot com 2009-08-28 14:36 ---
thanks for the answer. Here is what I did in the fresh new gcc-4.4.1 folder I
issued
./configure --prefix=/home/dmarkman/Development/GCC/macintel64/gcc-4.4.1/build
--enable-languages=c,c++
--- Comment #6 from dmarkman at mac dot com 2009-08-28 14:37 ---
thanks for the answer. Here is what I did in the fresh new gcc-4.4.1 folder I
issued
./configure --prefix=/home/dmarkman/Development/GCC/macintel64/gcc-4.4.1/build
--enable-languages=c,c++
--- Comment #7 from redi at gcc dot gnu dot org 2009-08-28 15:01 ---
it should be --build, not -build
as stated at http://gcc.gnu.org/install/configure.html do NOT build in the
source directory, create a new directory to build in and run $SRCDIR/configure
instead of ./configure
--
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-08-28
15:12 ---
Actually this is a bug in Xcode 3.2's linker that I wasn't able to get Apple to
fix (radar 6320843) duplicate symbols from static libraries not properly
ignored. The fix for gcc 4.4.1 and trunk is to apply
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2009-08-28
15:31 ---
Back to the issue of configure not properly detecting the target as
x86_64-apple-darwin10 but grabbing i386-apple-darwin10 instead, one
possible fix would be to have configure use 'sysctl -n
--- Comment #10 from mrs at gcc dot gnu dot org 2009-08-28 16:14 ---
When one builds with CC='gcc -m32', would be nice for config.guess to know this
is i686-apple-darwin10. When using CC='gcc -m64', would be nice for
config.guess to know this is x86_64-apple-darwin10. If ones makes
--- Comment #11 from dmarkman at mac dot com 2009-08-28 17:28 ---
thank you very much for all your comments
first of all I fixed my typo and used --build instead of -build
but that wasn't a problem
after modifying Make-lang.in from gcc/cp folder (as Jack Howarth suggested)
I was able to
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2009-08-29
01:32 ---
The following patch generated under gcc 4.4 branch is a first pass at
correcting the default triplet detected under darwin10...
Index: config.guess
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2009-08-29
01:40 ---
Opps, the corrected proposed patch is...
Index: config.guess
===
--- config.guess(revision 151196)
+++ config.guess(working
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2009-08-29
02:19 ---
We also need to make sure that the i[[3456789]]86-*-darwin* target pass -m32 to
the compiler when building on Snow Leopard. This patch is untested but I
believe is in the right direction...
Index:
32 matches
Mail list logo
