On 27 Nov 2008, at 01:13, Geoff Keating wrote:
On 26/11/2008, at 4:16 PM, Jack Howarth wrote:
On Wed, Nov 26, 2008 at 01:22:35PM -0800, Geoffrey Keating wrote:
Jack Howarth <[EMAIL PROTECTED]> writes:
Iain,
The use of the system libgcc simply won't work on Mac OS X 10.4.
The missing __Unwind_GetIPInfo only exists in libgcc_s.10.5.dylib
and not libgcc_s.10.4.dylib...
Replacing or modifying the system libgcc is not recommended and may
break in the next version of Mac OS X. It's not clear to me what
this
will mean for GCC development.
You can see the exact commands the regression tester used in the
build
log file at
<http://gcc.gnu.org/regtest/HEAD/native-lastbuild.txt.gzip>;
basically,
+ /Users/regress/tbox/svn-gcc/configure --prefix=/Users/regress/
tbox/objs --target=powerpc-apple-darwin8.5.0
+ make -j2 bootstrap
+ make -j2 -k check
No extra flags, no moving stuff around, nothing added or deleted
from
the GCC source tree; that would defeat the purpose of the regression
tester, which is to test the actual GCC in the repository. There is
some strangeness in the system configuration: GMP and MPFR are
installed in /usr/local as static libraries, and I seem to
remember the system is running with a modified kernel, containing a
patch which makes dejagnu work, which is why it's running 10.4.5.
10.4.11 is significantly different from 10.4.5 and from 10.5. I
believe it adds a shared libgcc and libstdc++. It may be that GCC
does not work on 10.4.11.
You can find the exact scripts the tester uses to run the build in
contrib/regression in the GCC source tree. The tester checks out
the
tree and runs the scripts from the checkout.
Geoff,
I think you misunderstood my intention with that statement. I
wasn't
suggesting that Iain move a libgcc.so.10.5.dylib onto a different
machine.
Rather I meant that the offending symbol, __Unwind_GetIPInfo, was
only added
to the system libgcc for 10.5 so that Tiger's system libgcc would
never
be able to provide it.
I should correct an earlier statement of mine: 10.4.11 does not add
a shared libgcc. My 10.4.5 machine has a shared libgcc which
indeed does not have __Unwind_GetIPInfo. However, this does not
prevent GCC building on it.
Geoff,
Thanks for pointing to the scripts; I'll examine them in more detail.
There was never a problem *building* gcc, nor is there apparently
any problem once installed to the correct place.
[ i.e. Once the compiler is installed (and it is used to generate
code from its installed position) everything is apparently OK.]
The problem was failures in "make check" (esp. with an uninstalled,
newly built, compiler)
the failures were caused by the fact that the newly-built libgcc was
not being found - and the symbol(s) are not present in /usr/lib/libgcc*
In fact, as far as g++ and libstdc++ tests are concerned, this was
apparently a temporary glitch and the test results are looking the
same as "regress" now.
===
However, I still find similar a problem with libgomp (see http://
gcc.gnu.org/ml/fortran/2008-11/msg00320.html )
This is repeatable on several machines...
.. so there is something I've got installed, or something I'm doing
differently (or wrong) and I'd like to get to the bottom of it. This
is a very time-consuming activity - it would be a shame to waste the
processor cycles and man-hours.
As far as the OS is concerned - I take care not to interfere with it;
any added stuff is in /opt, /sw, /xusr and very occasionally /usr/
local.
These are, however, in-use live systems with 3rd party apps and
drivers - so it's not impossible that something has been horked by
one of those.
FWIW I am using dejagnu-1-4-4 which seems to build and install
without any change or addition to OSX.
the PATH I use (on darwin8) for the configure/build/check is:
"/usr/local/dejagnu-1-4-4/bin:/bin:/sbin:/usr/bin:/usr/sbin"
I'm building GMP (4.2.4) and MPFR(2.3.2) in the gcc tree - but that
makes no material difference to the observation AFAICT.
thanks,
Iain
