search

AcademySoftwareFoundation / openexr

The OpenEXR project provides the specification and reference implementation of the EXR file format, the professional-grade image storage format of the motion picture industry.
http://www.openexr.com/
BSD 3-Clause "New" or "Revised" License
1.6k stars 606 forks source link

I have a githlab CI/CD docker build that is now failing with OpenEXR. #419

Closed JasonAlexander closed 4 years ago

JasonAlexander commented 5 years ago

My last good build was Thrusday (6/27). The docker file pulls the master branch: --2019-07-01 10:56:40-- https://github.com/openexr/openexr/archive/master.zip. Below are the errors:

[ 20%] Generating b44ExpLogTable.h
./dwaLookups: error while loading shared libraries: libHalf-2_3.so.24: cannot open shared object file: No such file or directory
make[2]: *** [OpenEXR/IlmImf/dwaLookups.h] Error 127
make[2]: *** Deleting file 'OpenEXR/IlmImf/dwaLookups.h'
make[2]: *** Waiting for unfinished jobs....
OpenEXR/IlmImf/CMakeFiles/IlmImf.dir/build.make:65: recipe for target 'OpenEXR/IlmImf/dwaLookups.h' failed
./b44ExpLogTable: error while loading shared libraries: libHalf-2_3.so.24: cannot open shared object file: No such file or directory
OpenEXR/IlmImf/CMakeFiles/IlmImf.dir/build.make:61: recipe for target 'OpenEXR/IlmImf/b44ExpLogTable.h' failed
make[2]: *** [OpenEXR/IlmImf/b44ExpLogTable.h] Error 127
make[2]: *** Deleting file 'OpenEXR/IlmImf/b44ExpLogTable.h'
CMakeFiles/Makefile2:601: recipe for target 'OpenEXR/IlmImf/CMakeFiles/IlmImf.dir/all' failed
make[1]: *** [OpenEXR/IlmImf/CMakeFiles/IlmImf.dir/all] Error 2
Makefile:151: recipe for target 'all' failed
make: *** [all] Error 2
The command '/bin/sh -c mkdir -p /openexr &&     mkdir -p /openexr/build &&

Is there a change that I'm missing?

cary-ilm commented 5 years ago

I'm not aware of any recent change that would trigger this. Is it possible that the build of IlmBase has failed, or been skipped? That would lead to the missing libHalf-2.3.so.

Are you building completely from scratch? The b44ExpLogTable.h file is auto-generated by the build process, that's what's failing, and it's a common source of build problems.

Google-Autofuzz commented 4 years ago

We can reproduce this too:

# […]
RUN git clone https://github.com/openexr/openexr.git

ENV LD_LIBRARY_PATH="/lib/x86_64-linux-gnu"
WORKDIR /fuzzing/openexr/IlmBase
RUN ./bootstrap
RUN ./configure
RUN make -j`nproc`
RUN make install
RUN ldconfig
WORKDIR /fuzzing/openexr/OpenEXR
RUN ./bootstrap
RUN ./configure
RUN make -j`nproc`
RUN make install
RUN ldconfig
# […]

resulting in the following:

libtool: link: /usr/bin/clang […] -o b44ExpLogTable b44ExpLogTable.o  -L/usr/local/lib -lImath2_3 -lHalf2_3 -lIex2_3 -lIexMath2_3 -lIlmThread2_3
/usr/bin/ld: cannot find -lImath2_3
/usr/bin/ld: cannot find -lHalf2_3
/usr/bin/ld: cannot find -lIex2_3
/usr/bin/ld: cannot find -lIexMath2_3
/usr/bin/ld: cannot find -lIlmThread2_3
clang: error: linker command failed with exit code 1 (use -v to see invocation)

It would be great to have a CI for OpenEXR, eg. via Travis-ci.

cary-ilm commented 4 years ago

We're aware of this problem and have a fix that should be merged into the master branch shortly. We're also in the final stages of setting up a CI for OpenEXR through the ASWF, using Azure Pipelines, more to follow soon.

cary-ilm commented 4 years ago

Looks like those changes have now been merged into master, could you try again? This was a wholesale rewrite of the CMakeSet thanks to @kdt3rd, so things should be much better now, if still possibly a bit unripe.

Google-Autofuzz commented 4 years ago

It seems that we still have the same issue :/

meshula commented 4 years ago

In the previous version of the cmake build system on Windows, we forced an extra static build of Half to link against b44ExpLogTable, because pathing for dlls under automation is vexing. Maybe the easiest way forward is to do the same on Linux?

kdt3rd commented 4 years ago

The issue the Google-Autofuzz script is reporting looks like an issue with the configure / autoconf based on their CI script (bootstrap, configure, etc), not with cmake which based on the snippet of output is what the original report is about.

The new cmake infrastructure is handling the rpath in the manner I would expect to happen as far as I can test (binaries and libraries while in the build tree all have a local rpath set, once you install, it depends on whether you set CMAKE_INSTALL_RPATH, are installing into a system location or a custom one.

However the legacy autoconf system hasn't been changed to fix anything with this, so if it's an issue, it would still be an issue.

meshula commented 4 years ago

Ah, makes sense. I didn't spot the automake angle.

Google-Autofuzz commented 4 years ago

Switching to cmake solved the issue, it would be nice to have the build-related documentation updated accordingly :)

kdt3rd commented 4 years ago

An update to the install documentation is pending. However, there is currently a disconnect in how cmake and autoconf generate library names causing the issues you were seeing with the autoconf path (which cmake avoids by directly carrying the names). We are researching and hope to have a fix soon.

cary-ilm commented 4 years ago

We believe both cmake and autoconf are working properly on master now, can you try this again?

The installation documentation should be updated as well, and the Azure CI dashboard is here: https://dev.azure.com/openexr/OpenEXR

cary-ilm commented 4 years ago

This seems to have been resolved. Closing the issue for now, feel free to re-open or file a new issue if you need further help.