Brad,
If you google "dyld: Symbol not found: ___dso_handle", you'll
come up with the following messages...
http://gcc.gnu.org/ml/gcc/2006-03/msg00712.html
http://gcc.gnu.org/ml/gcc/2006-03/msg00718.html
http://gcc.gnu.org/ml/gcc/2006-03/msg00735.html
So it certainly sounds like your cctools i
Brad,
You build system certainly has issues. Why don't you strip
down your .cshrc or .bashrc to a completely empty file, open
a new terminal session so none of the previous .cshrc settings
are in effect and rebuild gcc trunk. Also, I am assuming you
are running MacOS X 10.4 and have at least Xco
On Aug 30, 2006, at 9:55 PM, Jack Howarth wrote:
Try building
some of the g++ testcases manually and see what the errors
are.
Perhaps this is a problem:
grep 'Symbol not found' g++.log | sort | uniq -c
1254 dyld: Symbol not found: ___dso_handle
Bradley,
Something still is as astray with your build configuration.
Look at my last set of results.
http://gcc.gnu.org/ml/gcc-testresults/2006-08/msg01333.html
I only have 28 unexpected failures for g++ at -m64 and you
have 1350. Likewise for libstdc++ at -m64, I only have 6
unexpected fail
After some discussion with Jack Howarth, I have found that the
gfortran and libgomp executable tests on powerpc-apple-darwin8.7.0
(at least) do not link the correct, just-built-using-"make
bootstrap", libraries until those libraries have first been installed
in $prefix/lib/...
I filed a b
I've posted the results of last night's build of gcc trunk
on my dual G5 using Geoff's TImode patch and changes to
prune.exp to suppress the failures from the ld64 linker
warnings.
Jack
Mike,
Sure. I am actually doing a build right now to demonstrate the
baseline we have for c, c++, and fortran with just the TImode patch
and the prune.exp patches I use. Hmm, regress is a G4...surely you
can find a G5 laying around Apple to replace it with since PowerPC
is so passe there (grin).
On Aug 28, 2006, at 5:08 PM, Jack Howarth wrote:
Okay. How about this. Have regress set to at least do a -m64 make
check once a week.
I think it is a G4, so testing G5 code-gen might have to wait until
the G5 emulator is done. :-)
Can you contribute G5 results once a week?
At least that
Mike,
Okay. How about this. Have regress set to at least do
a -m64 make check once a week. At least that would show
some interest in the status of gcc at 64-bit. It is baffling
to most people how we can make any progress on such issues
if the status isn't sampled at least once every blue moon.
On Aug 28, 2006, at 3:57 PM, Jack Howarth wrote:
> If we can't speed up the testing
? -j2 makes testing go faster as well.
Sigh, I misstated that one. My comment in that case was about the
general case. I meant to say that -j2 is as applicable to testing as
it is to buil
Mike,
Now I totally confused. Are you saying that '-j 2' only speeds up
testing but not builds? In one sentence you say it won't speed things up
and in the next you say of course it speeds things up. Which is it?
Jack
On Aug 28, 2006, at 3:32 PM, Jack Howarth wrote:
On Aug 28, 2006, at 3:32 PM, Jack Howarth wrote:
Well then alternatively, might not 'make -j 2' increase the rate at
which gcc is built on regress?
Yes, we know about -j2. When I said, sorry, nope, I meant to convey
the idea that in fact that adding a -j2 won't speed it up.
Or doesn't Da
Mike,
Well then alternatively, might not 'make -j 2' increase
the rate at which gcc is built on regress? Or doesn't Darwin
support parallel builds? If we can't speed up the testing
then we could at least speed up the build process to free
up time for -m64. After all, we are already building -m6
On Aug 28, 2006, at 1:20 PM, Jack Howarth wrote:
Might that not increase the rate of testing on regress?
Sorry, nope.
Mike,
Do you know if regress is used for anything other than building
and checking gcc? Also is it a dual G5 by any chance? I ask because
it is unclear if regress is doing a 'make -k -j 2 check' or not?
Might that not increase the rate of testing on regress? I haven't
tried that myself because I
On Aug 27, 2006, at 7:24 AM, Jack Howarth wrote:
Can one of you remind me who we need to lobby at Apple
In the gcc project, contributions are generally speaking, made by an
individual. Geoff operates a regression tester, probably the one
you're thinking of. In the past, he has considered
Brad,
I was confusing your use of -mcpu=970 in the make check with the
build flags...sorry. You might stop using that flag for now until
you get a baseline of how many additional failures seen in -m64
compared to -m32 are not due to the linker warnings (after you
apply the TImode patch). I'll l
On Aug 28, 2006, at 12:10 PM, Jack Howarth wrote:
Why don't you try a normal multi-lib build without any
extra flags.
What extra flags? The configure command is
../configure --prefix=/pkgs/gcc-mainline --with-gmp=/opt/local/ --
with-mpfr=/opt/local/
which is totally generic (one need
Brad,
Why don't you try a normal multi-lib build without any
extra flags. At the moment, considering how much noise is on
the testsuite results on Darwin due to this linker warnings, I
don't think its really helpful to bother exploring corner cases
of building gcc trunk with unique flags. Make s
When I run bootstrap and "make check", I check the -m64 option
(only). Check gcc-testresults.
Currently, the results don't look very good. Maybe I'm doing
something wrong.
Brad
20 matches
Mail list logo
