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 <[EMAIL PROTECTED]>: > > * 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 _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
