Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
[Linux] Moving arch-dependent plugins out of /usr/share
Jenna:
--- Quote from: daniel2000 on August 03, 2008, 10:41:07 pm ---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:
--- End quote ---
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 ):
--- Code: ---wxString wxStandardPaths::GetPluginsDir() const
{
return AppendAppName(GetInstallPrefix() + _T("/lib"));
}
--- End code ---
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.
TheTuxKeeper:
--- Quote ---/lib64 and /lib32 : 64/32-bit libraries (architecture dependent)
The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place 64-bit libraries in /lib64, and 32-bit (or 31-bit on s390) libraries in /lib.
--- End quote ---
Quote from http://www.pathname.com/fhs/pub/fhs-2.3.html#LIB64 (seems to be the official fhs doc)
EDIT: hit the "post" instead of "preview"
So the wxwidgets function seems to be "wrong". I haven't used amd64 (though i have a capable cpu), but i think suse handles it very strict (no symlinking lib64->lib).
But storing the path before compiling should work like the autorevision header. I think that's the best way.
Jenna:
--- Code: ---/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]
--- End code ---
quote from: http://www.pathname.com/fhs/pub/fhs-2.3.html#LIBLTQUALGTALTERNATEFORMATESSENTIAL
--- Code: ---[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.
--- End code ---
quote from: http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN890
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...?).
TheTuxKeeper:
--- Quote from: jens on August 04, 2008, 01:11:48 am ---But all that does not really solve the problem on Suse11 (what about earlier Suse distros and e.g. Fedora...?).
--- End quote ---
I'll take a look at this at the evening. But for suse I think this should be all the same at least since 10.1 (the enterprise versions are based on this one).
TheTuxKeeper:
Sorry for the long "offline" time. i've made the patch ready for rev5280, but didn't solve the 64bit problem, when lib and lib64 aren't the same (symlink).
[ Patch #2529 ] patch to move plugins to /usr/lib/codeblocks/plugins
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version