[Linux] Moving arch-dependent plugins out of /usr/share

Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

<< < (5/5)

Jenna:

--- Quote from: Mephistopheles on November 16, 2009, 08:33:50 am ---Point being that you need said patch for Fedora, Mandriva and openSUSE x86_64 but you people seem not to care or not to need it on debian installs.

So how is it on .deb installs, isn't the wxWidgets stuff in /usr/lib64 or .... ?

--- End quote ---

I don't have Fedora, Mandriva or openSUSE, so I cannot test anything, I don't like to commit changes, that I cannot test myself, but I might do so in this case, if it does not break distros I can test.
Additional, there are so many other things to do, that I just forgot this problem, sorry.

The wxWidgets libs are in /usr/lib on debian, but debian links it to /usr/lib64, so your patch should work.

My problem with the patch is, that according to the fhs the libs should reside in /usr/lib, not in /usr/lib64 :

--- Quote from: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA ---/usr/lib : Libraries for programming and packages
Purpose

/usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts. [22]

Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory. [23]
--- End quote ---

/usr/lib64 or /usr/lib32 should be used for alternate formats:

--- Quote from: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLTQUALGTALTERNATEFORMATLIBRARI ---/usr/lib<qual> : Alternate format libraries (optional)
Purpose

/usr/lib<qual> performs the same role as /usr/lib for an alternate binary format, except that the symbolic links /usr/lib<qual>/sendmail and /usr/lib<qual>/X11 are not required. [26]

--- End quote ---

In my eyes it means on 64-bit systems the real 64-libs should reside in /usr/lib and additional 32-bit libs have to use /usr/lib32 and vice-versa.

Nevertheless, I will look into the problem.

Thanks again for reminding.

Jenna:
The patch can not be applied in this form, because it breaks install, if prefix is not /usr (at least on debian).
/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:

--- Code: ---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

--- End code ---

Mephistopheles:
Sorry for taking so long to reply but I got distracted by some other stuff.

Anyways, I tested your modified patch and it seems to work nicely so please apply it to trunk if no one else has a problem with it. Also thanks a lot for looking into this.

Navigation

[0] Message Index

[*] Previous page

Go to full version