Author Topic: [Linux] Moving arch-dependent plugins out of /usr/share  (Read 23614 times)

Offline TheTuxKeeper

  • Regular
  • ***
  • Posts: 293
  • daniel2000
[Linux] Moving arch-dependent plugins out of /usr/share
« on: July 08, 2008, 09:17:09 pm »
Hi,

since few weeks the openSUSE Buildservice, which I use to build packages, checks LSB/FHS-compatibility and rejects the build with too many violations (only for opensuse 11.0 and current dev). So some builds failed because of the plugin binaries in /usr/share/codeblocks/plugins since usr/share is only for arch-independent things.
Today i finished the changes for this.

My changes:
  • I had to change all plugin makefiles and rename the destination variable (libdir -> pluginlibdir), because i got a recursive variable ... error.
  • added a new path variable to the configmanager (plugin_path_global), added the initialisation and changed the return value somewhere
  • changes for the spec file and for debian

There are some things I'm not sure about:
  • Is the initilisation of plugin_path_global also working on windows and os x? i just set it to data_path_global
  • I moved the plugin path to /usr/lib/codeblocks/plugins, perhaps /usr/lib/codeblocks is better/enough?

EDIT:
Here's the complete patch (updated with changes for debian):
[ Patch #2529 ] patch to move plugins to /usr/lib/codeblocks/plugins

Thanks for testing and for all comments :)
« Last Edit: July 26, 2008, 02:19:37 pm by daniel2000 »
Nightly builds for openSUSE

Offline SharkCZ

  • Almost regular
  • **
  • Posts: 127
Re: [Linux] Moving arch-dependent plugins out of /usr/share
« Reply #1 on: July 15, 2008, 10:46:53 am »
I have done something similar for the Fedora packages, details are at http://cvs.fedoraproject.org/viewcvs/rpms/codeblocks/devel/. I think that a better place, where to report, is the bug tracker at Berlios.
Code::Blocks package maintainer for Fedora and EPEL

Offline TheTuxKeeper

  • Regular
  • ***
  • Posts: 293
  • daniel2000
Re: [Linux] Moving arch-dependent plugins out of /usr/share
« Reply #2 on: July 15, 2008, 11:04:11 am »
Yeah, right. The bugtracker is a better place. But since I'm not sure that everything is correct, i didn't want it to post there.
Will do the changes for debian too (forgot this) and then post it in the bugtracker. :)
Nightly builds for openSUSE

Offline SharkCZ

  • Almost regular
  • **
  • Posts: 127
Re: [Linux] Moving arch-dependent plugins out of /usr/share
« Reply #3 on: July 26, 2008, 11:17:54 am »
Thanks and after you will submit the bug, please post its link here too.
Code::Blocks package maintainer for Fedora and EPEL

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: [Linux] Moving arch-dependent plugins out of /usr/share
« Reply #4 on: July 26, 2008, 12:35:47 pm »
Yeah, right. The bugtracker is a better place. But since I'm not sure that everything is correct, i didn't want it to post there.
Will do the changes for debian too (forgot this) and then post it in the bugtracker. :)

If you have already done the changes for debian, it would be nice if you can post the patch, or send it to me via email.

Otherwise I will start patching the code I use for my repo to move the plugins libs away.
I think the subdir "plugins" should remain, because otherwise it looks like they belong to C::B's core libraries.

If I will have changed the "Makefile.am"s etc. and everything works for me, I will upload a patched version to my repo.

But I will not be at home the next week (no holidays, just work), that will not happen before next weekend, because I will not be able to react if problems occur during the next week.

EDIT:

There will be some more to do, at least split the packages into arch-dependen and arch-independend ones.

Offline TheTuxKeeper

  • Regular
  • ***
  • Posts: 293
  • daniel2000
Re: [Linux] Moving arch-dependent plugins out of /usr/share
« Reply #5 on: July 26, 2008, 12:50:43 pm »
I'm testing my changes atm. Have installed dpkg on my suse (uhhh, it's a strange feeling using dpkg here :mrgreen: ). Only some undefined DEB_* variable warnings (what shouldn't be serious ?) and of course ignored dependency errors ;)

I don't know if more splitting is needed, but I haven't thought about it yet and I don't know how much arch-independent files there are around. perhaps there are some good reasons to split. but imo e.g. the lib split is too much for just 2 files. but it's my opinion and I don't do this with my rpm packages. :)

EDIT:
had to disable dh_shlibdeps since dpkg hasn't any installed packages to get dependencies from. but the rest seem to be as expected. contens of the packages are fine.
Will upload the patch now and post the link here

EDIT2:
Here is the link to the patch: [ Patch #2529 ] patch to move plugins to /usr/lib/codeblocks/plugins
« Last Edit: July 26, 2008, 02:17:07 pm by daniel2000 »
Nightly builds for openSUSE

Offline pasgui

  • Almost regular
  • **
  • Posts: 165
    • LGP
Re: [Linux] Moving arch-dependent plugins out of /usr/share
« Reply #6 on: July 26, 2008, 09:07:14 pm »
Moving plugins to /usr/lib/codeblocks/ with your patch 2529 works on Ubuntu 8.04.

Regards, pasgui

[attachment deleted by admin]

Offline TheTuxKeeper

  • Regular
  • ***
  • Posts: 293
  • daniel2000
Re: [Linux] Moving arch-dependent plugins out of /usr/share
« Reply #7 on: July 26, 2008, 09:28:55 pm »
Thanks for testing :)

The changes in configmanager.cpp shouldn't affect other platforms (I don't see anything harmful). Am I right? I'm not the experienced coder, most is just theoretical knowledge ;)
Nightly builds for openSUSE

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: [Linux] Moving arch-dependent plugins out of /usr/share
« Reply #8 on: July 28, 2008, 05:51:17 am »
Thanks for testing :)

The changes in configmanager.cpp shouldn't affect other platforms (I don't see anything harmful). Am I right? I'm not the experienced coder, most is just theoretical knowledge ;)

I tested your patch and it works correctly for builds with "./configure ...", but it breaks build with "*.cbp" file on Linux, because it looks for the plugin-libs in "/usr/lib/codeblocks".

The easiest way to avoid this seems to be to I add a define that tells the compiler that it makes an "autoconf"-build.

I also created codeblocks-common, a package that contains the architecture-independent files of the main codeblocks-package.
It's a matter of taste if someone will do it this way, but I think it makes sense, because both packages have a size of 2 MB.

I uploaded the patch (also including some changes to "debian/rules"-file and the other changes I use for my repo) to my server.
You can download and have a look at it:
unpacked patch
patch packed with 7z

I tested the sources on debian sid 64bit-build (with "dpkg-buildpackage" and with .cbp-file) and on w2k (only .cbp).

I will not be reachable for the rest of the week (out for work and no internet).

Offline TheTuxKeeper

  • Regular
  • ***
  • Posts: 293
  • daniel2000
Re: [Linux] Moving arch-dependent plugins out of /usr/share
« Reply #9 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:
Nightly builds for openSUSE

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: [Linux] Moving arch-dependent plugins out of /usr/share
« Reply #10 on: August 04, 2008, 12:12:49 am »
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 ):
Code: [Select]
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.

Offline TheTuxKeeper

  • Regular
  • ***
  • Posts: 293
  • daniel2000
Re: [Linux] Moving arch-dependent plugins out of /usr/share
« Reply #11 on: August 04, 2008, 12:24:31 am »
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.
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.
« Last Edit: August 04, 2008, 12:28:58 am by daniel2000 »
Nightly builds for openSUSE

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: [Linux] Moving arch-dependent plugins out of /usr/share
« Reply #12 on: August 04, 2008, 01:11:48 am »
Code: [Select]
/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]
quote from: http://www.pathname.com/fhs/pub/fhs-2.3.html#LIBLTQUALGTALTERNATEFORMATESSENTIAL
Code: [Select]
[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.
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...?).

Offline TheTuxKeeper

  • Regular
  • ***
  • Posts: 293
  • daniel2000
Re: [Linux] Moving arch-dependent plugins out of /usr/share
« Reply #13 on: August 04, 2008, 06:56:59 am »
But all that does not really solve the problem on Suse11 (what about earlier Suse distros and e.g. Fedora...?).
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).
Nightly builds for openSUSE

Offline TheTuxKeeper

  • Regular
  • ***
  • Posts: 293
  • daniel2000
Re: [Linux] Moving arch-dependent plugins out of /usr/share
« Reply #14 on: October 21, 2008, 08:39:58 pm »
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
Nightly builds for openSUSE

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: [Linux] Moving arch-dependent plugins out of /usr/share
« Reply #15 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).

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]

Offline TheTuxKeeper

  • Regular
  • ***
  • Posts: 293
  • daniel2000
Re: [Linux] Moving arch-dependent plugins out of /usr/share
« Reply #16 on: February 17, 2009, 05:43:22 pm »
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: [Select]
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
« Last Edit: February 19, 2009, 11:53:26 am by TheTuxKeeper »
Nightly builds for openSUSE

Offline pedro

  • Single posting newcomer
  • *
  • Posts: 7
Re: [Linux] Moving arch-dependent plugins out of /usr/share
« Reply #17 on: April 06, 2009, 10:24:26 pm »
This patch is working for Slamd64. Thank you!

Offline Mephistopheles

  • Multiple posting newcomer
  • *
  • Posts: 16
Re: [Linux] Moving arch-dependent plugins out of /usr/share
« Reply #18 on: May 24, 2009, 03:31:56 pm »
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?

Offline Mephistopheles

  • Multiple posting newcomer
  • *
  • Posts: 16
Re: [Linux] Moving arch-dependent plugins out of /usr/share
« Reply #19 on: November 16, 2009, 08:33:50 am »
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/
« Last Edit: November 16, 2009, 08:38:53 am by Mephistopheles »

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: [Linux] Moving arch-dependent plugins out of /usr/share
« Reply #20 on: November 16, 2009, 10:03:08 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 .... ?

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]

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

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.

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: [Linux] Moving arch-dependent plugins out of /usr/share
« Reply #21 on: November 17, 2009, 07:54:01 am »
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: [Select]
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
 

Offline Mephistopheles

  • Multiple posting newcomer
  • *
  • Posts: 16
Re: [Linux] Moving arch-dependent plugins out of /usr/share
« Reply #22 on: November 27, 2009, 08:03:18 pm »
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.