[CMake] Override of link flag for one specific shared library

David Cole david.cole at kitware.com
Thu Sep 11 14:44:32 EDT 2008


ADD_SUBDIRECTORY is the "right" thing to be using. SUBDIRS is deprecated,
but they process things subtly differently, so I just wanted to rule out
that you might be encountering a "SUBDIRS side effect"...
You've ruled it out.

Could you re-organize such that libraries with different flags are in
different CMakeLists files?


On Mon, Sep 8, 2008 at 3:02 AM, Martin Apel <martin.apel at simpack.de> wrote:

> I am using ADD_SUBDIRECTORY. I did'nt know, that anything like SUBDIRS
> exists and haven't found anything in the documentation about it.
>
> Martin
>
>
> David Cole wrote:
> > Are you using SUBDIRS or ADD_SUBDIRECTORY in your project...?
> >
> >
> > On Thu, Sep 4, 2008 at 2:42 AM, Martin Apel <martin.apel at simpack.de
> > <mailto:martin.apel at simpack.de>> wrote:
> >
> >     Unfortunately this does not work. It seems that CMake generates all
> >     libraries defined in one CMakeLists.txt with the setting of
> >     CMAKE_SHARED_LINKER_FLAGS at the end of the file.
> >     This causes this setting to be applied to all libraries in the
> >     CMakeLists.txt. As I have 4 libraries in this one CMakeLists.txt,
> this
> >     doesn't help much.
> >
> >     I tried to do something like the following:
> >     SET (CMAKE_SHARED_LINKER_FLAGS "${ORIG_SHARED_LINKER_FLAGS}")
> >     ADD_LIBRARY (FortranInterface ${OBJS})
> >     SET (CMAKE_SHARED_LINKER_FLAGS "${MODIFIED_SHARED_LINKER_FLAGS}")
> >     but the FortranInterface library gets built with
> >     MODIFIED_SHARED_LINKER_FLAGS in effect.
> >
> >     I would suggest to change the order of items in the build rules for a
> >     future CMake release, such that it's possible to override general
> >     flags
> >     with a target specific property. Today the link
> >     rules look as follows:
> >     SET(CMAKE_CXX_CREATE_SHARED_LIBRARY "<CMAKE_CXX_COMPILER> ...
> >     <LINK_FLAGS> <CMAKE_SHARED_LIBRARY_CREATE_CXX_FLAGS> ....")
> >     >From my point of view it would be better to put LINK_FLAGS to the
> >     end of
> >     the list (not only for shared libraries, but in general).
> >
> >     Regards,
> >
> >     Martin
> >
> >     David Cole wrote:
> >     > Maybe save and restore the CMAKE_SHARED_LINKER_FLAGS around your
> >     reset
> >     > of it in the sub-CMakeLists.txt...?
> >     >
> >     >
> >     > On Wed, Sep 3, 2008 at 10:41 AM, Martin Apel
> >     <martin.apel at simpack.de <mailto:martin.apel at simpack.de>
> >     > <mailto:martin.apel at simpack.de <mailto:martin.apel at simpack.de>>>
> >     wrote:
> >     >
> >     >     Hi,
> >     >
> >     >     I have defined the following in a top-level CMakeLists.txt:
> >     >      SET (CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS}
> >     >     -Wl,--unresolved-symbols=ignore-in-shared-libs")
> >     >
> >     >     Now I'd like to reset this for one specific library in a
> >     subdirectory
> >     >     (in a separate CMakeLists.txt added with ADD_SUBDIRECTORY to
> >     the main
> >     >     CMakeLists.txt). I tried to use
> >     >      SET_TARGET_PROPERTIES (FortranInterface PROPERTIES LINK_FLAGS
> >     >     -Wl,--unresolved-symbols=ignore-in-object-files")
> >     >     which reverses the effect of "ignore-in-shared-libs".
> >     >     Unfortunately the
> >     >     linker rule contains the LINK_FLAGS before
> >     >     CMAKE_SHARED_LINKER_FLAGS, so
> >     >     this cannot be used to override the setting. I have also tried
> >     >     resetting
> >     >     CMAKE_SHARED_LINKER_FLAGS in the sub-CMakeLists.txt, but then
> it
> >     >     applies
> >     >     to all other
> >     >     libraries handled in this CMakeLists.txt as well.
> >     >
> >     >     Any ideas, how I can solve this problem?
> >     >
> >     >     Regards,
> >     >
> >     >     Martin
> >     >
> >     >     ____________
> >     >     Virus checked by G DATA AntiVirus
> >     >     Version: AVF 19.21 from 03.09.2008
> >     >
> >     >
> >     >     _______________________________________________
> >     >     CMake mailing list
> >     >     CMake at cmake.org <mailto:CMake at cmake.org>
> >     <mailto:CMake at cmake.org <mailto:CMake at cmake.org>>
> >     >     http://www.cmake.org/mailman/listinfo/cmake
> >     >
> >     >
> >
> >
> >     --
> >
> >     Martin Apel                                     Tel:     0049 8153
> >     9288-47
> >     Software Architect                              E-Mail:
> >      martin.apel at simpack.de <mailto:martin.apel at simpack.de>
> >
> >     INTEC GmbH                                      Tel:     0049 8153
> >     9288-0
> >     Argelsrieder Feld 13                            Fax:     0049 8153
> >     9288-11
> >     82234 Wessling                                  E-Mail:
> >      intec at simpack.de <mailto:intec at simpack.de>
> >     Germany                                         URL:
> >     http://www.simpack.com
> >
> >     ____________
> >     Virus checked by G DATA AntiVirus
> >     Version: AVF 19.22 from 03.09.2008
> >
> >
> >
>
>
> ____________
> Virus checked by G DATA AntiVirus
> Version: AVF 19.27 from 07.09.2008
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20080911/f55c3f52/attachment.htm>


More information about the CMake mailing list