MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015126CMakeCMakepublic2014-09-03 10:492016-06-10 14:31
ReporterRené J.V. Bertin 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformMacintosh (main)OSOS X / LinuxOS Version10.6.8
Product VersionCMake 3.0 
Target VersionFixed in Version 
Summary0015126: cmake issues -bundle instead of -dynamiclib when creating shared modules
DescriptionWhile building KDE's Calligra suite, I came across a cmake-related error causing the linker to refuse to link in 'bundle' shared objects (intended to act as plugins also) in x86_64 mode. Googling, I came across

​http://www.wireshark.org/lists/wireshark-dev/201009/msg00231.html [^] where one reads

"CMake is using -bundle rather than -dylib/-dynamiclib to build the asn1 plugin, probably so that it'll work even on versions of OS X where you can't dynamically load an MH_DYLIB."

AFAIK, that's a moot point since OS X 10.3 (or at least 10.4). Finding all CMAKE_SHARED_MODULE_CREATE definitions in /opt/local/lib/cmake{,-3.0} and replacing -bundle with -dynamiclib resolves the linking problem I encountered.

A patchfile is included.
Steps To Reproduce
Additional InformationTested on OS X 10.6.8 and 10.9.x, with cmake 2.8 and cmake 3.0 .

https://trac.macports.org/ticket/42840 [^]

I thought I already filed this bug "upstream" (from MacPorts) but apparently not here ...
TagsNo tags attached.
Relationships
Attached Filesdiff patch-SHARED_BUNDLE_flag.diff (4,089) 2014-09-03 10:49
https://public.kitware.com/Bug/file/5240/patch-SHARED_BUNDLE_flag.diff
Issue History
Date ModifiedUsernameFieldChange
2014-09-03 10:49René J.V. BertinNew Issue
2014-09-03 10:49René J.V. BertinFile Added: patch-SHARED_BUNDLE_flag.diff
2014-09-03 10:51René J.V. BertinNote Added: 0036716
2014-09-03 11:00Brad KingNote Added: 0036717
2014-09-03 11:02Brad KingNote Added: 0036718
2014-09-03 11:07René J.V. BertinNote Added: 0036719
2014-09-03 11:27Brad KingNote Added: 0036722
2014-09-03 13:21René J.V. BertinNote Added: 0036725
2014-09-03 15:06Brad KingNote Added: 0036726
2014-09-03 15:32René J.V. BertinNote Added: 0036727
2014-09-03 19:25Brad KingNote Added: 0036730
2016-06-10 14:29Kitware RobotNote Added: 0042619
2016-06-10 14:29Kitware RobotStatusnew => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:29Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0036716)
René J.V. Bertin   
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   
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   
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   
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   
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   
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   
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   
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   
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   
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.