On Thu, 19 Mar 2009, Peter W. Draper wrote:
>> 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
I am talking about dlopen. Have not tried the general case on OSX.
>
>> 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).
Ok. If it's only dynamically loading skycat and not the startcl interfaces
then that should be fine. If we used tcl more there would be separate NDF
and AST interfaces in loadable tcl modules and then I assume we would have
problems.
>> 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).
>
That seems a bit of a strange way to handle bug fixes. Who do I contact in
ESO management?
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|