Seems that there are problems on amd64 machines: http://forums.codeblocks.org/index.php/topic,8858.msg64488.html#msg64488 (http://forums.codeblocks.org/index.php/topic,8858.msg64488.html#msg64488)
As I replied there, I think it's the wxwidgets function I use in configmanager.cpp (wxStandardPathsBase::Get().GetPluginsDir() (http://docs.wxwidgets.org/trunk/classwx_standard_paths.html#6c8ddf3efdefe76f45123df151a5a20b)) and if i read the docs I don't see any special mentioning of amd64 platforms :|
I don't know when I find the time to look into that, but perhaps someone with wxwidgets experience could solve this :wink:
This problem does not appear on debian amd64 architecture (I use it myself), because debian uses "/usr/lib". "/usr/lib64" is only a symlink to it, there is also a "/usr/lib32", which is a symlink to "/emul/ia32-linux/usr/lib". The same is done for "/lib" etc. but without the "/usr".
What I want to say is, that it is not easy to figure out the standard-directory for libraries on linux, if the different distributions don't agree about it.
I just looked in wxWidgets source-code and the directory is hardcoded.
That's the function they use (wxWidgets2.8.8 ):
wxString wxStandardPaths::GetPluginsDir() const
{
return AppendAppName(GetInstallPrefix() + _T("/lib"));
}
There are some possibilities I see: the first is to look if the returned PluginPath exists, and if not try the same path with other possible lib-directories. (Not a real elegant way).
Another would be to create the symlink in the postinst-process (I guess that's also possible on suse and others). But I don't think that creating a system-directory (even if it is "only a link) automatically is real good.
A third way might be to use a define to store the really used library-path(s) at configure/compile-time and use this define in "projectmanager.cpp" instead of the wxWidgets-function. I'm not sure if that would be easy to do, but I think it might be the most secure way.
And if "lsb" allows the "lib64" without the "lib" the wxWidgets-function is not standard-compliant and needs to be overworked.
/lib<qual> : Alternate format essential shared libraries (optional)
Purpose
There may be one or more variants of the /lib directory on systems which support more than one binary format requiring separate libraries. [14]
[14] This is commonly used for 64-bit or 32-bit support on systems which support multiple binary formats, but require libraries of the same name.
In this case, /lib32 and /lib64 might be the library directories, and /lib a symlink to one of them.
That shows they also seem not to agree with each other. Or did I misunderstood something.
I thought using the "/lib" and "/usr/lib" directories is correct for pure 32-bit or pure 64-bit (or pure whatever) architectures.
The debian amd64-bit system uses 32-bit libs only for programs that really need them (e.g. wine), but then it uses "/lib32" and "/usr/lib32". It's not a (really) biarch system.
But all that does not really solve the problem on Suse11 (what about earlier Suse distros and e.g. Fedora...?).
Last night I committed changes based on your patch.
The problem that some distros need 64-bit libraries isnatlled in "lib64" and some in "lib" is not solved (at the moment). They are always placed in lib due to the wxWidgets way to find the standard-path for the plugins-dir.
The easiest workaround would be to just ad a "64" when building is done for 64-bit, but then there must be additional changes to the automake-system.
I will look into it (if I find the time).
I wrote a patch for the lib64 issue, but don't know whether it's a good way like this. The patch is used in my buildservice repository (see signature). I tested it with a suse 11.1 64bit livecd (i'm running the 32bit version as main OS) and it works. The 32 Bit package with this patch works too ;)
Index: src/sdk/configmanager.cpp
===================================================================
--- src/sdk/configmanager.cpp (Revision 5456)
+++ src/sdk/configmanager.cpp (Arbeitskopie)
@@ -1390,7 +1390,12 @@
if(platform::windows || platform::macosx)
ConfigManager::plugin_path_global = data_path_global;
else
- ConfigManager::plugin_path_global = wxStandardPathsBase::Get().GetPluginsDir() + _T("/plugins");
+ {
+ if(! wxIsPlatform64Bit())
+ ConfigManager::plugin_path_global = wxStandardPathsBase::Get().GetPluginsDir() + _T("/plugins");
+ else
+ ConfigManager::plugin_path_global = ((const wxStandardPaths&)wxStandardPaths::Get()).GetInstallPrefix() + _T("/lib64/codeblocks/plugins");
+ }
}
#endif
/usr/local/lib64 (for example, any other prefix does it as well) is not a symlink to /usr/local/lib, but C::B's plugins and libs will be installed there. In this case it can not find it's plugins.
Please test the following patch, it first assumes we use the standard-folder (lib), and only if it not exists and we are on 64-bit it uses lib64 instead:
Index: src/sdk/configmanager.cpp
===================================================================
--- src/sdk/configmanager.cpp (Revision 5919)
+++ src/sdk/configmanager.cpp (Arbeitskopie)
@@ -1442,10 +1442,18 @@
#ifdef CB_AUTOCONF
if (plugin_path_global.IsEmpty())
{
- if(platform::windows || platform::macosx)
- ConfigManager::plugin_path_global = data_path_global;
- else
- ConfigManager::plugin_path_global = wxStandardPathsBase::Get().GetPluginsDir() + _T("/plugins");
+ if(platform::windows || platform::macosx)
+ ConfigManager::plugin_path_global = data_path_global;
+ else
+ {
+ ConfigManager::plugin_path_global = wxStandardPathsBase::Get().GetPluginsDir() + _T("/plugins");
+ // first assume, we use standard-paths
+ if(!wxDirExists(ConfigManager::plugin_path_global) && wxIsPlatform64Bit())
+ {
+ // if standard-path does not exist and we are on 64-bit system, use lib64 instead
+ ConfigManager::plugin_path_global = ((const wxStandardPaths&)wxStandardPaths::Get()).GetInstallPrefix() + _T("/lib64/codeblocks/plugins");
+ }
+ }
}
#endif