Re: build trouble on MacOS 10.5

[Ben Abbott]

On Dec 20, 2009, at 2:34 PM, Rob Mahurin wrote:

> On Sun, Dec 20, 2009 at 01:29:26PM -0500, Ben Abbott wrote:
>> On Dec 20, 2009, at 12:30 PM, Rob Mahurin wrote:
>>> On Sat, Dec 19, 2009 at 11:52:45PM -0500, Ben Abbott wrote:
>>>> I've assumed the bus error is a result of conflicting dylibs. Thus,
>>>> I wrote a simple script to list those being linked to so that I may
>>>> visually inspect them for conflicts.
>>>> 
>>>> For 10.6.2 I see conflicts for libiconv, libfontconfig, and
>>>> libfreetype (maybe others as well, but I'm done looking today).
>>>> 
>>>> Perhaps we can eliminate suspects by comparing results?
>>>> 
>>>> For comparison, I've included my result.
>>> 
>>> Here's my output from your script.  How should I interpret this?
>>> 
>>> Rob
>>> <dylib_output.txt>
>> 
>> My understanding is that conflicting version of libraries are a
>> problem. If I include FLTK in my build, I have libstdc++.dylib from
>> both gcc 4.2.1 and gcc 4.4.2 ... which *might* create troubles, but
>> that does not appear to be my problem (or yours).
>> 
>> You are linking against libgcc_s.1.dylib from Apple's gcc 4.0.2 (?)
>> and MacPorts gcc 4.3.? ... while I'm linking against Apples gcc
>> 4.2.1 and Finks gcc 4.4.2.
> 
> I have 
> 
>       $ /usr/bin/gcc --version ## from apple
>       i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493)
>       $ /opt/local/bin/gcc-mp-4.3 --version ## from macports
>       gcc-mp-4.3 (GCC) 4.3.4
> 
>> I'm not expert in interpreting the back trace, but if I understand correctly 
>> ...
>> 
>>      http://www.caf.dk/cafonly/gnu/gdb/gdb_42.html
>> 
>> ... the bus error for your occurs in 
>> 
>>      #0  0x03ca4156 in __gnu_cxx::__exchange_and_add ()
>>      #1  0x03c48526 in std::locale::operator= ()
>> 
>> ... and for me, in close proximity to your example 
>> 
>>      #0  0x0282902f in std::locale::operator= ()
>> 
>> I'm not sure what "std::locale::operator= ()" refers to, but I'd
>> guess it is either libstdc++.6.dylib or maybe libgcc_s.1.dylib. Any
>> thoughts?
> 
> I agree that the crash seems to happen in the same place, but I don't
> understand much more than that.
> 
> On the theory that it's a library conflict, I complied with 
> 
>       ./configure CC=gcc-mp-4.3 CXX=g++-mp-4.3 F77=gfortran-mp-4.3
>       LDFLAGS=-L/opt/local/lib --without-framework-carbon
>       --without-qhull --without-z --without-hdf5 --without-fftw3
>       --without-fftw3f --without-glpk --without-curl
>       --without-framework-opengl --without-qrupdate --without-amd
>       --without-camd --without-colamd --without-ccolamd
>       --without-cholmod --without-cxsparse --without-umfpack
>       --without-arpack --disable-readline
> 
> That gives me a run-octave that runs without crashing.  My build fails
> with
> 
>       Making all in interpreter
>       ../../run-octave -f -q -H -p . --eval "geometryimages ('voronoi', 
> 'eps');"
>       error: `d_typ' undefined near line 152 column 38
>       error: evaluating argument list element number 2
>       error: called from:
>       error:   
> /Users/rob/src/octave-all/octave-hg/doc/interpreter/geometryimages.m at line 
> 152, column 7
>       error:   
> /Users/rob/src/octave-all/octave-hg/doc/interpreter/geometryimages.m at line 
> 35, column 5
> 
>       make[3]: *** [voronoi.eps] Error 1
> 
> and that error goes away if I make the change in the attached patch.
> Now the build succeeds.  
> 
>       $ make check
>         src/DLD-FUNCTIONS/convhulln.cc ......................... PASS    0/2  
>   FAIL 2
>         src/mappers.cc ......................................... PASS  
> 257/258  FAIL 1
>         scripts/specfun/beta.m ................................. ***MESSAGE 
> FROM ROUTINE DGAMMA IN LIBRARY SLATEC.
>        ***FATAL ERROR, PROG ABORTED, TRACEBACK REQUESTED
>        *  X IS 0
>        *  ERROR NUMBER = 4
>        *   
>        ***END OF MESSAGE
>        
>        ***JOB ABORT DUE TO FATAL ERROR.
>       0          ERROR MESSAGE SUMMARY
>        LIBRARY    SUBROUTINE MESSAGE START             NERR     LEVEL     
> COUNT
>        SLATEC     DGAMMA     X IS 0                       4         2         
> 1
>       
>        PASS    5/6    FAIL 1
>         test_io.m .............................................. PASS   67/68 
>   FAIL 1
>       
>       Summary:
>       
>         PASS   5321
>         FAIL      5
> 
> 
> The output of your library script on this runnable octave is
> attached.  Do you see what is different?  
> 
> I will start adding libraries one at a time and see where the problem
> comes back.
> 
> Cheers,
> Rob
> <geometryiamges.patch><dylib_output.bare.txt>

It looks to me like there remain more two versions of both libgcc_s and 
libstdc++.

Maybe we should see if it is just one of the libraries that is responsible. 
Perhaps multiple builds with just one of the --without-foobar will tell us 
which one is the problem?

BTW, you mention that run-octave didn't crash. I assume you mean you can run 
and then quit without error?

Ben