Follow-up Comment #2, bug #32564 (project gnustep):
I'm sorry, but your changes did not fix the problem. (How do I reopen this
bug?)
I guess, my problem description wasn't clear enough, so I'll try again. When
one starts an application, say Ink, through the link in the Tools directory,
the absolute executable path computed by NSBundle is
/usr/GNUstep/Local/Tools/Ink. Hence, NSBundle tries to open the main bundle of
that application in /usr/GNUstep/Local/Tools where apparently it doesn't
exist. To get things right, the NSBundle code at some point must resolve the
symlinks in the path to the executable so that it will look up the bundle in
the directory /usr/GNUstep/Local/Applications/Ink.app. Until David's change,
this implicitly happened -stringByStandardizingPath, but now we'll have to do
that explicitly at some point.
I think this problem doesn't show up under Linux because
GSPrivateExecutablePath() reads the executable path from the process file
system and the kernel apparently resolves the symbolic link. Eventually, you
can test things under Linux by temporarily commenting out the code following
#ifdef PROCFS_EXE_LINK in GSPrivateExecutablePath()
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?32564>
_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnustep
