Notes
(0036716) René J.V. Bertin (reporter) 2014-09-03 10:51	I labelled this as a minor issue because it doesn't seem to concern a very common use case. But it's a major/blocking issue when it does manifest itself.

(0036717) Brad King (manager) 2014-09-03 11:00	CMAKE_SHARED_MODULE_CREATE_${lang}_FLAGS is used for targets created with the add_library command's MODULE mode. These are meant for dynamically loadable plugins and not for libraries that can be linked. If you want to be able to link to a library then use the add_library command's SHARED mode to create it.

(0036718) Brad King (manager) 2014-09-03 11:02	From the add_library documentation: http://www.cmake.org/cmake/help/v3.0/command/add_library.html [^] "MODULE libraries are plugins that are not linked into other targets but may be loaded dynamically at runtime using dlopen-like functionality."

(0036719) René J.V. Bertin (reporter) 2014-09-03 11:07	Well, if modules are supposed to be impossible to use as shared libraries, there's a bug with the implementation on Linux, because there they can be. I doubt sincerely that my suggested modifications will cause issues creating plugins on OS X. I've stopped using -bundle in my own projects a long time ago and never encountered the slightest problem.

(0036722) Brad King (manager) 2014-09-03 11:27	Re 0015126:0036719: Some platforms distinguish plugin modules from shared libraries and some do not. CMake has both MODULE and SHARED in order to model this concept. If you write cmake_minimum_required(VERSION 2.8) project(myproj) add_library(myplugin MODULE myplugin.c) add_executable(myexe myexe.c) target_link_libraries(myexe myplugin) CMake will complain that you can't link to modules. We have no way to enforce the restriction outside of CMake on platforms that do not make a distinction. Some projects create a shared library to contain everything in the plugin except a stub initialization function, and then create a plugin that has the stub init function and links to the shared library. That way the plugin can be dlopen-ed or linked everywhere by choosing the right variant. Still, on modern OS X it is a reasonable proposal to implement both with -dynamiclib anyway.

(0036725) René J.V. Bertin (reporter) 2014-09-03 13:21	I was hoping you'd say that ... :) I don't know what reason the few projects I know of have to do things the way they do, but I could think of reasons to use something as both a shared library and a plugin. In fact, it's not because some platforms treat them differently (MS...?) that that's a good idea ...

(0036726) Brad King (manager) 2014-09-03 15:06	Re 0015126:0036725: Well, after looking into this more and reading http://stackoverflow.com/questions/2339679/what-are-the-differences-between-so-and-dylib-on-osx [^] I do not think we can simply change the flag CMake uses. The file types are different. If we just change the flag then the type of binary will depend on the version of CMake used. The preferred file names are different (.so -> .dylib), so if we change the binary type we should also change the file name. Both of these will change behavior for existing projects. KDE's Calligra suite is doing something wrong (from a CMake point of view) if it tries to link to a library created with the add_library MODULE mode. The add_library documentation I linked earlier says this should not be done. This issue should be raised with them whether or not anything changes here.

(0036727) René J.V. Bertin (reporter) 2014-09-03 15:32	For loadable modules, the "extension .bundle is recommended by Apple, but most ported software uses .so for the sake of compatibility." That's from the page you referred to, which quotes (and updates) a page hosted by the Fink project. I agree with the ".so for the sake of compatibility", though I think it's often more a question of laziness to leave the linux-standard .so extension and not replace it with a Mac-specific one. After all, the extension only counts when you want to do -l style linking. In addition, looking at "https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/MachOTopics/1-Articles/loading_code.html#//apple_ref/doc/uid/TP40001830-97384-BABJCDDD", [^] we have "In general, for applications or libraries targeted for OS X v10.4 or later, use the dynamic loader compatibility functions, defined in /usr/include/dlfcn.h, to load and link bundle files. These functions are the preferred way to load code at runtime. They are particularly helpful when porting UNIX tools that support plug-ins to OS X. See “Dynamic Loader Compatibility Functions” in OS X ABI Dynamic Loader Reference for more information." I think CMake's point of view will have to take into consideration what kind of software projects will be using it. MH_BUNDLE objects may be so Mac/OS X specific that they are basically only created in Xcode projects, and that no cross-platform project will need or even want to generate them when creating modules. If that analysis is correct, CMake's aims to be a cross-platform tool would probably not be helped by generating MH_BUNDLE objects instead of more generic/standard ones. Again, I have never had the need to resort to bundle objects when creating plugins on OS X (admittedly in cross-platform code). In fact, I was relieved when 10.4 made it possible to do things almost exactly the same way as on Linux.

(0036730) Brad King (manager) 2014-09-03 19:25	Re 0015126:0036727: Using -bundle was a design decision made in CMake back when it was necessary on OS X (10.2?) to get loadable modules working. It is still a valid approach today. The bug you are encountering is not in CMake. It is in the project using CMake that does add_library(foo MODULE ...) and then later expects something to link to foo. By using MODULE, it tells CMake that no one is expecting to link to the library. Once that happens, CMake is free to make a non-linkable library file as it happens to do on OS X. No, CMake doesn't have to do this on modern OS X, but it is allowed to do so because the project said so by declaring it with MODULE. If the library is meant to be linked, then it should be added by add_library(foo SHARED ...) It can still by dynamically loaded as a plugin if desired. The project in question should be fixed to do this if the library is to be linked by anyone.

(0042619) Kitware Robot (administrator) 2016-06-10 14:29	Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Issue History
Date Modified	Username	Field	Change
2014-09-03 10:49	René J.V. Bertin	New Issue
2014-09-03 10:49	René J.V. Bertin	File Added: patch-SHARED_BUNDLE_flag.diff
2014-09-03 10:51	René J.V. Bertin	Note Added: 0036716
2014-09-03 11:00	Brad King	Note Added: 0036717
2014-09-03 11:02	Brad King	Note Added: 0036718
2014-09-03 11:07	René J.V. Bertin	Note Added: 0036719
2014-09-03 11:27	Brad King	Note Added: 0036722
2014-09-03 13:21	René J.V. Bertin	Note Added: 0036725
2014-09-03 15:06	Brad King	Note Added: 0036726
2014-09-03 15:32	René J.V. Bertin	Note Added: 0036727
2014-09-03 19:25	Brad King	Note Added: 0036730
2016-06-10 14:29	Kitware Robot	Note Added: 0042619
2016-06-10 14:29	Kitware Robot	Status	new => resolved
2016-06-10 14:29	Kitware Robot	Resolution	open => moved
2016-06-10 14:29	Kitware Robot	Assigned To	=> Kitware Robot
2016-06-10 14:31	Kitware Robot	Status	resolved => closed

Relationships