Re: Succees on OSX 64-bit with development branch

[Jarno Rajahalme]

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 
>> "-dylib_file 
>> /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 
>> problem.
>> 
>> In the end, neither of these options is required.
>> 
>> Jarno
> 
> 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)?
> 
> Ben
> 
> 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.

  Jarno