cessen / openexr-rs

This repository has been moved to https://github.com/vfx-rs/openexr-rs
MIT License
23 stars 10 forks source link

PKG_CONFIG_PATH issue on Debian #43

Open elite-sheep opened 4 years ago

elite-sheep commented 4 years ago

I was trying to build OpenEXR v2.3.0 on Debian 10,

If we build OpenEXR(Version <= 2.5.2) from source, then it will name the pkg config file as "Ilmbase.pc" instead of "OpenEXR.pc"
Thus when we build the project, it will run into the following issue:

--- stderr
  thread 'main' panicked at 'couldn't find OpenEXR: environment variable OPENEXR_DIR is unset and pkg-config failed: `"pkg-config" "--libs" "--cflags" "OpenEXR" "OpenEXR >= 2.0.0"` did not exit successfully: exit code: 1
  --- stderr
  Package OpenEXR was not found in the pkg-config search path.
  Perhaps you should add the directory containing `OpenEXR.pc'
  to the PKG_CONFIG_PATH environment variable
  No package 'OpenEXR' found
  Package OpenEXR was not found in the pkg-config search path.
  Perhaps you should add the directory containing `OpenEXR.pc'
  to the PKG_CONFIG_PATH environment variable

The changelog of OpenEXR is here: https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v2.5.2

Can we make some changes to mitigate this issue?

cessen commented 4 years ago

Hi Aaron! Thanks for the report.

This definitely needs to be addressed. I don't have the bandwidth to tackle this myself right now, but if you or anyone else can take a crack at it, I'll be happy to merge PRs. I'm not totally sure what the best way to address this is, however.

elite-sheep commented 4 years ago

Ok, I will look at this issue and maybe provide a fix soon.

cessen commented 3 years ago

As I discovered in issue #46, it appears that the changes made to fix this actually break other things.

Looking at the git history of the OpenEXR project, it also appears that they have always used OpenEXR.pc, not Ilmbase.pc, going back at least as far as version 2.0. Moreover, in retrospect, we've always been building openexr-rs using OpenEXR.pc, including when manually building OpenEXR itself from source, at least since version 2.2 of OpenEXR, and it's worked fine.

So I'm really not sure what's going on that's causing the build issues for @Aaron19960821.

For now, I'm going to effectively revert the fix, since it seems to break things everywhere except @Aaron19960821's situation. I do, of course, still want to fix things for Aaron as well, but more investigation is needed.

elite-sheep commented 3 years ago

@cessen I found that OpenEXR is developing in both 2.4.x and 2.5.x. They change the PKG_CONFIG_PATH in both versions. In your case, you tend to initialize your environment with libopenexr24-dev and they also change the idea. ChangeLog: 2.4.x: https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v2.4.2 2.5.x: https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v2.5.2

I am not sure how to fix this issue. A trivial solution is that we mention it in README.md to tell the users to check this if they meet related errors?

cessen commented 3 years ago

Yeah, I saw that they mentioned the same change in v2.4.2 as well. And the first thing I actually did was take a crack at making a fix that accounted for that as well. But in the process, I noticed some things, then checked some things, and discovered:

  1. We've always had pkg-config look for OpenEXR.pc, never Ilmbase.pc (well, we also check for Ilmbase.pc, but only for the IlmBase library itself). I checked back quite far in our commit history to verify, including releases of this crate that significantly predate even OpenEXR 2.4.0. So it seems like OpenEXR.pc has always worked.
  2. Checking the actual OpenEXR repository, and their git history going all the way back to v2.0.0, it appears that they have always provided OpenEXR.pc for OpenEXR itself. See for example this file in their 2.0 release tag.

So it seems like what they're referring to in the release notes for v2.5.2 and v2.4.2 isn't related to the OpenEXR.pc/Ilmbase.pc files, and that OpenEXR.pc has always been the correct file to look for, at least since v2.0.0.

I could have missed something, of course. But at the very least, the situation does not seem obvious, and I think more investigation is warranted to figure out what's actually going on.