[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Succees on OSX 64-bit with development branch
Re: Succees on OSX 64-bit with development branch
Wed, 21 Apr 2010 17:45:37 -0700
On Apr 21, 2010, at 5:08 PM, ext Ben Abbott wrote:
> On Apr 21, 2010, at 5:18 PM, Jarno Rajahalme wrote:
>> On Apr 15, 2010, at 11:58 AM, ext Jarno Rajahalme wrote:
>>> 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?
>>> 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.
>> Short recap: in OSX, system dylibs pull in the system version of the
>> libstdc++.6.dylib. When using GCC > 4.2, the code needs to be linked with a
>> newer libstdc++.6.dylib. Having two copies of the same dylib linked in
>> causes some weird results, caused by one libstdc++ linking to another, which
>> results in malloc/free errors, segmentation faults, aborts, etc.
>> The solution to this linking problem was quite easy, when found. All it
>> takes is to have the newer libstdc++ (e.g.
>> /opt/local/lib/gcc44/libstdc++.6.dylib) in the LDFLAGS. This way to
>> cross-linkage between the different versions seems to go away, no seg
>> faults, and all tests (but the one of the svds tests) succeed.
>> There is also a linking option -dylib_file, which, according to the man ld
>> is intended for resolving a similar kind of a problem. However having
>> /usr/lib/libstdc++.6.dylib:/opt/local/lib/gcc44/libstdc++.6.dylib" in
>> LDFLAGS did not help, there are still two versions of libstdc++.6.dylib
>> linked in.
>> Finally, there is the linking option -flat_namespace, which reveals the
>> duplicate libraries at the link time (warnings), but did not resolve the
>> In the end, neither of these options is required.
> Jarno, did you build all dependencies with the same version of the gcc
> compiler and link to Apple's frameworks, or did you mix versions of gcc when
> building dependencies?
> Also, were any of the dependencies built under Leopard (10.5), or did you
> rebuild all of them using Snow Leopard (10.6)?
> p.s. notice I've switch to bottom posting so that late comers can follow
> along more easily.
I started out using Octave on Mac on Leopard, but I think all of the
dependencies were rebuild when switching to a newer version of macports, while
on Snow Leopard. Macports Octave 3.2.3 has been a 64-bit build from since I
upgraded to 10.6, since I have been using 64-bit kernel all along, and the
ports build according to the running kernel architecture.
I think rebuilding is actually mandatory, as the binary interface is different
between 32-bit (i386) and 64-bit (x86_64). You can't link 32-bit and 64-bit
together, as the linking phase will fail due to incompatible architectures.
I had a seg fault in eigs() test for a long time, and that turned out to be due
to macports arpack being built with -ff2c, while everything else is built
without (including Octave). In the process of figuring this out I have locally
built atlas (including lapack), with errata from the atlas site, qrupdate (with
a fix from Octave maintainers list), and arpack, now with proper compiler
options (no -ff2c).
I recall that you have been using the -ff2c version using fink and Apple
accelerated blas? There is a bug in the 64-bit apple blas library, as it is not
following the f2c calling conventions regarding returning single precision
floats. This is the reason configure fails in 64-bit, if using Apple blas
library (veclib). I reported this to Apple, and someone responded to me at
MacResearch and confirmed that this is really an Apple bug. So, for the time
being, you have to use atlas for blas, if building 64-bit, as Apple's doesn't
work either with or without -ff2c.
macports atlas is linked with compiler-specific fortran libraries. While this
is probably no problem, I built them locally so that the fortran library
references are left unresolved, so that they are resolved to whatever fortran
library octave is built with. Officially, you should not mix new code and older
library (older code and newer library should be fine), but apparently there has
not been any significant change in libgfortran, so that using 4.2 library with
code compiled with 4.4 still works as intended.
I have successfully built octave 64-bit now with both Apple GCC 4.2 (with
gfortran from the R-site) and macport GCC 4.4. The only quirk with the former
was that the gfortran installation from the R-site did not include a dylib
version of libgfortran, so I had to build that from the static library. With
static libgfortran octave itself linked ok, but my atlas dylib did not find the
missing gfortran symbols.
So, to make it clear, yes, I have mixed versions, building some of the
dependencies with GCC 4.4, and using Apple GCC 4.2 to build octave. Linking to
Apple frameworks worked fine all along, when compiling Octave with Apple GCC
4.2. Many of my dependencies are still from macports, some build with GCC 4.3,
some with GCC 4.4. These dependencies have NOT been rebuilt after I upgraded to
Xcode 3.2.2 two weeks ago.
The LDFLAGS stuff I mentioned above allowed me to build and link Octave with
macports GCC 4.4 while linking to Apple frameworks.