__Unwind_GetIPInfo on Darwin 8.11

[IainS]

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 <howarth@bromo.med.uc.edu> 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