Re: Wrapper dylib to fix OSX libBLAS & libLAPACK with -m64 (Re: 3.5.0+ compiled on Mac OSX 10.6.6)

[Richard Campbell]

On Jan 31, 2011, at 1:01 AM, Jarno Rajahalme wrote:

> 
> On Jan 28, 2011, at 22:02 , ext Richard Campbell wrote:
>> So it turns out I had preemptively tried --enable-64 last time. I got rid of 
>> it and it successfully built. But it doesn't run:
>> 
>> [cara:~/Downloads/octave-3.3.54] xnk% ./run-octave
>> dyld: Symbol not found: 
>> __ZNSt15basic_stringbufIcSt11char_traitsIcESaIcEE7seekoffElSt12_Ios_SeekdirSt13_Ios_Openmode
>> Referenced from: 
>> /Users/xnk/Downloads/octave-3.3.54/src/.libs/liboctinterp-3.3.54.dylib
>> Expected in: flat namespace
>> in /Users/xnk/Downloads/octave-3.3.54/src/.libs/liboctinterp-3.3.54.dylib
>> Trace/BPT trap
>> 
> 
> You need to update the gnulib you are using. This exact bug has been fixed 
> since November 24, 2010 (same problem with GCC 4.2, 4.3, and 4.4):
> 
> 2010-11-24  Paul Eggert  <address@hidden>
> 
>       stdint: port to GCC 4.3 + OSX + Octave
>       On this platform, stdint.h is buggy and defines int64_t to long
>       long int.  The replacement defined it to long int, causing
>       problems with C++ style name mangling.  Instead, trust the system
>       definition if INT64_MAX is defined, and likewise for the unsigned
>       variant.   Problem reported by Jarno Rajahalme in
>       <http://lists.gnu.org/archive/html/bug-gnulib/2010-04/msg00143.html>.
>       * lib/stdint.in.h (GL_INT64_T): Define if INT64_MAX is defined,
>       and don't mess with int64_t and INT64_MAX in this case.
>       (GL_UINT64_T): Likewise for UINT64_MAX and uint64_t.
> 
> The procedure is like this:
> 
> cd <your-octave-source-directory>
> make distclean
> cd gnulib
> git pull
> cd ..
> gnulib/gnulib-tool --add-import
> ./autogen.sh
> ./configure --prefix=<prefix-where-to-install-octave> <other config options>
> make -j2 check
> 
>  Jarno
> 
> 


This is not going to work for me. As per my earlier messages, I am trying to do 
this without any package managers and a minimum of third party replacements for 
the libraries that come installed on every Mac. I am using gcc 4.2.1 as 
released by Apple, and gfortran 4.2.3 as released by AT&T for compatibility 
with Apple's gcc build. There should be a workaround within the Octave source.

Campbell