Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmake: cannot link against static ilmbase libraries #125

Closed
chadrik opened this issue Aug 13, 2014 · 1 comment
Closed

cmake: cannot link against static ilmbase libraries #125

chadrik opened this issue Aug 13, 2014 · 1 comment
Labels
Build A problem with building or installing the library.
Milestone

Comments

@chadrik
Copy link

chadrik commented Aug 13, 2014

I was trying to build openexr and link it against static ilmbase libraries, but it does not work. I dug through the CMakeLists.txt files a bit, and the basic problem is that the full paths to libraries are not used when calling TARGET_LINK_LIBRARIES().

Cmake encourages authors to be very explicit about exactly what libraries are used. Calling TARGET_LINK_LIBRARIES() without full paths defers to the native linking tool's own search system, which makes building unpredictable across platforms and gives the user less control for specifying what libraries to use (see below for more on this). This is what is being done in openexr:

TARGET_LINK_LIBRARIES ( dwaLookups
  Half
  Iex${ILMBASE_LIBSUFFIX}
  IlmThread${ILMBASE_LIBSUFFIX}
  ${PTHREAD_LIB}
)

The typical way to use cmake is to write a FindFoo.cmake which fills out a set of variables. Unfortunately, the exact naming convention varies, but it is commonly Foo_FOUND, Foo_LIBRARIES, and Foo_INCLUDE_DIRS (there is no solid convention for whether Foo should be all caps or not. see the native FindBoost vs FindOpenSSL). If a package provides many libraries, there will often be variables for each individual library: Foo_Bar_LIBRARY for libBar, etc (again, no solid convention on whether to make Bar all caps).

If you don't make a FindFoo.cmake file, at the very, very least, you should use FIND_LIBRARY() to get the path to the library, so that users can affect this search using environment variables like CMAKE_PREFIX_PATH and CMAKE_LIBRARY_PATH. More importantly, using the cmake find functions, like FIND_LIBRARY(), ensures that all of your variables contain the full path to the file or directory, not just a name.

Then, when you link, you provide the variable holding list of full paths to the libraries, like so:

TARGET_LINK_LIBRARIES ( dwaLookups
  ${ILMBase_LIBRARIES}
  ${PTHREAD_LIB}
)

Or specify individual libraries, if needed:

TARGET_LINK_LIBRARIES ( dwaLookups
  ${ILMBase_Half_LIBRARY}  ${ILMBase_Iex_LIBRARY}   ${ILMBase_IlmThread_LIBRARY}
  ${PTHREAD_LIB}
)

Here is an example FindILMBase.cmake: https://github.com/nerdvegas/vfxcmake/blob/master/cmake/FindILMBase.cmake

One nice feature of this module is that it gives the user control over whether to search for static libraries, using ILMBase_USE_STATIC_LIBS (a convention borrowed from FindBoost.cmake).

I co-maintain this project, so let me talk to the other author and see if we can get the license changed to BSD so you can just use it.

chad.

@kdt3rd
Copy link
Contributor

kdt3rd commented Jul 17, 2019

A complete refactor of the cmake has taken place, modernizing cmake to match the "Modern CMake" guidelines and practices, and no longer uses the Find* mechanisms, but rather should use the suggested cmake config mechanisms that go into /usr/lib/cmake// and find_package knows how to search for and generate import libraries. We also have switched to standard BUILD_SHARED_LIBS, but also have an option to generate both static and shared, and when you use the imported libraries, you can target the default or the static (both are there as explicit library names if you do both).

Thanks for the report!

@kdt3rd kdt3rd closed this as completed Jul 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Build A problem with building or installing the library.
Projects
None yet
Development

No branches or pull requests

3 participants