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

Issues when using libs built with CMake on Linux #61

Closed
ppearson opened this issue Apr 14, 2013 · 6 comments
Closed

Issues when using libs built with CMake on Linux #61

ppearson opened this issue Apr 14, 2013 · 6 comments
Labels
Bug A bug in the source code Build A problem with building or installing the library.

Comments

@ppearson
Copy link

Building IlmBase 2.0 and OpenEXR 2.0 (from the website) using CMake on Linux64 works (in terms of producing the target libs), but then linking those output libs that have been built against an application doesn't work, due to the following issues:

  1. ImfNamespace.h is missing from ./IlmImf/CMakeLists.txt in the Headers INSTALL section, so that header is never installed in the target directory, so anything which needs it (OpenEXR reading/writing) can't find it.
  2. ./OpenEXR-2.0.0/IlmImf/CMakesList.txt is not adding the ilmBase libs as target link libraries, so there's unresolved symbols to all header-only (mostly constructors and destructors) at link time. Adding:
    TARGET_LINK_LIBRARIES(IlmImf -lImath -lIexMath -lHalf -lIex -lIlmThread -pthread)
    after:
    ADD_LIBRARY ( IlmImf STATIC)
    fixes that.

These issues also affect OS X, plus there are additional issues on OS X that I'll look into later.

@pstanczyk
Copy link
Contributor

Hey - I think this should all be fixed up by now. Could you try the cmake-fixes branch and let me know if all is working for you.

@ppearson
Copy link
Author

Linux debug seems to be fine with gcc 4.7.1 and 4.8.1 - I'll try and get release checked within the next few days - I'm going to need to change some infrastructure stuff to test that properly...

Quick question (I think this was asked in another issue, but I can't find it now): is the libtool stuff (.la file generation) still needed, as IlmBase appears to have (haven't checked if it works) pkgconfig stuff? It's not a problem, I'm just curious.

Thanks.

@pstanczyk
Copy link
Contributor

Thanks for that.

No, I don't think we would need the .la files with CMake.

Whilst exploring this a bit more on the linux platform, I noticed that adding the namespaces into the library name does make it difficult to build IlmImf against the IlmBase libs, but I think we can come back to that.

Linux debug seems to be fine with gcc 4.7.1 and 4.8.1 - I'll try and get release checked within the next few days - I'm going to need to change some infrastructure stuff to test that properly...

Quick question (I think this was asked in another issue, but I can't find it now): is the libtool stuff (.la file generation) still needed, as IlmBase appears to have (haven't checked if it works) pkgconfig stuff? It's not a problem, I'm just curious.

Thanks.


Reply to this email directly or view it on GitHubhttps://github.com//issues/61#issuecomment-26680035.

@ppearson
Copy link
Author

Okay, seems to work nicely in release too. Many thanks.

@ppearson
Copy link
Author

Actually, on Linux with CMake only, I don't think the custom command for generating the b44ExpLogTable.h is working:

I'll add this as a separate issue as it affects Linux and OS X: Issue 77.

@ehanway-ilm
Copy link
Contributor

Closing this out. Tested with 2.2: the original issues with the ImfNamespace.h and link libraries for IlmImf are addressed, and the auto generation of the tables is working on Linux.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug A bug in the source code Build A problem with building or installing the library.
Projects
None yet
Development

No branches or pull requests

3 participants