Succees on OSX 64-bit with development branch

[Jarno Rajahalme]

I finally managed to build octave development branch on 64-bit OSX 10.6.3 with 
the recent Xcode 3.2.2.

The only patch that is needed is this one, by Ben Abbott, I recall:

diff -r 6538ff562949 m4/acx_pthread.m4
--- a/m4/acx_pthread.m4 Wed Apr 14 22:15:34 2010 +0300
+++ b/m4/acx_pthread.m4 Thu Apr 15 11:48:58 2010 -0700
@@ -149,6 +149,10 @@
 
         acx_pthread_flags="-pthreads pthread -mt -pthread $acx_pthread_flags"
         ;;
+
+       *-darwin*)
+       acx_pthread_flags="-pthread"
+       ;;
 esac
 
 if test x"$acx_pthread_ok" = xno; then

Would it be possible to incorporate this patch to the development branch?

Major trouble seemed to be with my macports background, it turned out that 
freshly compiled 3.2.3 seg faults on eigs test due to an incompatible macports 
arpack port. All other macports octeve dependencies are compiled without the 
-ff2c option. Mixing the calling conventions causes seg faults for complex type 
data.

Apple blas (veclib) does not work with 64-bit gfortran (4.2, 4.3, 4.4, nor 
4.5). Complex functions obviously fail (and segment fault) without -ff2c 
option, but then other non-complex routines return incorrect answers when -ff2c 
is enabled, so that configure fails (rightly so). So with 64-bit OSX you pretty 
much have to use atlas and/or lapack, not the apple veclib. AFAIK this is a 
problem of the fortran compilers with -m64, as changing from no -ff2c to -ff2c 
should not have any effect on non-complex functions (as they don't when -m32).

I had some trouble with gnulib, but these have been now resolved, and octave 
compiles with a fresh gnulib git clone.

Compiling with non-apple GCC produces faulty results, if the OpenGL framework 
is enabled. GCC 4.4 succeeds with --without-framework-opengl. Building with 
apple-gcc 4.2 seems to be the safest bet, as then this issue does not arise. 
This requires the use of the gfortran-4.2 from the R site, the newest build 
seems to work well with the fresh Xcode 3.2.2 (even though the installer warns 
about overwriting cc1).

Octave 3.2.3 runs fine with the opengl framework enabled also when compiled 
with macport GCC 4.4, so some changes in Octave since then make this problem 
surface.

The reason for the seg faults with opengl framework enabled can be seen here:

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib                   0x00007fff853fb886 __kill + 10
1   libSystem.B.dylib                   0x00007fff8549beae abort + 83
2   liboctinterp-3.3.51+.dylib          0x00000001002b6690 
my_friendly_exit(char const*, int, bool) + 74
3   liboctinterp-3.3.51+.dylib          0x00000001002b676f 
generic_sig_handler(int) + 31
4   libSystem.B.dylib                   0x00007fff8540d80a _sigtramp + 26
5   libSystem.B.dylib                   0x00007fff853fb886 __kill + 10
6   libSystem.B.dylib                   0x00007fff8549beae abort + 83
7   libSystem.B.dylib                   0x00007fff853b3a75 free + 128
8   libstdc++.6.dylib                   0x00007fff81188eb3 
std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> 
>::overflow(int) + 281
9   libstdc++.6.dylib                   0x00007fff81189c21 
std::basic_streambuf<char, std::char_traits<char> >::xsputn(char const*, long) 
+ 139
10  libstdc++.6.dylib                   0x000000010335f225 
std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, 
std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, 
char const*, long) + 485

Note the jump from one instance (GCC 4.4, at address ..00103..) of libstdc++ to 
another (OSX, at address ..7fff..) both above, and again below:

11  liboctinterp-3.3.51+.dylib          0x00000001000553c8 
octave_vformat(std::ostream&, char const*, __va_list_tag*) + 93
12  liboctinterp-3.3.51+.dylib          0x000000010000aec8 verror(bool, 
std::ostream&, char const*, char const*, char const*, __va_list_tag*, bool) + 
568
13  liboctinterp-3.3.51+.dylib          0x00000001000ce5a4 vmessage(char 
const*, char const*, __va_list_tag*) + 48
14  liboctinterp-3.3.51+.dylib          0x00000001000ce634 message(char const*, 
char const*, ...) + 142
15  liboctinterp-3.3.51+.dylib          0x00000001001e666d dump_octave_core() + 
59
16  liboctinterp-3.3.51+.dylib          0x00000001002b6718 
my_friendly_exit(char const*, int, bool) + 210
17  liboctinterp-3.3.51+.dylib          0x00000001002b676f 
generic_sig_handler(int) + 31
18  libSystem.B.dylib                   0x00007fff8540d80a _sigtramp + 26
19  libSystem.B.dylib                   0x00007fff853fb886 __kill + 10
20  libSystem.B.dylib                   0x00007fff8549beae abort + 83
21  libSystem.B.dylib                   0x00007fff853b3a75 free + 128
22  libstdc++.6.dylib                   0x00007fff81188eb3 
std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> 
>::overflow(int) + 281
23  libstdc++.6.dylib                   0x00007fff81189c21 
std::basic_streambuf<char, std::char_traits<char> >::xsputn(char const*, long) 
+ 139
24  libstdc++.6.dylib                   0x000000010335f225 
std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, 
std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, 
char const*, long) + 485

The root of the problem seems to be the linkage from line 24 to 23: Why would 
the gcc 4.4 libstdc++.6.dylib link to a streambuf function in the system 
libstdc++, and not it's own copy of it?

Binary Images:
...
      0x103319000 -        0x1033beff7 +libstdc++.6.dylib 7.13.0 (compatibility 
7.0.0) <4F9407EC-5435-EB8A-6E92-A3A87262DFA7> 
/opt/local/lib/gcc44/libstdc++.6.dylib
...
   0x7fff8115a000 -     0x7fff811d7fef  libstdc++.6.dylib 7.9.0 (compatibility 
7.0.0) <35ECA411-2C08-FD7D-11B1-1B7A04921A5C> /usr/lib/libstdc++.6.dylib
...

Checking for the offending function:

$ c++filt "__ZNSt15basic_streambufIcSt11char_traitsIcEE6xsputnEPKcl"
std::basic_streambuf<char, std::char_traits<char> >::xsputn(char const*, long)
$ nm /opt/local/lib/gcc44/libstdc++.6.dylib | grep 
"__ZNSt15basic_streambufIcSt11char_traitsIcEE6xsputnEPKcl"
000000000004c940 T __ZNSt15basic_streambufIcSt11char_traitsIcEE6xsputnEPKcl
$ nm /usr/lib/libstdc++.6.dylib | grep 
"__ZNSt15basic_streambufIcSt11char_traitsIcEE6xsputnEPKcl"
000000000002fb96 T __ZNSt15basic_streambufIcSt11char_traitsIcEE6xsputnEPKcl
$ 

How it is possible that a call to a function within GCC 4.4 libstdc++ is 
resolved at the load time, and to a different library (system's version of the 
libstdc++)? Could the linking be somehow changed to have GCC 4.4 libstdc++ use 
it's own version of the function?

For some reason unknown to me, configuring with --without-framework-opengl 
produces binaries where this problem does not arise (no seg fault), even when 
there still are two different copies of libstdc++ within the binary images. The 
system version of libstdc++ is pulled in by libGLU, which is linked in 
regardless of the framework-opengl status.