MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013155CMake(No Category)public2012-04-19 16:422015-08-20 10:10
ReporterMathieu Malaterre 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake 2.8.8 
Target VersionCMake 2.8.9Fixed in VersionCMake 2.8.9 
Summary0013155: Allow option to build module without SONAME
DescriptionIt would really be nice if there was an option to build module without SONAME.

Java/C# or even python module do not support the UNIX/SONAME mecanism. It is even considered an error in some case, eg. debian policy:


              The indicated symbol has not been found in the libraries linked
              with the binary. The binary is most likely a plugin and the sym-
              bol is probably provided by the program that loads this plugin.
              In theory a plugin doesn't have any SONAME but this binary does
              have one and as such it could not be clearly identified as such.
              However the fact that the binary is stored in a non-public
              directory is a strong indication that's it's not a normal shared
              library. If the binary is really a plugin, then disregard this
              warning. But there's always the possibility that it's a real
              library and that programs linking to it are using an RPATH so
              that the dynamic loader finds it. In that case, the library is
              broken and needs to be fixed.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0015705closed Brad King Sets SONAME for modules 
Attached Filespatch 0001-Support-building-shared-libraries-or-modules-without.patch (13,954) 2012-04-22 13:21
https://public.kitware.com/Bug/file/4313/0001-Support-building-shared-libraries-or-modules-without.patch
Issue History
Date ModifiedUsernameFieldChange
2012-04-19 16:42Mathieu MalaterreNew Issue
2012-04-19 16:42Mathieu MalaterreNote Added: 0029266
2012-04-19 16:54Brad KingNote Added: 0029267
2012-04-20 11:41Brad KingNote Added: 0029270
2012-04-20 11:49Mathieu MalaterreNote Added: 0029271
2012-04-20 12:01Brad KingNote Added: 0029272
2012-04-20 14:23Ben BoeckelNote Added: 0029273
2012-04-20 14:25Ben BoeckelNote Added: 0029274
2012-04-21 12:38Mathieu MalaterreNote Added: 0029294
2012-04-21 12:38Mathieu MalaterreNote Edited: 0029294bug_revision_view_page.php?bugnote_id=29294#r621
2012-04-22 11:47Modestas VainiusNote Added: 0029296
2012-04-22 13:21Modestas VainiusFile Added: 0001-Support-building-shared-libraries-or-modules-without.patch
2012-04-22 13:22Modestas VainiusNote Added: 0029299
2012-04-23 09:02Brad KingAssigned To => Brad King
2012-04-23 09:02Brad KingStatusnew => assigned
2012-04-23 09:57Brad KingNote Added: 0029309
2012-04-23 09:58Brad KingNote Added: 0029310
2012-04-23 11:40Brad KingNote Added: 0029316
2012-04-24 10:08Brad KingNote Added: 0029324
2012-04-24 10:08Brad KingAssigned ToBrad King =>
2012-04-24 10:08Brad KingStatusassigned => backlog
2012-04-28 16:54Modestas VainiusNote Added: 0029363
2012-04-29 02:40Modestas VainiusNote Added: 0029364
2012-04-30 13:02Brad KingAssigned To => Brad King
2012-04-30 13:02Brad KingStatusbacklog => assigned
2012-04-30 13:05Brad KingNote Added: 0029372
2012-04-30 14:35Brad KingTarget Version => CMake 2.8.9
2012-05-02 15:10Modestas VainiusNote Added: 0029385
2012-05-02 15:25Brad KingNote Added: 0029386
2012-05-02 15:28Brad KingNote Added: 0029387
2012-05-02 15:28Brad KingStatusassigned => resolved
2012-05-02 15:28Brad KingFixed in Version => CMake 2.8.9
2012-05-02 15:28Brad KingResolutionopen => fixed
2012-10-01 13:22David ColeNote Added: 0031117
2012-10-01 13:22David ColeStatusresolved => closed
2015-08-20 10:10Brad KingRelationship addedrelated to 0015705

Notes
(0029266)
Mathieu Malaterre   
2012-04-19 16:42   
Adding reference to discussion on cmake mailing list:

http://www.cmake.org/pipermail/cmake/2012-April/049889.html [^]
(0029267)
Brad King   
2012-04-19 16:54   
Non-compatible quick hack to try:
diff --git a/Source/cmMakefileLibraryTargetGenerator.cxx b/Source/cmMakefileLibraryTargetGenerator.cxx                                            

index 38aa59d..b830742 100644
--- a/Source/cmMakefileLibraryTargetGenerator.cxx
+++ b/Source/cmMakefileLibraryTargetGenerator.cxx                                                                                                            

@@ -714,7 +714,10 @@ void cmMakefileLibraryTargetGenerator::WriteLibraryRules                                                                                
   
std::string linkString = linklibs.str();                                                                                                                  
   
vars.LinkLibraries = linkString.c_str();
   vars.ObjectsQuoted = buildObjs.c_str();
-  vars.TargetSOName= targetNameSO.c_str();
+  if(this->Target->GetType() == cmTarget::SHARED_LIBRARY)
+    {
+    vars.TargetSOName = targetNameSO.c_str();
+    }
   vars.LinkFlags = linkFlags.c_str();
 
   // Compute the directory portion of the install_name setting.
(0029270)
Brad King   
2012-04-20 11:41   
Another quick hack that may work without modifying CMake:

string(REPLACE "<CMAKE_SHARED_LIBRARY_SONAME_C_FLAG><TARGET_SONAME>" "" CMAKE_C_CREATE_SHARED_MODULE "${CMAKE_C_CREATE_SHARED_MODULE}")
(0029271)
Mathieu Malaterre   
2012-04-20 11:49   
To make things clear, I need to be able from a single cmake project, to:

1. generate shared libs with SONAME/SOVERSION information.
2. generate python, java & C# modules without SONAME (they actually link to libs (1) ).

So only module or on a per target based can I remove SONAME
(0029272)
Brad King   
2012-04-20 12:01   
Re 0013155:0029271: The hack suggested in 0013155:0029270 modifies CMAKE_C_CREATE_SHARED_MODULE, not CMAKE_C_CREATE_SHARED_LIBRARY, so it should only influence modules.

Since CMake disallows linking to modules anyway it would make sense to always build modules without any soname. We just need to think about compatibility issues, if any.
(0029273)
Ben Boeckel   
2012-04-20 14:23   
I don't think this is a bug. I have projects which build soname-less libraries just fine back to cmake-2.8.6. How are you building the libraries? add_library works just find if you don't set the SOVERSION or VERSION properties with a set_target_properties.
(0029274)
Ben Boeckel   
2012-04-20 14:25   
Ah, nevermind, I see what you mean now. I misread it as SOVERSION. Sorry for the noise.
(0029294)
Mathieu Malaterre   
2012-04-21 12:38   
Re 0013155:0029270: Here is what I did:

https://github.com/malaterre/PublicRep/blob/master/CMake/test1/CMakeLists.txt [^]

This does not seems to be working at least not with cmake 2.8.5 or 2.8.7

I can still see:


$ readelf -d /usr/local/lib/liblib2.so

Dynamic section at offset 0x658 contains 22 entries:
  Tag Type Name/Value
 0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
 0x000000000000000e (SONAME) Library soname: [liblib2.so]

Thanks much
(0029296)
Modestas Vainius   
2012-04-22 11:47   
Right now I'm writing a patch which would add NO_SONAME property to achieve this. I will post it later.
(0029299)
Modestas Vainius   
2012-04-22 13:22   
That's what I came up with (0001-Support-building-shared-libraries-or-modules-without.patch). Please check if it's any good.
(0029309)
Brad King   
2012-04-23 09:57   
Re 0013155:0029299: Fantastic, thanks. I've applied the patch with minor modifications:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2d951c1d [^]

and added a test:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=69626f02 [^]
(0029310)
Brad King   
2012-04-23 09:58   
Re 0013155:0029294: The workaround must be applied after the project command so that C is already enabled.
(0029316)
Brad King   
2012-04-23 11:40   
Re 0013155:0029309: One additional change to fix OS X Framework support after the main patch:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6ad39679 [^]
(0029324)
Brad King   
2012-04-24 10:08   
Unfortunately I had to revert the entire feature due to some subtle problems explained in the commit message:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1a25d0ee [^]

Moving to backlog until someone has time to address these problems and provide a new implementation of the feature. At that point we can recover the test code from the reverted topic.
(0029363)
Modestas Vainius   
2012-04-28 16:54   
I fixed all problems you mentioned in 1a25d0ee. However, I didn't reimplement the feature as you suggested in the commit because I felt like messing with LINK_FLAGS depending on the presence or absence of some other variable was kind of awkward and non-straightforward from the design perspective. Fortunately, the problems were pretty easy to fix in my original implementation (see the last 3 commits in [1],[2]). I committed on top of your topic branch in order to make clear what changes I made. Feel free to ask if I need to provide a patch in some other form.

[1] http://anonscm.debian.org/gitweb/?p=users/modax/cmake.git;a=shortlog;h=refs/heads/no-soname [^]
[2] git://anonscm.debian.org/users/modax/cmake.git [^]
(0029364)
Modestas Vainius   
2012-04-29 02:40   
I have just pushed another small fix to the repo (fc2605a5).

By the way, just in case you absolutely want TARGET_SONAME and TARGET_INSTALLNAME_DIR (I omit SONAME_FLAG since it's already new) to expand regardless of NO_SONAME property, we could leave them alone as they were and introduce another set of variables like TARGET_SONAME_IF_ON and TARGET_INSTALLNAME_DIR_IF_ON and use them in platform files.

Personally, I think it's not necessary as NO_SONAME property is new and one has to turn it on explicitly to kick in at all. Therefore, the patch should not break existing sources.
(0029372)
Brad King   
2012-04-30 13:05   
Re 0013155:0029363: Wonderful, thanks for following through on this!

I revived the original topic by reverting the revert and then merged your topic into it:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=71f64e75 [^]

This will keep your commits in the history of 'next' for reference.

Then I rewrote the topic to squash together all of your commits and add my test for the feature:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e1409ac5 [^]
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fdb3f878 [^]

This cleaned up version of the topic will be suitable for merge to 'master' after testing in 'next'.
(0029385)
Modestas Vainius   
2012-05-02 15:10   
Sigh, looks like I managed to make a few typos in NO_SONAME description. Here is a patch.

From b081f03c2fda432aa5a782211b43ff8ae721c2ef Mon Sep 17 00:00:00 2001
From: Modestas Vainius <modax@debian.org>
Date: Wed, 2 May 2012 22:06:35 +0300
Subject: [PATCH] Fix a few typos in NO_SONAME property description.

---
 Source/cmTarget.cxx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 4789197..c9bb006 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -832,7 +832,7 @@ void cmTarget::DefineProperties(cmake *cm)
      "plugins. If you use it on normal shared libraries which other targets "
      "link against, on some platforms a linker will insert a full path to "
      "the library (as specified at link time) into the dynamic section of "
- "the dependant binary. Therefore, once installed, dynamic linker may "
+ "the dependent binary. Therefore, once installed, dynamic loader may "
      "eventually fail to locate the library for the binary.");
 
   cm->DefineProperty
--
1.7.10
(0029386)
Brad King   
2012-05-02 15:25   
Re 0013155:0029385: Thanks:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1aa52163 [^]
(0029387)
Brad King   
2012-05-02 15:28   
The topic mentioned in 0013155:0029372 passed testing everywhere and has been merged to 'master'. The typo fixes are in 'next' and will go in 'master' during next week's integration session.

I'm resolving this issue as "fixed".
(0031117)
David Cole   
2012-10-01 13:22   
Closing resolved issues that have not been updated in more than 4 months.