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

[jens]

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 attach a 7z-zipped file containing the new layout of the C::B files if configured to build all contrib-plugins.



[attachment deleted by admin]

[TheTuxKeeper]

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

Code:

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

[pedro]

This patch is working for Slamd64. Thank you!

[Mephistopheles]

Bump ...

I'm kinda confused if I'm missing the obvious here because without that patch the plugins wont work on a 64bit system so I had guessed you would give it a bigger priority.

IMHO the patch is fine for packaging C::B to make it "just work" but the correct solution actually would be that wxStandardPathsBase::Get().GetPluginsDir() should return the correct path in the first place. Could you therefore please get in touch with the wxWidgets folks (the function name kinda sounds like it would come from there) and find a way to get that solved properly?

[Mephistopheles]

My apologies for bumping that one once again but I just don't feel comfortable with carrying around that patch all the time.

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 .... ?

If it is in /usr/lib64 then how do you get it working there? And if it isn't could you please think about how to get that "hack" into the trunk so it works on said distros (at least until wxStandardPathsBase::Get().GetPluginsDir() returns the proper path)?

If you want to give it a try you can find binaries at http://download.opensuse.org/repositories/devel:/tools:/ide/

[jens]

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 .... ?

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 :

/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]

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

/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]

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.

[jens]

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
 

[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.