Seems that there are problems on amd64 machines: 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()) 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.