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

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

<< < (4/5) > >>

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

--- Quote from: jens on December 14, 2008, 10:42:33 am ---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).

--- End quote ---

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
--- End code ---

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/

Navigation

[0] Message Index

[#] Next page

[*] Previous page