oxygen-gtk2 (as well as oxygen-gtk3!) define liboxygen-gtk as a shared library instead of as a plugin (cf `src/CMakeLists.txt`). I cannot judge whether this is the more appropriate type declaration, but it appears that gtk-engines are expected to have the `.so` extension. Declaring the engine as a shared library causes it to have a `.dylib` extension on OS X, which renders the theme dysfunctional. Reproducible: Always Steps to Reproduce: 1. Build oxygen-gtk2 2. Install the theme 3. Try to use it Actual Results: The theme is dysfunctional or does not even show up in the list of installed themes. Expected Results: Theme can be selected and functions as it should Replacing all `liboxygen-gtk.dylib` with `liboxygen-gtk.so` after running cmake, in all files generated by cmake (build.make, link.txt etc) is a sufficient workaround to resolve the issue, but not an elegant fix.
I don't have any MacOSX near me, so I'll try doing some guesswork on how this should be prepared to work there. As I've googled, the plugin is expected to be a so called "bundle" instead of a shared lib, so following cmake docs [1], here's my first attempt. Does the following patch produce what you'd expect on MacOSX? (and does it actually work after installing?) --------cut here---------- diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt index 7e9fe07..3f8bfdc 100644 --- a/src/CMakeLists.txt +++ b/src/CMakeLists.txt @@ -77,7 +77,7 @@ set( oxygen_gtk_SOURCES oxygenwindowshadow.cpp ) -add_library( oxygen-gtk SHARED ${oxygen_gtk_SOURCES} ) +add_executable( oxygen-gtk MACOSX_BUNDLE ${oxygen_gtk_SOURCES} ) # Add debug cflags set( CMAKE_CXX_FLAGS " -Wall -g ${CMAKE_CXX_FLAGS}" ) ----------cut here--------------- [1] http://www.cmake.org/Wiki/CMake:Bundles_And_Frameworks
Interesting. I thought bundle were for executables, not libraries. My take on this is that dynlib *is* the correct extension for shared libraries on MAC (I'd bee curious to look at the extension for the gtk librararies for instance (libgtkxxx.xxx), and that what cmake is doing is the correct thing. What is not correct is that gtk, under MACOS look for plugins (our liboxygen-gtk.xxx), in the form of something .so and not something.dynlib. That would make this an upstream bug ...
(In reply to Hugo Pereira Da Costa from comment #2) > Interesting. I thought bundle were for executables, not libraries. > My take on this is that dynlib *is* the correct extension for shared > libraries on MAC (I'd bee curious to look at the extension for the gtk > librararies for instance (libgtkxxx.xxx), and that what cmake is doing is > the correct thing. > What is not correct is that gtk, under MACOS look for plugins (our > liboxygen-gtk.xxx), in the form of something .so and not something.dynlib. > That would make this an upstream bug ... (meant .dylib and not .dynlib)
@Hugo Actually no, GTK is correct, From what I've read on the Internet, MacOSX shared libs are what is linked by `-lfoo` at linking stage (and thus loaded by dynamic linker at app startup), while bundles are the things which are loaded as plugins, which oxygen-gtk is.
Couple things: - a "bundle" as in "something loaded as a plugin" is *not* the same thing as a bundle that has the form of a directory on disk (e.g. an app bundle or a framework bundle). That's not to say that you cannot "bundle a bundle" together with who knows what files it might need, but if you just use the linker's -bundle flag, you'll get a binary file that on first sight is not different from a shared library. - OS X can use shared libraries (true .dylibs) as well as frameworks as plugins, i.e. you can load and use them with dlopen and dlsym. - Idem for a "bundle" , but you cannot use that as a shared library - creating something as a bundle doesn't change the extension (but CMake's macro might; I haven't tried yet) - bundles can have a designated loader, which means that they have access to that loader's symbols without having to import them explicitly at runtime. That last part is the only difference that I know of that justifies building things as "bundles". Where GTk is wrong is that it expects the engines it loads dynamically to have a .so extension. Then again KDE4 isn't any different: my /opt/local/lib/kde4 directory has a whole load of .so files. The easiest fix would be to use CMake's syntax to change the extension used for liboxygen-gtk. I know it's possible, just don't remember how.
Scrap that last comment: the easiest will be to use add_library( oxygen-gtk MODULE ${oxygen_gtk_SOURCES} ) That's cmake's official way to declare a plugin, and from what I can see all my other style engines (including QtCurve-gtk2) are built that way.
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.