Ticket #53 (reopened defect)
on cygwin, installed CS binaries don't work
| Reported by: | acb@… | Owned by: | mdmkolbe |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | general | Version: | V0.99 |
| Keywords: | Cc: |
Description
Migrated from SFbug:1441054.
Original description:
On cygwin, with the latest pseudo-stable version of CS
(cs-pseudo-stable-2006-01-27), every exec gives the
message:
WARNING: could not load plugin 'crystalspace.kernel.vfs'
* This likely means that the plugins could not be found.
If you're a user: Check the working directory the
application starts from -
usually, it is the same as the directory with the
executable.
If in doubt, contact the vendor.
If you're a developer: Check if the CRYSTAL
environment var points to the
correct location - usually the directory CS was built in.
WARNING: could not load plugin 'crystalspace.kernel.vfs'
Cannot load iVFS plugin
when invoked from the install directory, regardless of the setting of the CRYSTAL environment variable.
I dug into the code a bit, and discovered that it could be made to work by deleting line 46 of libs/csutil/scf.cpp (#define NEW_PLUGIN_PATHS). Aparently on cygwin, the method csInstallationPathsHelper::GetPluginPaths() does not work.
After the line is deleted, everything is recompiled and reinstalled, the installed executables work as expected.
Original comments:
Date: 2006-04-28 10:20 Sender: jorrit Logged In: YES user_id=1703 Eric, do you have any clue about this?
Date: 2006-03-22 22:58 Sender: acb Logged In: YES user_id=14072 All right -- I've looked at the code a bit more and it does look like it needs to be fixed during the build process (otherwise the vfs.cfg file will be incorrect; the /sw/CS/etc/crystalspace/vfs.cfg file after my hacky-comment-out-the-FixSeparators() call attempted workaround has these entries: VFS.Win32.CS_SHAREDIR = /sw/CSMINE/share/crystalspace VFS.Win32.CS_DATADIR = /sw/CSMINE/share/crystalspace/data VFS.Win32.CS_CONFIGDIR = /sw/CSMINE/etc/crystalspace VFS.Win32.CS_MAPDIR = /sw/CSMINE/share/crystalspace/data/maps which cause nothing but problems, since the vfs.cfg sets for example VFS.Mount.scripts = $(CS_SHAREDIR)$/bindings$/, which results in /sw/CSMINE/share/crystalspace\bindings. If $/ is going to be '\' on cygwin, then the paths need to be fixed before they get into the vfs.cfg file. Looks to me like there needs to be a translation of the variables set in mk/jam/install.jam from cygwin paths to native windows paths... appdatadir,appdocdir,appconfdir,appincdir, and plugindir get set in mk/jam/install.jam. I.e. mk/jam/install.jam currently sets plugindir on line 31 of mk/jam/install.jam: plugindir ?= [ ConcatDirs $(libdir) $(PACKAGE_NAME) ] ; I think things would work better if they were to set to how cygwin_conv_to_win32_path() would interpret what they're set to now (for cygwin). I think that would pretty much take care of the problem (CS_PLUGINDIR is set to $(plugindir) in libs/csutil/Jamfile, and those vfs.cfg use these variables too in plugins/filesys/vfs/Jamfile). What do you think? Does this sound like a viable approach to solve the problem?
Date: 2006-03-14 23:13 Sender: acb Logged In: YES user_id=14072 If the call to FixSeparators() in the constructor to Entry() is removed, that's exactly what happens: csPathsUtilities::ExpandPath() calls cygwin_conv_to_win32_path() (see line 116 of libs/csutil/win32/winsyspath.cpp) to get the native windows path.
Date: 2006-03-14 22:09 Sender: res2002 Logged In: YES user_id=360881 Paths are intended to be native, even on Cygwin. So maybe CS_PLUGINDIR should contain a native path, or perhaps should somehow get converted to native at some point.
Date: 2006-03-09 23:05 Sender: acb Logged In: YES user_id=14072 OK -- I sank a big deeper into csutil code, and I think I found the root cause (after much trial and error)! When the function csPathsList::AddUnique is called on a cygwin path (that originated with CS_PLUGINDIR), it constructs a new Entry() (line 88 of libs/csutil/syspath.cpp). The problem is that the Entry(char*,char*,bool) constructor called FixSeparators() on the passed string. This results in the CS_PLUGINDIR value of '/sw/CS/lib/crystalspace' becoming '\sw\CS\lib\crystalspace'. The problem with this is that later cygwin_conv_to_win32_path() is used on this (line 116 of libs/csutil/win32/winsyspath.cpp), and cygwin_conv_to_win32_path() turns "/sw/CS/libs/crystalspace/" into "d:/cygwin/sw/CS/libs/crystalspace" just fine, but it turns "\sw\CS\libs\crystalspace\" into the non-existing path "d:\sw\CS\libs\crystalspace". I commented out the call to FixSeparators() in the constructor to Entry(), and this also seemed to solve the installed-binaries-don't-work problem (when I executed executables in the installed directory, they are now able to find plugins in the install path, etc.). Not sure if this is the best fix or not (I don't know if this FixSeparators() is needed at any point)
