Geoff,
If the autoconf patch isn't going in to gcc trunk, would someone
at Apple please nudge the folks who maintain www.opensource.apple.com
to post the Xcode Tools 2.4 source code release? Either than or post
a new cctools based off the same to the gcc ftp site. We really need
to be able to cr
On 10/09/2006, at 6:48 AM, Jack Howarth wrote:
Eric,
You definitely want the autoconf patch added
in otherwise builds of libgfortran will crash
when older cctools are used (like Xcode 2.3).
Typically what we do is just say that GCC requires a later version of
cctools.
smime.p7s
Descr
Eric,
You definitely want the autoconf patch added
in otherwise builds of libgfortran will crash
when older cctools are used (like Xcode 2.3).
I'll try a build of current gcc trunk with
your new darwin.c correction but without
the autoconf patch to see if all the literal16
support exists in Xco
Shantonu Sen wrote:
That's not correct. The linker support only exists in ld64 for Xcode
2.4. It fails like this for ld(32). 32-bit Darwin targets shouldn't be
using this assembly feature...
Right, I knew that. Looks like I have a typo though. Bah.
I'll fix it shortly. Though nothing wrong
That's not correct. The linker support only exists in ld64 for Xcode
2.4. It fails like this for ld(32). 32-bit Darwin targets shouldn't be
using this assembly feature...
Shantonu
On Sep 9, 2006, at 12:16 PM, Eric Christopher wrote:
Using the cctools from Xcode 2.4, the failure changes an
Jack Howarth wrote:
Eric,
One last question. Is it correct to assume that when
the newer cctools with the literal16 support becomes
available, things like 'integer(16)' will become available
in gfortran for darwin?
Seems reasonable to expect that it could be made to happen.
-eric
Eric,
One last question. Is it correct to assume that when
the newer cctools with the literal16 support becomes
available, things like 'integer(16)' will become available
in gfortran for darwin?
Jack
Using the cctools from Xcode 2.4, the failure changes and moves to the linkage
of libgfortran itself...
ld: .libs/maxloc0_4_r16.o unknown flags (type) of section 2
(__TEXT,__literal16) in load command 0
ld: .libs/maxloc0_8_r16.o unknown flags (type) of section 2
(__TEXT,__literal16) in load c
My original attempt to build gcc trunk yesterday used the
cctools from Xcode 2.3 and produced the failure...
/bin/sh ./libtool --mode=compile /sw/src/fink.build/gcc4-4.1.999-20060908/darwin
_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc4-4.1.999-20060908/darwin_objdir/./gc
c/ -B/sw/lib/gcc4/powerp
Okay. The problem with the libgfortran build failing is
unrelated to the remaining sections of the TImode patch.
I see the same failure with an unpatched version of current
gcc trunk. Time to file a PR.
Jack
ps I am currently building (for the last couple of days)
with --disable-boo
I should add that the last good build I have is from last
night at revision r116774.
Jack
To correct the typo in the last message, I am now rebuilding
without the reduced TImode patch to confirm it is not at fault.
As I said, since the build craps out in the 32-bit sections, I
doubt it is the source of the libgfortran build failure.
Jack
I don't know if this is related to Eric's checkins tonight
but I can no longer build libgfortran on Darwin PPC. The build fails
at...
/bin/sh ./libtool --mode=compile /sw/src/fink.build/gcc4-4.1.999-20060908/darwin
_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc4-4.1.999-20060908/darwin_objdir/./g
13 matches
Mail list logo
