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... Best regards Saso ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
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
[Gnustep-cvs] gnustep/usr-apps/gworkspace ChangeLog
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Gregory John Casamento [EMAIL PROTECTED] 05/09/08 00:45:10 Modified files: usr-apps/gworkspace: ChangeLog Log message: Corrected circular dependency in ddbd. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/usr-apps/gworkspace/ChangeLog.diff?tr1=1.62tr2=1.63r1=textr2=text
[Gnustep-cvs] gnustep/usr-apps/gworkspace ChangeLog
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Gregory John Casamento [EMAIL PROTECTED] 05/09/08 00:48:32 Modified files: usr-apps/gworkspace: ChangeLog Log message: Removed change made by commit script. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/usr-apps/gworkspace/ChangeLog.diff?tr1=1.63tr2=1.64r1=textr2=text
