symbol not found: __ZTINIlmThread_3_14TaskE on Macos 11.7.7 #24
Comments
EmberLightVFX
changed the title
|
I suppose it is missing a -lm link. I do not understand why though... I suppose that is a dependency of OpenEXR or Imath and for some reason it was dinamically linked. |
|
Perhaps you have not installed pthreads or mthreads? |
|
I haven't installed pthreads or mthreads. Would it be some kind of c package? |
|
I found this: I would say pthreads should be somewhere. The problem is that I do not have a MacOS to dive into this problem. Maybe I will enable the tests on MacOS autobuilds too, but I think that would not help at all |
|
Yeah I'm using Big Sur so it might be something to do with that |
No idea. It is what we are trying to figure out here.
Nope, they are just having similar issues, so we might try to learn from them
You can check how is the wheel built on MacOS here (actually for all platforms): The idea is:
|
|
I am having the same issue under Ubuntu (18.04). Under Windows, everything is working as expected. Strangely, |
|
With Ubuntu I can work! can you @TobiasNoell please check your Python version and download the appropriate wheel from here? e.g. if you use Python 3.8 please download the wheel named OpenEXR-1.3.9-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl Then uncompress it and go into the folder, then type:
(The name of the file would change depending on the specific wheel) and paste here the result |
|
Meanwhile I am probably disabling threading on OpenEXR |
|
Apparently OpenEXR won't compile with the option OPENEXR_ENABLE_THREADING=OFF, neither on windows nor on MacOS |
|
I submitted an issue |
|
Thanks for the step-by-step instruction. Was really helpful :) The output of what you requested is: |
|
It should be working! Look:
Weiiird... I need to give this a second thought... |
|
I tried to do some research myself but the only thing I came across was this: AcademySoftwareFoundation/openexr#1449 but that's for macos <= 10.8 and not 10.9 that Github Actions seeems to compile with. The change I did to the workflow is: #- name: download OpenEXR source code
# uses: suisei-cn/[email protected]
# with:
# url: https://github.com/AcademySoftwareFoundation/openexr/archive/refs/tags/v3.1.8.tar.gz
# target: ${{github.workspace}}/
#
#- name: Extract OpenEXR
# run: |
# tar -xvzf v3.1.8.tar.gz -C ${{github.workspace}}/
# mv openexr-3.1.8 openexr
# rm v3.1.8.tar.gz
- name: Create openexr directory
run: mkdir ${{github.workspace}}/openexr
- name: Download OpenEXR repository
run: git clone https://github.com/AcademySoftwareFoundation/openexr.git ${{github.workspace}}/openexr |
|
ASF seems to fix the problem in this PR: AcademySoftwareFoundation/openexr#1462 Bonus question: What does the pthreads actually do? |
|
Cool! Just to understand, this is fixing that OpenEXR can be compiled without threading? And this would then most likely remove the linker error? The downside would probably be that the performance would be decreased? |
|
It should fix so it can be compiled without threading. They have fixed some importing issue so maybe compiling with threading will fix the linker error... No idea but might be worth testing |
|
This week I am on a congress, but I will try to tackle this ASAP |
|
I had the same runtime link error during OpenEXR import in Python after building a Docker container that uses pyexr which depends on Python package openexr and was picking up openexr 1.3.9. I worked around it by installing Python package openexr 1.3.8: Diagnosis Confusingly, my local system is importing fine using the same version of the openexr Python package (1.3.9) but the library file inside has a different MD5 checksum. It looks like the 1.3.9 wheels have been updated about a month ago, well after the original release of 1.3.9 last year. The Docker build is picking up the new version with the issue, while my local system still has the older version. The updated versions seem to have broken the linking with the ILM libraries, specifically with ImThread. Inside container with broken Python openexr package (tried with both Import fails with: Inside my local Linux (Windows 11 WSL2 Ubuntu 22.04): Import succeeds. I have I saw in some other issue comments here that @sanguinariojoe has released new builds with static linking of the OpenEXR libraries. Is it possible that this change has somehow broken the library linkages on at least on some systems? |
|
I have two different builds of a Docker image, each with OpenEXR 1.3.9 installed, but clearly a different build. It seems that it was rev'd without a version change. Working build, built May 20 2023 -- no missing symbol: And the broken image, built today, missing symbol: |
|
Ok guys! I am integrating into OpenEXR. See #11 and AcademySoftwareFoundation/openexr#1487. On that PR the Python wheels are fixed and working on all platforms |
|
openexr==1.3.8 work with Google Colab |
|
I'm trying to see if I can use the latest openexr in Blender's python. I'm using docker images as test environments. If I try to install with pip: To try to circumvent this I have tried using a docker image to run: But I get an error: Ultimately I'm trying to install this for Blender which has its own python executable and environment in a subfolder, plus it has its own c++ openEXR, but I don't specifically know how I could bind to those via python. |
|
@Steinthor Unfortunately I think the PyPI binary packages for 1.3.9 are broken. I recommend trying the work around in #24 (comment): |
|
Guys, all these issues are fixed on the OpenEXR upstream repository, where
the python wrapper is becoming integrated.
They are preparing a release this month. Afterwards I will provide them
with the pipy repo access (so they can start uploading the wheels there)
and close this repo.
…On Sat, 19 Aug 2023, 05:55 Matthew Arnison, ***@***.***> wrote:
@Steinthor <https://github.com/Steinthor> Unfortunately I think the PyPI
binary packages for 1.3.9 are broken. I recommend trying the work around in #24
(comment)
<#24 (comment)>
:
$ pip3 install OpenEXR==1.3.8
—
Reply to this email directly, view it on GitHub
<#24 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMXKKEQPBLJKM6JBFDSI33XWA2LJANCNFSM6AAAAAAZFC4PJE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@yellowtailfan Thanks for the suggestion, but I just got more errors:
|
|
@sanguinariojoe That's great news! @Steinthor Sorry that didn't work, I'm not sure what else to suggest. |
|
I was about to file a new issue, but I see this one went through the same process I have been going through. @Steinthor: One way to resolve it: clone this repo, edit setup.py, and remove those two libs from the line: Then run |
|
Or just forget about this repo and use the upstream. They already
integrated this and I will close it soon
…On Wed, 23 Aug 2023, 20:52 mentics, ***@***.***> wrote:
I was about to file a new issue, but I see this one went through the same
process I have been going through. @Steinthor
<https://github.com/Steinthor> for the cannot find -lHalf and -lIlmImf,
that is because OpenEXR used to use those libraries, but they have changed
according to this comment on the openexr project
<AcademySoftwareFoundation/openexr#1231 (comment)>
about that same error.
One way to resolve it: clone this repo, edit setup.py, and remove those to
libs from the line:
libraries = ["Iex", "Half", "Imath", "IlmImf", "z"]
# change the above line to:
libraries = ["Iex", "Imath", "z"]
Then run python setup.py bdist_wheel and it will build a wheel file in
the dist directory. Then you can run pip install {path to wheel file}
where you need it. You probably need the header files for OpenEXR at least
and maybe some other dependencies, but I'm not sure. When I got to this
point, it just worked for me.
—
Reply to this email directly, view it on GitHub
<#24 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMXKKFHJ4VTDR5IVM7ZHKDXWZGN5ANCNFSM6AAAAAAZFC4PJE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Thanks! I see it here in the openexr repository. It's not in a release yet, but it appears it will be in 3.2. For anyone else finding this in the next short time before it is formally included (openexr website still says it doesn't have python bindings and links to the other python bindings repo from many years ago), you can get it by: If you clone the main branch of the openexr repo and build that, you'll need to add a switch during cmake config to build the python wrapper: |
I'm trying to run a python script running pip-openexr 1.3.9.
On windows there are no problems but on mac I'm getting this error from the import:
ImportError: dlopen([...].env/lib/python3.9/site-packages/OpenEXR.cpython-39-darwin.so, 2): Symbol not found: __ZTINIlmThread_3_14TaskE
Expected in: flat enamespace
I'm runnin macos 11.7.7 and python 3.9.13
Any idea why this is happening? A bad wheel?
The text was updated successfully, but these errors were encountered: