---------- Forwarded message ---------- Date: Thu, 8 Sep 2005 13:51:51 +0100 (BST) From: Nicola Pero <[EMAIL PROTECTED]> To: "[iso-8859-2] Sa¹o Kiselkov" <[EMAIL PROTECTED]> 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! ;-) _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev