Re: GNUstep Native Framework Support

[Sašo Kiselkov]

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

Quoting Nicola Pero <address@hidden>:

>
>  * 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. In more detail, my ideas
run like this:
 - every wrapper would contain information on what frameworks it depends on.
Frameworks would also contain additional dependency information.
 - our linker would look through the dependency hierarchy and resolve all
framework locations.
 - the linker could be implemented as a thin C-library which would be used by
code which would want to load ObjC frameworks/bundles (e.g. ldfworks.c and any
ObjC language-bridge). Instead of using 'dlopen' they would use our (for
example) 'GSLoadBundle()'. This function would do the above lookups and
afterwards set up the LD_LIBRARY_PATH of the process in which it operates to
correctly include the frameworks. Finally, it would simply invoke dlopen.

(While writing this e-mail a joky idea came to me: what if we didn't build
apps/tools as standalone apps, but instead build them as shared libraries.
Running an app/tool would be then be done by invoking our specialized
mini-C-program which would simply load the target program's relocatable code
into it's address space and transfer control to it. The point of doing this is
that we can do arbitrary setups before the code is actually loaded and run, and
the only difference that target program would see is that it's stack backtrace
would be one level deeper. It's just a rough idea, but it could work... and on
top of that be portable... :-D (though, again, debugging issues...))

>  * 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.

>  * 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.

>  * Wrappers are slow.  We used to have wrappers for all our ObjC tools,
> but that way whenever you write a command-line in ObjC you'd get penalized
> a lot compared to a native C tool.  You can't match the speed of a native
> C tool such as 'sed' or 'grep' if you have wrappers -- the wrapper itself
> will require at least an additional process creation, which is a
> considerable overhead for a light command-line tool.  So we managed to
> remove the wrappers, and nowadays writing ObjC command-line tools should
> be possible and they should be reasonably comparable, in speed, to native
> C tools. :-)

I'd personaly disagree here. Compare the speed penalty of an additional exec
against the dynamic-linker having to load giant libraries (which gnustep-base
is). I use a 533MHz Transmeta and GNUstep tools already _have_ a significant
speed penalty. When I run "grep" I instantly get a response. Running
make_strings takes roughly 0.5 seconds. I think a few additional miliseconds
taken up by ldfworks.c get completely lost in the giant startup gap.

>
> I don't mean to stop the debate though, and not necessarily to discourage
> you.  Maybe we could still have it as an option if people like it. :-)
>
> Let's hear what other people think ;-)
>
> Thanks
>
>

I'm sure there is a satisfactory and portable way to do it, we just have to look
hard enough and combine enough heads together. :-)

--
Saso