--- Comment #18 from andreast at gcc dot gnu dot org 2008-12-08 20:34
---
Should be fixed:
http://gcc.gnu.org/ml/gcc-cvs/2008-12/msg00125.html
http://gcc.gnu.org/ml/gcc-cvs/2008-12/msg00124.html
http://gcc.gnu.org/ml/gcc-cvs/2008-12/msg00068.html
http://gcc.gnu.org/ml/gcc-cvs/2008-12/ms
--- Comment #17 from andreast at gcc dot gnu dot org 2008-11-30 08:22
---
http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg02671.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38314
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2008-11-30
00:57 ---
The problem was a dirty build directory. A clean bootstrap has completed and a
complete make check for -m32 and -m64 is underway under darwin10.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38314
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2008-11-29
21:28 ---
It may be due to another patch I was testing. I am doing a clean bootstrap
without the other patches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38314
--- Comment #14 from andreast at gcc dot gnu dot org 2008-11-29 21:20
---
gcc.o differing is severe, while *checksum.o depend on some version information
differing.
I propose to do a real clean build. No build over build.
My build on x86_64-apple-darwin9 is in the last stage, linking
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2008-11-29
21:09 ---
Why is it okay for cc1-checksum.o and cc1plus-checksum.o to differ but not
gcc.o?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38314
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2008-11-29
21:06 ---
The bootstrap is failing at...
make "DESTDIR=" "RPATH_ENVVAR=DYLD_LIBRARY_PATH"
"TARGET_SUBDIR=x86_64-apple-darwin10" "bindir=/Users/howarth/inst_gcc/bin"
"datadir=/Users/howarth/inst_gcc/share" "exec_pre
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2008-11-29
20:35 ---
Apple wasn't concerned about the multilib issue since they do everything as
lipo files. So I suspect it is rather academic on what we choice for the 32-bit
subdirectory name.
--
http://gcc.gnu.org/bug
--- Comment #10 from andreast at gcc dot gnu dot org 2008-11-29 20:24
---
At the time I did x86_64-apple-darwin* stuff I asked apple people if they
intend to do multilib on this target, the answer was no. So I did not bother
any longer.
I do not know if IA32 is correct. I use i386 for
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2008-11-29
20:11 ---
Andreas,
Can you try the proposed patch on darwin9 for the x86-64-apple-darwin9
target? I will do a complete make check on darwin10 with the
x86_64-apple-darwin10 triplet. I am surprised by this issue a
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2008-11-29
20:03 ---
Thanks! With your patch, gcc now makes it into stage 2 and is still building. I
would suggest we use...
MULTILIB_DIRNAMES = IA32
as Apple often using I386 but also builds for i686-apple-darwin as well.
I
--- Comment #7 from andreast at gcc dot gnu dot org 2008-11-29 19:31
---
A starting point would be this:
[wolfram:head/gcc/gcc] andreast% svn diff config/i386/t-darwin64
Index: config/i386/t-darwin64
===
--- config/i386/t-
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2008-11-29
19:23 ---
The uname output looks like a red herring. I substituted a script for uname
that executes...
#!/bin/sh
uname_aside "$@" | /usr/bin/sed 's/i386/x86_64/'
and the build still fails. I wonder if we could fix
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2008-11-29
18:44 ---
Ah, I see the problem in the config.log. The inaccurate output of uname under
the i386 kernel on a EMT64 chipset is confusing configure such that...
$ ../gcc/configure --prefix=/Users/howarth/inst_gcc
--
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2008-11-29
04:12 ---
../gcc/configure --prefix=/Users/howarth/inst_gcc
--enable-languages=c,c++,fortran,java --with-gmp=/sw --with-libiconv-prefix=/sw
--with-system-zlib --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6
15 matches
Mail list logo
