Re: Symlinks from Tools to Applications

[Nicola Pero]

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). :-(

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. :-)

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 ?

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.

Thanks


-----Original Message-----
From: Christopher Armstrong <carmstrong@fastmail.com.au>
Sent: Sat, March 10, 2007 2:07 am
To: nicola.pero@meta-innovation.com
Cc: discuss-gnustep@gnu.org, Richard Frith-Macdonald 
<richard@tiptree.demon.co.uk>
Subject: Re: Symlinks from Tools to Applications

Hi

Nicola Pero wrote:
>> There is also the issues of bundles linking against different versions 
>> of gnustep-base/gnustep-gui as compared to the application they are 
>> running in...
>>     
>
> Very good point ... I hadn't thought of that. :-(
>
> On other platforms this is not so much of an issue just because bundles 
> don't need to be explicitly linked to all libraries ... but on Windows they 
> do :-/
>
> Is there a way to avoid linking bundles to all libraries on Windows ?
>   
Not that I'm aware of. It doesn't actually link it to a particular 
library, just the file name. From past experience, you can usually just 
drop in another DLL with the same name. As long as all the exports are 
the same, this never is really much of a problem (obviously interface 
breakage is possible, but we wouldn't allow this).
> Else, there is some more thinking to do here to make for a smoother user
> experience. :-/
>   
Perhaps we should emphasize the usage of frameworks in these scenarios, 
instead of using libraries. They have versioning built into their 
design, so we really should take advantage of them, even if they don't 
map properly to a GNUstep environment. We really should modify the 
openapp/opentool script so that it puts the paths to a framework version 
into the "PATH" variable on windows and "LD_LIBRARY_PATH" on unix on 
startup (has this already been done?) Then, as Richard has suggested, 
use the AppPath registry setting to the directories we need (in this 
case, the framework directories). In all cases, the name of the .dll 
file stays the same whilst the dll itself changes every time the 
programme is run.

Otherwise, your idea of using the INTERFACE_VERSION stuff is probably 
more appropriate, as we should just "hope" that a bundle or library uses 
the same version as the application thats linking against it. Perhaps 
better protection against this can be put into the Objective-C runtime? 
This appears to be where most of the problem starts.

There is also a technique on Windows known as "Delayed-DLL Loading", 
where the dll is loaded until the first time one of its symbols is 
referenced in the programme. Code is emitted by the compiler that causes 
LoadLibrary/GetProcAddress to be called upon this happening. Maybe we 
should consider bugging the mingw people into writing something like 
this, or developing it ourselves.
>> Which leads me to my other idea...COM registers every class/interface in 
>> the registry with a pointer to the location of the DLL. If we were to 
>> modify the runtime, would it be possible for it to locate classes at 
>> runtime by looking them up in the registry, instead of explicitly 
>> linking against its DLL? Or is this just fanciful thinking?
>>     
>
> It's an interesting idea ;-)
>
> I'm not sure it would really work because most libraries/bundles/etc contain
> a lot of C code as well as ObjC classes.  So even if we managed to hack the
> runtime to look up classes in the registry, C stuff would still need to be
> loaded via DLLs, and versioning problems wouldn't go away :-
Good point...perhaps we could use a thunking technique for these? 
Something like a code stub that tries to find the address of the 
function at runtime and does a jmp to its address? Not pretty, but again 
another potential (part) of the solution.

Regards
Chris