2009/3/18 Tim Jenness <[log in to unmask]>:
> 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).
Ouch! Sounds slow.
David
|