#275 Plugin location on OSX....

[Daniel Kulp]

After doing a "make; make install" on OSX using the latest SVN and then running codeblocks from the installed bin directory, it's not finding any of the plugins.

Scanning for plugins in /Users/dkulp/Library/Application Support/codeblocks/share/codeblocks/plugins
Loaded 0 plugins
Scanning for plugins in /Users/dkulp/Applications/codeblocks/bin/../share/codeblocks
Loaded 0 plugins

The plugins are located in /Users/dkulp/Applications/codeblocks/lib/codeblocks/plugins so it looks like either the search path is wrong for OSX or the "make install" is putting them in the wrong location. I don't know the intent so not sure which is the proper fix.

Also note: the plugins all have ".so" extensions instead of the more normal .dylib extension on OSX.

[Teodor Petrov]

Not sure what is the correct way to fix this. But I think it has been discussed in the forum. Please search about it.

[Mojca Miklavec]

I MacPorts we also patch the sources in order to find plugins. One of our developers added this:

--- src/sdk/configmanager.cpp.orig
+++ src/sdk/configmanager.cpp
@@ -1503,8 +1503,10 @@ void ConfigManager::InitPaths()
 #ifdef CB_AUTOCONF
     if (plugin_path_global.IsEmpty())
     {
-        if (platform::windows || platform::macosx)
+        if (platform::windows)
             ConfigManager::plugin_path_global = data_path_global;
+        else if (platform::macosx)
+            ConfigManager::plugin_path_global = res_path + _T("/lib/codeblocks/plugins");
         else
         {
             // It seems we can not longer rely on wxStandardPathsBase::Get().GetPluginsDir(),

but this is not fully portable and we would need to craft a better proposal for location of the plugins on Mac.

[Teodor Petrov]

I'll test C::B on a macosx soon, so I'll see what I can do about this.

[Mojca Miklavec]

It might be nice to support this via a configure option (for both relative and absolute paths).

[Daniel Kulp]

I've been using:

ndex: src/sdk/configmanager.cpp
===================================================================
--- src/sdk/configmanager.cpp   (revision 10669)
+++ src/sdk/configmanager.cpp   (working copy)
@@ -1503,7 +1503,7 @@
 #ifdef CB_AUTOCONF
     if (plugin_path_global.IsEmpty())
     {
-        if (platform::windows || platform::macosx)
+        if (platform::windows)
             ConfigManager::plugin_path_global = data_path_global;
         else
         {
@@ -1512,7 +1512,7 @@
             // So we create the pathname manually
             ConfigManager::plugin_path_global = ((const wxStandardPaths&)wxStandardPaths::Get()).GetInstallPrefix() + _T("/lib/codeblocks/plugins");
             // first assume, we use standard-paths
-            if (!wxDirExists(ConfigManager::plugin_path_global) && wxIsPlatform64Bit())
+            if (!wxDirExists(ConfigManager::plugin_path_global) && wxIsPlatform64Bit() && !platform::macosx)
             {
                 // 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");
Index: src/sdk/pluginmanager.cpp
===================================================================
--- src/sdk/pluginmanager.cpp   (revision 10669)
+++ src/sdk/pluginmanager.cpp   (working copy)
@@ -960,6 +960,13 @@
     wxString filename;
     wxString failed;
     bool ok = dir.GetFirst(&filename, PluginsMask, wxDIR_FILES);
+    if (platform::macosx && !ok) {
+        //on osx, if built from source and not "packed" into an .app, the plugins will
+        //have a .so extension, not .dylib.  Likely should do BOTH .so and .dylib, but
+        //filespec for GetFirst doesn't allow that so would need two full scans
+        bbplugins.Add(_T("libcompiler.so"));
+        ok = dir.GetFirst(&filename, _T("*.so"), wxDIR_FILES);
+    }
     while (ok)
     {
         if (batch)

As it does two things:
1) Looks in the normal "unixy" directory structure

2) If it finds libcompiler.so, it searches for plugins named with .so instead of .dylib. When I run "make install", the plugins all are ending up as .so which wasn't being picked up due to the search of just .dylib. Searching for .so allows all the plugins to load.

[Mojca Miklavec]

An alternative could also be to change the build system to create dylib files on Mac rather than the so files.

[Daniel Kulp]

The only way I was able to do that was to remove -module from all the Makefile.am files which would likely break everything else. That said, this is not an area i have any experience with. There is likely some automake flag or tool or something, but I have no idea.

[Teodor Petrov]

As far as I can see here: http://stackoverflow.com/questions/2339679/what-are-the-differences-between-so-and-dylib-on-osx we're doing the right thing when we create the .so files. So this is better to be preserved. Are there any plugins that are .dylibs? If we have both .dylib and .so file we should change the build to produce just one of them.

[Daniel Kulp]

They seem to all be .so files. wxSmith has some dyLibs, but they are then considered shared libs linked into the libwxsmith.so.

[Teodor Petrov]

Yep, wxSmith uses some shared libs that are not plugins. So we're good to go with a .so only patch. Can you check what happens when you build cb from cb?

[Daniel Kulp]

I would have no idea how to build anything from CB... I only use it for wxSmith. All real development is done in Xcode. That said, wxSmith in the new CB isn't really usable on my Macbook right now due to http://trac.wxwidgets.org/ticket/17302 Works fine on the non-retina external display.

[Franko F]

With this patch:

Index: src/sdk/configmanager.cpp
===================================================================
--- src/sdk/configmanager.cpp   (revision 10921)
+++ src/sdk/configmanager.cpp   (working copy)
@@ -1503,8 +1503,10 @@
 #ifdef CB_AUTOCONF
     if (plugin_path_global.IsEmpty())
     {
-        if (platform::windows || platform::macosx)
+        if (platform::windows)
             ConfigManager::plugin_path_global = data_path_global;
+        else if (platform::macosx)
+            ConfigManager::plugin_path_global = data_path_global + _T("/plugins");
         else
         {
             // It seems we can not longer rely on wxStandardPathsBase::Get().GetPluginsDir(),

and make on OSX 10.11.6 and move files to CodeBlocks.app I have:

Scanning for plugins in /Users/nnn/Library/Application Support/codeblocks/share/codeblocks/plugins
Loaded 0 plugins
Scanning for plugins in /Applications/CodeBlocks.app/Contents/Resources/share/codeblocks/plugins
^^^^^^^^
Loaded 55 plugins

Regards,
frankofrank

[Franko F]

Patch for extension .dylib for plugins on OSX:

Index: configure.ac
===================================================================
--- configure.ac        (revision 10921)
+++ configure.ac        (working copy)
@@ -96,6 +96,14 @@
 PKG_CHECK_MODULES([TINYXML], [tinyxml], [HAVE_TINYXML=yes], [HAVE_TINYXML=no])
 AM_CONDITIONAL([HAVE_TINYXML], [test "$HAVE_TINYXML" = yes])

+dnl Darwin -> .dylib  Linux -> .so
+if test "x$DARWIN_TRUE" = "x" ; then
+    MODULE_SHARED_LDFLAGS="-dynamiclib"
+else
+    MODULE_SHARED_LDFLAGS="-module -shared"
+fi
+AC_SUBST(MODULE_SHARED_LDFLAGS)
+
 dnl versioning info for libtool
 dnl Note this is the ABI version which is not the same as our actual library version
 CODEBLOCKS_CURRENT=0

and in every Makefile.am for plugin "nnn":

Index: src/plugins/nnn/Makefile.am
===================================================================
--- src/plugins/nnn/Makefile.am       (revision 10921)
+++ src/plugins/nnn/Makefile.am       (working copy)
@@ -11,7 +11,7 @@

 pluginlib_LTLIBRARIES = libnnn.la

-libnnn_la_LDFLAGS = -module -version-info 0:1:0 -shared -no-undefined -avoid-version
+libnnn_la_LDFLAGS = @MODULE_SHARED_LDFLAGS@ -version-info 0:1:0 -no-undefined -avoid-version

 libnnn_la_LIBADD = ../../sdk/libcodeblocks.la $(WX_LIBS)

[Teodor Petrov]

Fixed in rev10930