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

OpenEXR static build not creating libIlmImf.a #1770

Open
SteveWDI opened this issue Jun 21, 2024 · 5 comments
Open

OpenEXR static build not creating libIlmImf.a #1770

SteveWDI opened this issue Jun 21, 2024 · 5 comments

Comments

@SteveWDI
Copy link

SteveWDI commented Jun 21, 2024

Setting BUILD_SHARED_LIBS to OFF seems to create a static library for ilmThread, but not
for IlmImf.

Environment:
	Docker container based on Centos:7
	updated
	'devtoolset-11' installed
	'scl enable devtoolset-11 bash' executed
	OpenSSL 1.1.1l installed  built/installed
	CMake  3.29.5 built/installed
	Freetype 2.11.0 built/installed

Steps to reproduce:
	wget https://github.com/AcademySoftwareFoundation/openexr/releases/download/v3.2.4/openexr-v3.2.4.tar.gz
	mkdir openexr-v3.2.4
	tar zxvf openexr-v3.2.4.tar.gz -C /openexr-v3.2.4
	rm openexr-v3.2.4.tar.gz
	cd /openexr-v3.2.4
	cmake -DCMAKE_CXX_STANDARD=17 -DBUILD_SHARED_LIBS=0 .
	make -j$(nproc)
	make install

If you then execute:
	find / -name "libIlm*" 

Returns:
	/usr/lib64/libIlmImf.so
	/usr/lib64/libIlmThread.so.6
	/usr/lib64/libIlmThread.so.6.0.0
	/usr/lib64/libIlmImf.so.7
	/usr/lib64/libIlmImf.so.7.0.0
	/usr/local/lib64/libIlmThread-3_2.a
	/usr/local/lib64/libIlmThread-3_2.so.31.3.2.4
	/usr/local/lib64/libIlmThread-3_2.so.31
	/usr/local/lib64/libIlmThread-3_2.so
	/usr/local/lib64/libIlmThread.so
	/src/lib/IlmThread/libIlmThread-3_2.a

Expected behavior:
A libIlmImf.a library should be created.

I.e., it creates libIlmThread-3_2.a, but not an ILMImf equivalent.

@cary-ilm
Copy link
Member

The libraries in /usr/lib/* appear to be from an older installation. Those should not be generated by your cmake invocation of v3.2.4. Are you picking those up from a base image somewhere?

OpenEXR v3.2.4 does not build any libraries with Imf in the name, that term was retired in the v3.0 release.

@SteveWDI
Copy link
Author

SteveWDI commented Jun 21, 2024

The desire to reference IlmImf comes from this error when building an app using OIIO:

/opt/rh/devtoolset-11/root/usr/libexec/gcc/x86_64-redhat-linux/11/ld: /OpenImageIO-2.5.12.0/dist/lib64/libOpenImageIO.a(imagebufalgo_draw.cpp.o): in function std::_Function_handler<void (OpenImageIO_v2_5::ROI), OpenImageIO_v2_5::noise_uniform_<Imath_3_1::half>(OpenImageIO_v2_5::ImageBuf&, float, float, bool, int, OpenImageIO_v2_5::ROI, int)::{lambda(OpenImageIO_v2_5::ROI)#1}>::_M_invoke(std::_Any_data const&, OpenImageIO_v2_5::ROI&&)': imagebufalgo_draw.cpp:(.text+0xeb4f): undefined reference to imath_half_to_float_table'

I'm very confused because I thought the table was included in Imath, but it looks like Imath is no longer a part of OpenEXR...?
Nor does it seem to be included with OIIO.

@lgritz
Copy link
Contributor

lgritz commented Jun 21, 2024

The project split Imath (now producing libImath) into a separate project repo at version 3.0, and at that time, also the main OpenEXR library changed to be called libOpenEXR, not libIlmImf.

On Unix-like systems, dynamic libraries understand how to link their own dependencies. Static libraries do not. If you're linking static libOpenImageIO.a, and not using cmake and consuming OIIO's exported cmake config files, you'll need to -lStuff yourself to include the dependency libraries you need. In this case, it's Imath.

@SteveWDI
Copy link
Author

SteveWDI commented Jun 21, 2024

Understood. Thanks, @lgritz, for your helpful response. I was confused by this line from the OIIO dependency definition:

- OpenEXR/Imath >= 3.1 (tested through 3.2 and main)

I thought it meant that OpenEXR and Imath were both contained together when in fact they are not and it's now necessary to download and build them separately. Imho, there should be two separate lines in the dependency list for OIIO, not one.

@lgritz
Copy link
Contributor

lgritz commented Jun 21, 2024

It's only very recently in master (not yet in any official supported release) that we were 3.1+ only. For a very long time, we accepted either 2.x or 3.x. They were the same package in 2.x. So "OpenEXR/Imath" was meant indicate "either both package, if new, or the combined thing, if old."

Sorry, I will clarify the docs. I'm sure there are a few places where the wording is muddied because it used to describe a different situation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants