Re: Symlinks from Tools to Applications

[Christopher Armstrong]

Hi

Nicola Pero wrote:
> Just to recap on this, I've been thinking a bit, and reading about it, and
> there doesn't seem to be an easy general solution.  The fact that a bundle 
> needs to be linked against all libraries all the time on Windows and some other
> systems makes things very difficult on these systems ... unless you reimplement
> the dynamic linker yourself to work around these limitations (which seems too 
> much work). :-(
>   
I don't really think we can modify the linker, unless we get the MINGW 
people to implement delay loaded DLLs (DLLs which get loaded when the 
first call against one of its exports is called, instead of at 
application startup), which could possibly offer us a way out of this 
mess, as if we added the right code to every application, an app would 
(possibly) be able to modify its search path for DLLs at runtime. That 
is if the MINGW people can figure this out (or if we can).
> One thing we can do is make sure at least the gnustep-base and gnustep-gui 
> bundles
> are located inside the library versioned resource directory ... in that way, for
> example, you can have two SSL gnustep-base bundles installed, each one used by
> its own gnustep-base.  I've done this for gnustep-base, but not yet for 
> gnustep-gui.
> Presumably it's something to be done before the forthcoming release. :-)
>   
The problem of different versioned copies of the same DLL being loaded 
into an address space should go away if both of the same versioned dlls 
have the same name. This obviously means they are in different 
directories. What you say above makes sense and sounds like the 
equivalent of a user containing two API incompatible versions of 
gnustep-base, such that two versions of the library are installed. We 
probably should use version numbers for library versions which are known 
to be incompatible, or use frameworks and implement proper support for 
those (somehow).
> Unfortunately, not sure we can do that for the backend bundle ?  Should the 
> backend
> bundle be installed into a versioned directory (versioned on the version of 
> gnustep-gui
> it was linked against) too ?
>   
It should be installed against the gnustep-gui version it was linked 
against, but this version should stay the same as long as the 
gnustep-gui version remains compatible with previous versions (API wise).
> Once the core bundles are used only by the appropriate library, the problem 
> should mostly
> be hidden ... usually bundles used by applications are bundled with the 
> application
> and are linked against the same libraries.  The problem would mostly occur for
> bundles app add-ins distributed by a different packager than the original 
> application.
> No matter what we do, I don't see an easy solution to that.
>   
A packager would have to distribute a different version for each 
application version I would think. Unless the APIs it depended on handed 
been changed. Probably a case by case basis thing we can't avoid.

Regards
Chris