[Scribus] Many Versions = 2

[Martin Costabel]

Thorsten Z?rner wrote:
[
>> imac:~ eric$  /sw/Applications/Scribus.app/Contents/MacOS/Scribus
>> dyld: Symbol not found:
>> __ZN12QApplication14macEventFilterEP25OpaqueEventHandlerCallRefP14OpaqueEventRef 
>>
>>   Referenced from: /sw/Applications/Scribus.app/Contents/MacOS/Scribus
>>   Expected in: dynamic lookup

This symbol should be found in /sw/lib/qt3mac/lib/libqt-mt.3.dylib which 
is loaded at runtime by Scribus. Why this isn't the case for you I 
cannot guess without further looking at your configuration.

You can verify with the command

otool -L /sw/Applications/Scribus.app/Contents/MacOS/Scribus

whether that dylib is indeed on the list of libraries loaded at runtime. 
And with

nm /sw/lib/qt3mac/lib/libqt-mt.3.dylib |grep OpaqueEventHandlerCallRef

you can check whether the symbol in question is really defined in that 
library (does it have a "T" in front of it?).

[]
> Macintosh-2:~ thorsten$ /sw/bin/scribus
> dyld: lazy symbol binding failed: Symbol not found: _art_free
>   Referenced from: /sw/bin/scribus
>   Expected in: dynamic lookup

This one comes from /sw/lib/libart_lgpl_2.2.dylib which is also loaded 
by scribus at runtime.

[]
> Over on MacPorts I was able to compile and run 1.3.3.9 and 1.3.3.10  
> allright.
> So, if you need Scribus for production now, give MacPorts a try: 
> http://www.macports.org/
> 

If Fink's scribus-1.3.3.10 and scribus-aqua-1.3.3.10 did not work for me 
on at least two machines with MaxOSX 10.4 and MacOSX 10.5, they would 
not be available from Fink, as they have been since yesterday.

Problems with undefined symbols at runtime are often caused by too many 
different versions of the same libraries installed from different 
sources, which disturbs the compilation, because at runtime different 
versions may be found than at compile time.

  Another frequent source for such problems is the setting of the 
DYLD_LIBRARY_PATH environment variable, which should be avoided on MacOSX.

I don't believe that Macports is more immune to such problems than Fink.

-- 
Martin