View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0013155 | CMake | (No Category) | public | 2012-04-19 16:42 | 2015-08-20 10:10 | ||||
Reporter | Mathieu Malaterre | ||||||||
Assigned To | Brad King | ||||||||
Priority | normal | Severity | minor | Reproducibility | have not tried | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | CMake 2.8.8 | ||||||||
Target Version | CMake 2.8.9 | Fixed in Version | CMake 2.8.9 | ||||||
Summary | 0013155: Allow option to build module without SONAME | ||||||||
Description | It 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. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | 0001-Support-building-shared-libraries-or-modules-without.patch [^] (13,954 bytes) 2012-04-22 13:21 [Show Content] | ||||||||
Relationships | ||||||
|
Relationships |
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. |
Notes |
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 |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |