On Wed, 26 Aug 2009, tim.jenness wrote:
> On Aug 26, 2009, at 1:22 AM, Peter W. Draper wrote:
>
>> On Wed, 26 Aug 2009, Matthijs H.D. van der Wiel wrote:
>>
>>> Thanks for this suggestion. After running the "Java Preferences"
>>> application (from /Applications/Utilities ), and doing export
>>> DYLD_LIBRARY_PATH=/star/lib , everything seems to work: Gaia, Splat,
>>> Topcat, Kappa procedures, and even my old python.
>>
>> Good, thinking about that a little more, clearly your old python setup is
>> 32bit, that would make the Starlink 64bit libraries incompatible and
>> ignored.
>>
>
> The point is that the 64-bit tree links against a libpng in the OSX X11
> distribution.
True, but Matthijs' original problem was Tk related, the PNG issue came
later. Having a 64bit version of Tk probably keeps it from being loaded by
python.
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0908&L=STARLINK&T=0&F=&S=&P=17370
>> (and as an aside, clearly some parts of the OS X X11 are also 32bit)
>>
>
> no they aren't. They are multi-architecture. I can link against it with no
> trouble in starlink land.
So why would an X server process (or whatever X11.bin is, that is the
process I saw in error messages) attempt to map in a 32bit version of PNG,
in preference to a multi-architecture version in the framework? I read
that as meaning the server (/X11.bin) itself is a 32bit process.
Peter.
|