On Wed, 18 Mar 2009, Tim Jenness wrote:
> On Mar 18, 2009, at 8:16 AM, Peter W. Draper wrote:
>
>> On Wed, 18 Mar 2009, Tim Jenness wrote:
>>
>>>> The problem is that GAIA and Skycat now use dynamically loaded libraries,
>>>> rather than static builds. So we'd either need to create a static build
>>>> or
>>>> finally solve the problem of building DLLs under Cygwin. Generally
>>>> Windows/Cygwin will not build a DLL with missing dependencies, that's
>>>> something we've been slack about. Not sure how to build an actual
>>>> dl-loadable library under Cygwin (that's a DLL designed to be loadable at
>>>> runtime, stage two of this operation). Looking at that has been on the
>>>> todo list since the break.
>>>
>>> do we know what to do in the general case?
>>
>>> From my notes.
>>
>> Add all the libraries that another library references to the _ADDLIB macro
>> (`ndf_link` etc.) and use the libtool flags -no-undefined and
>> -avoid-version. That leaves problems with the libraries that are already
>> static, BLT, NCAR etc to also resolve.
>>
>
> On the plus side ndf_link would almost become a no-op and we could
> simply use "-lndf".
>
> I'm a bit worried that this won't work with libraries that use global
> variables (eg EMS and AST). If you have an application that links
> against AST and NDF you end up with
>
> Application linking libast
> Application linking libndf linking libast
>
> and on some systems the libast linked against the application has a
> completely different address space than the libast connected to libndf. I
> have this problem with my perl interfaces to NDF and AST since they are setup
> exactly as above. In order for the AST perl interface to "see" AST objects
> returned by NDF (eg ndfGtwcs) I need to stringify the AST object (inside the
> C code calling NDF) and in the perl side convert it back to an AST object
> (using the perl AST interface).
>
> When you don't have global state in the shared library it works great
> but in our case....
Seems like a pretty crappy system. Are you sure you're not confusing
shareable libraries resolved at link time, which I don't expect has this
problem, with libraries loaded at runtime (loaded by dlopen)? You can end
up with the same library loaded into different addresses using this latter
technique
> In the particular case of GAIA/Skycat it may not actually be a problem since
> the bits of the system are isolated and specialized enough that workarounds
> as detailed above could work.
It should be OK. I create a special wish that all the standard libraries
hang onto, the Tcl/Skycat bits are the only dlopen-loaded parts (and these
are designed for that).
>> Having done all that I'm still worried that the dynamic loading might still
>> be a non-starter, so it wouldn't be wasted work, but still might not get us
>> there.
>>
>>>> The trick to getting GAIA working on Cygwin (and to some extent OS X) is
>>>> to pursuade the various components (Tk & friends, VTK) that would like to
>>>> have a native build to work as X11 libraries. Usually that's not a well
>>>> supported mode, so some hacking is involved.
>>>
>>> Any chance that ESO could re-implement RTD using native code on OSX? Then
>>> we could have a native GAIA with a nice aqua interface....
>>
>> Nice to dream.
>>
>
> That's what I do :-)
>
>> It's a lot of work to rip out all the X11 direct calls and replace with Tk
>> equivalents. That might not be enough for the RTD part where speed was a
>> major design issue.
>
>
> Maybe it could be done with macros so that we had a real-time version
> and a native version... Something for ESO though. No point attempting it
> only to find that ESO ignore the patches. We *really* need to send them
> patches for all the fixes you've been doing.
Down to them (re-hiring Allan to do this).
Peter.
|