[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #32564] Cannot start applications with the symbolic link created in

From: Wolfgang Lux
Subject: [bug #32564] Cannot start applications with the symbolic link created in the Tools directory
Date: Sat, 05 Mar 2011 16:06:40 +0000
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-US) AppleWebKit/531.21.8+(KHTML, like Gecko, Safari/528.16) Version/5.10.3 OmniWeb/622.14.0

Follow-up Comment #2, bug #32564 (project gnustep):

I'm sorry, but your changes did not fix the problem. (How do I reopen this

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:


  Nachricht geschickt von/durch Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]