Re: GNUstep Native Framework Support (fwd)

[Nicola Pero]

---------- Forwarded message ----------
Date: Thu, 8 Sep 2005 13:51:51 +0100 (BST)
From: Nicola Pero <address@hidden>
To: "[iso-8859-2] Sa¹o Kiselkov" <address@hidden>
Subject: Re: GNUstep Native Framework Support


> I wanted to avoid using some platform-specific hacking in order to extended
> support to the platform hated by any serious developer: Windows.

Thanks - ... thinking ... - Hmmm, I'm not sure if having our own linking
machinery would make the Windows port more simple or more complex. ;-)



> >  * ObjC software is not always invoked from the command line ... eg if
> > your ObjC software is a package (linked to some frameworks) that you want
> > to load inside a program written in another language (typically Java or
> > Python), you can't execute any prior script to set up the library path to
> > match the exact frameworks linked into the code you're loading;  you'll
> > just be loading the ObjC code using C calls to the linker libraries and
> > running it.  That makes everything lot more complex in this case -- I
> > suppose all language interfaces would have to have custom code that would
> > actually manually load all the required frameworks using the linker
> > libraries ?  That would be quite messy.  Currently, instead, all this is
> > done automatically by the linker and is really nice. :-)
> 
> I hadn't thought of that .. ^_^; oops. Anyways, I think it could be 
> circumvented
> like this: implement our own "front-end" to the linker.

Good idea ...  but this is not always possible/easy.  Eg, in Java you have
to use

  System.loadLibrary ("xxx");

(that's a Java method call) and that call will use whatever linking system
is built into the Java Virtual Machine.  In particular, the Sun/Linux one
will check that all symbols in the loaded shared object are resolved ...
but at least it honours the xxx_LIBRARIES_DEPEND_UPON, so you can have
your shared object depend on all the libs that you want.



> >  * In some cases, LD_LIBRARY_PATH is ignored on Unix.  For example, by
> > tools that can be run as root by any user (setuid).  For those, the only
> > possible solution is having symlinks and then running ldconfig. :-(
> 
> True, no solution possible here... damn... However, even with today's symlinks
> setuid ObjC binaries would require me to put my paths into /etc/ld.so.conf -
> symlinks alone don't suffice, as the linker ignores LD_LIBRARY_PATH. In other
> words: the functionality is broken already today.

Sure ... but we're fixing it.  We want to get rid of LD_LIBRARY_PATH
(except for people wanting to use their own user's library dir) and have
everyone have their library paths in ld.so.conf ... :-)


> >  * The recent trends in GNUstep users are that we should try avoiding
> > shell/C wrappers and relying on LD_LIBRARY_PATH and other such variables.
> > Most people are more worried about being able to deploy the software so
> > that it runs out of the box and can't be considered as friendly as native
> > applications, rather than about frameworks being more "real". ;-)
> 
> The wrapper mechanism would do it's own env var setup, so "out of the box
> functionality" actually is ensured. There might, however, be problems if a
> program plays around with it's LD_LIBRARY_PATH, but this problem exists today
> as well, as GNUstep uses LD_LIBRARY_PATH for setting up the linker search path
> to include the directories with symlinks to frameworks.

Yes ... exactly what I wanted to say ... we are trying to get rid of
LD_LIBRARY_PATH in general! :-)


Anyway, I think I put enough meat on the fire, let's wait and see if we
have other people commenting. ;-)

Thanks for your time, and I do appreciate your efforts to find a good
portable solution to frameworks! ;-)