Re: GNUstep Native Framework Support
> Hello everybody > > I know there have been tons of discussions and flames on this topic, but this > time I have a solution for it. For details, please read > http://openspace.adlerka.sk/NativeFrameworks and tell me your opinion: is it > worth bothering about further, or just blow the whole thing in the wind. And > please don't stone me if you don't agree with the details... Thanks ... it's an interesting idea ... and nicely done! :-) I can see a few problems with this approach though -- * 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. :-) * 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. :-( * 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". ;-) * 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 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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep Native Framework Support
--- Sa¹o Kiselkov <[EMAIL PROTECTED]> wrote: > Hello everybody > > I know there have been tons of discussions and > flames on this topic, but this > time I have a solution for it. For details, please > read > http://openspace.adlerka.sk/NativeFrameworks and > tell me your opinion: is it > worth bothering about further, or just blow the > whole thing in the wind. And > please don't stone me if you don't agree with the > details... > > Best regards > Saso > hi just took a quick glance at this document, will look more closely later... after my foray into hacking the dynamic linker... i took another look at this, i haven't actually tried this yet as i don't currently have a glibc-2.4 available and there might be another option... new in glibc-2.4 is LD_AUDIT support this is only available currently as an environment variable... but with an audit lib and an implementation of la_objsearch() it *seems* possible.. (i'm thinking that the frameworks link with an extended substitution sequence, and the audit lib turns the substitution sequence into a real search path...) e.g. --Wl,-soname,"$FRAMEWORK/foo.framework/Versions/A/foo" then la_objsearch() looks for $FRAMEWORK and replaces it with the path found.. gnu ld last i looked doesn't support the -p and -P options (from solaris ld) which would be nice to link frameworks against the audit lib without forcing the use of the LD_AUDIT variable. so only apps using frameworks or whatever would need the audit lib and matt __ Click here to donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
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. 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 w
Re: GNUstep Native Framework Support
From: "Saso Kiselkov" <[EMAIL PROTECTED]> I wanted to avoid using some platform-specific hacking in order to extended support to the platform hated by any serious developer: Windows. This is my fundamental problem with OSS in general: The very idea that all "serious" developers hate Windows is a derangement. Look if you don't want to program in Windows, just stay out of the way, but don't insult those serious developers who make their living there. I know perhaps only Saso feels this way, and I am not ascribing this view to all gnustep developers, but the project does seem to have more anti-windows zealots than the average. Windows has some quirks, and is very different from Unix, but that doesn't make it a terrible place to develop software. In many areas, it has a more stable and/or efficient structure. It's just that those areas are not where Unix excels ( i.e.. multi-user, mem management, multitasking, etc.), instead they are in the areas that a single user would notice. (graphics performance, multithreading, etc.) The huge benefit of writing software for windows is that there are millions of potential customers for you to sell/give your software to. The current Frameworks code in CVS seems to be working fine on windows, let's let it be. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep Native Framework Support
Am Donnerstag, 08.09.05 um 16:53 Uhr schrieb Jeremy Bettis: The huge benefit of writing software for windows is that there are millions of potential customers for you to sell/give your software to. The huge benefit of running windows is that there are millions of "friends" who offer you to share their stolen software. Sorry, I simply could not resist here. It might sound odd but I heart of many developers who were surprised on how much they actually could sell to Mac users despite the minor market share OS X has. I think it is a well pampered urban legend that the "huge Windows-market" makes you earning big profits. Never forget that the biggest piece of cake attracts the most hungry birds (e.g. competitors) and that the "warez" subculture flourishes there. regards, Lars p.s.: I have no objections against you as a windows developer, I merely just don't share the common views on that market. Nevertheless I think a stable Windows Version of GNUstep is very important - but this is another story than above: GNUstep is free software, so no profit problems here. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep Native Framework Support (fwd)
-- 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
Re: GNUstep Native Framework Support (fwd)
heres a quick hack at the LD_AUDIT thing i mentioned earlier with glibc-2.4... (and the current fedora libc i believe) or with a few changes s/-Wl,-soname/-Wl,-h/ and some other stuff solaris.. > Yes ... exactly what I wanted to say ... we are > trying to get rid of > LD_LIBRARY_PATH in general! :-) > well, this one uses yet another environment variable :P i just randomly picked out GS_FRAMEWORK_PATH... > > Anyway, I think I put enough meat on the fire, let's > wait and see if we > have other people commenting. ;-) it only takes care of the dynamic linking issue leaving the c pre-processor/ld machinery for something else... if this is deemed interesting enough, i can make a stab at implementing -pfwk-audit and -P in ld, so we can link the framework to the audit lib instead of requiring the LD_AUDIT environment variable, (which also means it wouldn't be auditing things that don't link to frameworks) > > Thanks for your time, and I do appreciate your > efforts to find a good > portable solution to frameworks! ;-) > this one isn't portable... matt __ Click here to donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/ frameworks-audit.tar.gz Description: 1411266797-frameworks-audit.tar.gz ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
