CMake build custom command for generating b44ExpLogTable exe fails on Linux and OS X about openexr HOT 21 CLOSED

Thanks for logging this. I'll take a look on a 10.6.8 system. Linux seems to be behaving itself well for the head of the develop branch.

from openexr.

OK - this should be fixed with: (on develop)
c3d440f

from openexr.

Cool, I'll give it a go - is develop up to date with all CMake-fixes changes now?

from openexr.

I'm afraid this is still broken on Linux for me with a pure CMake build:

No rule to make target ...../OPENEXR_LOCAL/b44ExpLogTable.h', needed byIlmImf/CMakeFiles/IlmImf.dir/ImfB44Compressor.cpp.o'. Stop.

from openexr.

Does Cmake allow you to inject shell commands? A little gcc -o, run, copy, and clean up goodness would be a straightforward way to avoid having to tease Cmake into doing something unnatural :)

from openexr.

This is really bizarre...

On Linux, with CMake 2.8.9, if I remove from OpenEXR/IlmImf/CMakeLists.txt:
the SET_SOURCE_FILES_PROPERTIES commands, then everything works as expected.

On OS X however, it seems to need them, but there are issues with the generated files for half on OS X...

I'm also suspicious about the makefiles / Makefile.am files that exist already in the repro... I had to remove a few of them from the source of IlmBase before stuff I'd changed in the CMake generated makefiles for IlmBase/Half worked correctly...

from openexr.

What issue did you run into? The file generated for half (the float conversion array) is pretty straightforward.

from openexr.

Hi,

Could you try pulling from develop again? I fixed a number of things with cmake. Notably, that the generation of the header files is now happening in the right working directory.

• Piotr

  ---

  From: Nick Porcino [[email protected]]
  Sent: 17 November 2013 11:48
  To: openexr/openexr
  Cc: Piotr Stanczyk
  Subject: Re: [openexr] CMake build custom command for generating b44ExpLogTable exe fails on Linux and OS X (#77)

What issue did you run into? The file generated for half (the float conversion array) is pretty straightforward.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/77#issuecomment-28661941.

from openexr.

Two questions, just to be sure. I just did a pull.

1 - which branch should I build?
2 - on master, the cmake readme is specific to windows (and probably old). What is the proper recipe to follow?

from openexr.

Hi Nick,

Go from develop, that is where the latest stable features are. Master is really just there for aligning with what is released.

Let me know

• Piotr

  ---

  From: Nick Porcino [[email protected]]
  Sent: 18 November 2013 08:31
  To: openexr/openexr
  Cc: Piotr Stanczyk
  Subject: Re: [openexr] CMake build custom command for generating b44ExpLogTable exe fails on Linux and OS X (#77)

Two questions, just to be sure. I just did a pull.

1 - which branch should I build?
2 - on master, the cmake readme is specific to windows (and probably old). What is the proper recipe to follow?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/77#issuecomment-28713261.

from openexr.

Nick,

One more thing, take a look at README.cmake.txt on the develop branch - that should outline the process for building on Linux.

• Piotr

  ---

  From: Nick Porcino [[email protected]]
  Sent: 18 November 2013 08:31
  To: openexr/openexr
  Cc: Piotr Stanczyk
  Subject: Re: [openexr] CMake build custom command for generating b44ExpLogTable exe fails on Linux and OS X (#77)

Two questions, just to be sure. I just did a pull.

1 - which branch should I build?
2 - on master, the cmake readme is specific to windows (and probably old). What is the proper recipe to follow?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/77#issuecomment-28713261.

from openexr.

I did a fresh pull of develop two days ago - I can't see that anything's changed since... It's saying everything's up to date...

I've managed to get things working locally by putting the SET_SOURCE_FILES_PROPERTIES() in IlmBase/Half/CMakeLists.txt and OpenEXR/IlmImf/CMakeLists.txt within:
IF(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")

ENDIF(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")

So that they only have effect on OS X, where they seem to be needed.

I really don't understand this though. On Linux, debug and release building dynamic .so objects, having those statements seems to cause issues. Without them, they get generated correctly...

I'll try and test on another Linux machine, as I'm suspicious about what's going on.

from openexr.

OK - maybe I missed something here.

The fixes I pushed recently were to make sure that the generation of the b44 header file happened and the correct linker commands were being issued.
Could you try with a new install directory?

Is there another problem that we need to look at?

• Piotr

  ---

  From: Peter Pearson [[email protected]]
  Sent: 18 November 2013 12:13
  To: openexr/openexr
  Cc: Piotr Stanczyk
  Subject: Re: [openexr] CMake build custom command for generating b44ExpLogTable exe fails on Linux and OS X (#77)

I did a fresh pull of develop two days ago - I can't see that anything's changed since... It's saying everything's up to date...

I've managed to get things working locally by putting the SET_SOURCE_FILES_PROPERTIES() in IlmBase/Half/CMakeLists.txt and OpenEXR/IlmImf/CMakeLists.txt within:
IF(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")

ENDIF(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")

So that they only have effect on OS X, where they seem to be needed.

I really don't understand this though. On Linux, debug and release building dynamic .so objects, having those statements seems to cause issues. Without them, they get generated correctly...

I'll try and test on another Linux machine, as I'm suspicious about what's going on.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/77#issuecomment-28733458.

from openexr.

Hi Piotr, a few problems. IlmBase built fine.

The recipe for OpenEXR is incorrect. Notice how it says . Also, is ambiguous; it wants the same install prefix that was used for IlmBase, as opposed to one of the directories created within that location.

-- OpenEXR --

initial bootstraping:
cmake -DILMBASE_PACKAGE_PREFIX= -DCMAKE_INSTALL_PREFIX=

The next problem, is that there is an assumption that the installed IlmBase files are in your search path, rather than assuming that they are in the location of the installed IlmBase files. I think it is not a good assumption that the installed files are in your search path, because you might have many versions of OpenEXR on your system. I do. :)

I can work around it temporarily, but I think that similar to mk at ILM, we should make sure that the build environment is logical during the build.

]make -j 3
Scanning dependencies of target b44ExpLogTable
[ 1%] Building CXX object IlmImf/CMakeFiles/b44ExpLogTable.dir/b44ExpLogTable.cpp.o
Linking CXX executable b44ExpLogTable
dyld: Library not loaded: libHalf.11.dylib
Referenced from: /tmp/openexrbuild/IlmImf/b44ExpLogTable
Reason: image not found
/bin/sh: line 1: 90901 Trace/BPT trap: 5 /tmp/openexrbuild/IlmImf/b44ExpLogTable > b44ExpLogTable.h
make[2]: *** [IlmImf/b44ExpLogTable] Error 133
make[1]: *** [IlmImf/CMakeFiles/b44ExpLogTable.dir/all] Error 2
make: *** [all] Error 2

from openexr.

Nick, I am not sure I follow here.

There is the need to set DYLD_LIBRARY_PATH to point to the location of the installed IlmBase libraries. Is that the issue you are describing here?

• Piotr

  ---

  From: Nick Porcino [[email protected]]
  Sent: 18 November 2013 18:27
  To: openexr/openexr
  Cc: Piotr Stanczyk
  Subject: Re: [openexr] CMake build custom command for generating b44ExpLogTable exe fails on Linux and OS X (#77)

Hi Piotr, a few problems. IlmBase built fine.

The recipe for OpenEXR is incorrect. Notice how it says . Also, is ambiguous; it wants the same install prefix that was used for IlmBase, as opposed to one of the directories created within that location.

-- OpenEXR --

initial bootstraping:
cmake -DILMBASE_PACKAGE_PREFIX= -DCMAKE_INSTALL_PREFIX=

The next problem, is that there is an assumption that the installed IlmBase files are in your search path, rather than assuming that they are in the location of the installed IlmBase files. I think it is not a good assumption that the installed files are in your search path, because you might have many versions of OpenEXR on your system. I do. :)

I can work around it temporarily, but I think that similar to mk at ILM, we should make sure that the build environment is logical during the build.

]make -j 3
Scanning dependencies of target b44ExpLogTable
[ 1%] Building CXX object IlmImf/CMakeFiles/b44ExpLogTable.dir/b44ExpLogTable.cpp.o
Linking CXX executable b44ExpLogTable
dyld: Library not loaded: libHalf.11.dylib
Referenced from: /tmp/openexrbuild/IlmImf/b44ExpLogTable
Reason: image not found
/bin/sh: line 1: 90901 Trace/BPT trap: 5 /tmp/openexrbuild/IlmImf/b44ExpLogTable > b44ExpLogTable.h
make[2]: *** [IlmImf/b44ExpLogTable] Error 133
make[1]: *** [IlmImf/CMakeFiles/b44ExpLogTable.dir/all] Error 2
make: *** [all] Error 2

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/77#issuecomment-28760153.

from openexr.

Yes, that's what I mean. What I was trying to say was that I think that if one follows the instructions in the read me, then OpenEXR should build. So I was proposing that the make system itself should set DYLD_LIBRARY_PATH temporarily for the duration of the build, so that the build can succeed without the necessity of the user having to set it for the build and then clear it. That's what mk does. A far less preferable solution would be that we insert instructions into the readme, informing the user that since dylibs created during the IlmBase build step are required to complete the OpenEXR build, then the user should temporarily set up that variable in the case that the IlmBase install directory is not in the dylib search path. That just seems like a bother to the user though, when it could be automated.

from openexr.

That would indeed be preferable.

Interestingly, for some reason, I don't need to set the equivalent LD_LIBRARY_PATH on Linux, despite building IlmBase and OpenEXR in different directories with different target directories...

from openexr.

It could be you have a previous build of the dso's somewhere in your path, or maybe from Maya or something like that?

from openexr.

Regarding the following: openexr/OpenEXR/IlmImf/CMakeLists.txt

Contents in Source with the following error:

IF(BUILD_SHARED_LIBS)
ADD_DEFINITIONS(-DILMIMF_EXPORTS)
ENDIF()

ADD_LIBRARY ( IlmImf ${LIB_TYPE}
${ILMIMF_SRCS}
)

TARGET_LINK_LIBRARIES ( IlmImf
Half
Iex-2_1
Imath-2_1
IlmThread-2_1
${PTHREAD_LIB} ${ZLIB_LIBRARIES}
)

ADD_DEPENDENCIES ( IlmImf b44ExpLogTable )

SET_SOURCE_FILES_PROPERTIES (
ImfB44Compressor.cpp
PROPERTIES
OBJECT_DEPENDS ${CMAKE_SOURCE_DIR}/b44ExpLogTable.h
)

SOLUTION:

IF(BUILD_SHARED_LIBS)
ADD_DEFINITIONS(-DILMIMF_EXPORTS)
ENDIF()

ADD_LIBRARY ( IlmImf ${LIB_TYPE}
${ILMIMF_SRCS}
)

TARGET_LINK_LIBRARIES ( IlmImf
Half
Iex-2_1
Imath-2_1
IlmThread-2_1
${PTHREAD_LIB} ${ZLIB_LIBRARIES}
)

ADD_DEPENDENCIES ( IlmImf b44ExpLogTable )

SET_SOURCE_FILES_PROPERTIES (
ImfB44Compressor.cpp
PROPERTIES
OBJECT_DEPENDS ${CMAKE_SOURCE_DIR}/IlmImf/b44ExpLogTable.h // Problem Line missing IlmImf pathway
)

NOTE: Your CMAKE_SOURCE_DIR/b44ExLogTable.h is searching one level up and finding no target. Including the CMAKE_SOURCE_DIR/IlmImf/b44ExLogTable.h builds clean

from openexr.

Problem: It produces the following:

excerpt:

-- Installing: /usr/local/include/OpenEXR/include/OpenEXR/ImfAcesFile.h
-- Installing: /usr/local/include/OpenEXR/include/OpenEXR/ImfMultiPartOutputFile.h
-- Installing: /usr/local/include/OpenEXR/include/OpenEXR/ImfGenericOutputFile.h
-- Installing: /usr/local/include/OpenEXR/include/OpenEXR/ImfMultiPartInputFile.h
-- Installing: /usr/local/include/OpenEXR/include/OpenEXR/ImfGenericInputFile.h

Install prefix wasn't set properly to /usr/local [// My fault]

from openexr.

I see PyIlmbase still doesn't have Cmake equivalents

from openexr.