Jack Howarth wrote:
Oddly I see to see that when fink links liblam.0.0.0.dylib with gcc called
as gcc-4.0, I have...
gcc-4.0 -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o
.libs/liblam.0.0.0.dylib ...etc
whereas when I build lam 7.1.1 manually I end up with...
gcc -dynamiclib
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Costabel wrote:
| This is strange also because the libtool calls in both cases seem
| identical...
|
| []
|
| It is curious that they produce such different linkages.
|
|
| Different libtool versions in /sw and in /usr?
|
Nope, setting
Peter,
Actually 'NoSetMACOSX_DEPLOYMENT_TARGET: true' is insufficient.
I had to resort to 'SetMACOSX_DEPLOYMENT_TARGET: 10.2' in order to
force libtool to use -undefined suppress. I'll post the packaging I
have into the fink tracking system later today. There also was a patch
I added to force
I don't understand why this build problem happens under fink but I
believe I have identified the offending file. It appears that the breakage
in the fink build of lam 7.1.1 originates in the liblam.0.0.0.dylib
shared library. Oddly the fink built version shows...
otool -L liblam.0.0.0.dylib
Oddly I see to see that when fink links liblam.0.0.0.dylib with gcc called
as gcc-4.0, I have...
gcc-4.0 -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o
.libs/liblam.0.0.0.dylib ...etc
whereas when I build lam 7.1.1 manually I end up with...
gcc -dynamiclib ${wl}-flat_namespace
