View Issue Details Jump to Notes ] Print ]
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.
TagsNo tags attached.
Attached Filespatch file icon 0001-Support-building-shared-libraries-or-modules-without.patch [^] (13,954 bytes) 2012-04-22 13:21 [Show Content]

 Relationships
related to 0015705closedBrad King Sets SONAME for modules 

  Notes
(0029266)
Mathieu Malaterre (developer)
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 (manager)
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 (manager)
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 (developer)
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 (manager)
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 (developer)
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 (developer)
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 (developer)
2012-04-21 12:38
edited on: 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 (reporter)
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 (reporter)
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 (manager)
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 (manager)
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 (manager)
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 (manager)
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 (reporter)
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 (reporter)
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 (manager)
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 (reporter)
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 (manager)
2012-05-02 15:25

Re 0013155:0029385: Thanks:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1aa52163 [^]
(0029387)
Brad King (manager)
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 (manager)
2012-10-01 13:22

Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2012-04-19 16:42 Mathieu Malaterre New Issue
2012-04-19 16:42 Mathieu Malaterre Note Added: 0029266
2012-04-19 16:54 Brad King Note Added: 0029267
2012-04-20 11:41 Brad King Note Added: 0029270
2012-04-20 11:49 Mathieu Malaterre Note Added: 0029271
2012-04-20 12:01 Brad King Note Added: 0029272
2012-04-20 14:23 Ben Boeckel Note Added: 0029273
2012-04-20 14:25 Ben Boeckel Note Added: 0029274
2012-04-21 12:38 Mathieu Malaterre Note Added: 0029294
2012-04-21 12:38 Mathieu Malaterre Note Edited: 0029294
2012-04-22 11:47 Modestas Vainius Note Added: 0029296
2012-04-22 13:21 Modestas Vainius File Added: 0001-Support-building-shared-libraries-or-modules-without.patch
2012-04-22 13:22 Modestas Vainius Note Added: 0029299
2012-04-23 09:02 Brad King Assigned To => Brad King
2012-04-23 09:02 Brad King Status new => assigned
2012-04-23 09:57 Brad King Note Added: 0029309
2012-04-23 09:58 Brad King Note Added: 0029310
2012-04-23 11:40 Brad King Note Added: 0029316
2012-04-24 10:08 Brad King Note Added: 0029324
2012-04-24 10:08 Brad King Assigned To Brad King =>
2012-04-24 10:08 Brad King Status assigned => backlog
2012-04-28 16:54 Modestas Vainius Note Added: 0029363
2012-04-29 02:40 Modestas Vainius Note Added: 0029364
2012-04-30 13:02 Brad King Assigned To => Brad King
2012-04-30 13:02 Brad King Status backlog => assigned
2012-04-30 13:05 Brad King Note Added: 0029372
2012-04-30 14:35 Brad King Target Version => CMake 2.8.9
2012-05-02 15:10 Modestas Vainius Note Added: 0029385
2012-05-02 15:25 Brad King Note Added: 0029386
2012-05-02 15:28 Brad King Note Added: 0029387
2012-05-02 15:28 Brad King Status assigned => resolved
2012-05-02 15:28 Brad King Fixed in Version => CMake 2.8.9
2012-05-02 15:28 Brad King Resolution open => fixed
2012-10-01 13:22 David Cole Note Added: 0031117
2012-10-01 13:22 David Cole Status resolved => closed
2015-08-20 10:10 Brad King Relationship added related to 0015705


Copyright © 2000 - 2018 MantisBT Team