[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Succees on OSX 64-bit with development branch
From: |
Jarno Rajahalme |
Subject: |
Succees on OSX 64-bit with development branch |
Date: |
Thu, 15 Apr 2010 11:58:45 -0700 |
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.
- Succees on OSX 64-bit with development branch,
Jarno Rajahalme <=