Workaround for freetype build error with external libz and spack-built pkg-config #496
Conversation
climbfuji
force-pushed
the
bugfix/extzlib_pkgconfig_freetype
branch
from
ec0f142 to
cd576f2
Compare
…os/builtin/packages/freetype/package.py: find zlib.pc and add directory to PKG_CONFIG_PATH
climbfuji
force-pushed
the
bugfix/extzlib_pkgconfig_freetype
branch
from
cd576f2 to
ecc987c
Compare
climbfuji
changed the title
climbfuji
requested review from
AlexanderRichert-NOAA,
stiggy87 and
RatkoVasic-NOAA
|
If it's okay I'd prefer to fix the style check, depending how much trouble you think it would be. As far as the change itself, I don't mind it while a permanent solution is found. Would it work though to add '/usr/lib64/pkg-config' or whatever to PKG_CONFIG_PATH in compilers.yaml? I agree that a general solution should be found that lets a Spack-installed pkg-config find external libraries... |
I can try to pull in spack#48352 in a separate PR and merge that first. Hopefully, not too many conflicts (since we are already a bit behind spack develop).
I didn't want to do that, because I don't want all |
|
Isn't that what this is doing though? If it's an external zlib, then wouldn't |
Correct, for the purpose of finding dependencies of The update of the license file headers from spack develop is unfortunately more complicated. I think an alternative would be to temporarily modify the license header check to look for 2024 and leave a note in there. There is going to be a merge conflict next time we pull in spack develop (which removes the year range entirely) |
…e/spack/qa/run-style-tests
|
@AlexanderRichert-NOAA For now, I commented out the license header check in the style CI tests. I added a fat note there that we need to reactivate it, and I will also create an issue for it. |
|
@AlexanderRichert-NOAA I can confirm that the spack build picks up the correct dependencies. |
This PR updates all NRL sites to use the OS libz.so instead of the spack-built zlib-ng version. This is to address numerous problems, especially on Cray, where after loading spack-stack environments, basic tools like less and more sophisticated tools like ddt would throw many warnings or even stop working. For consistency, we do this on all NRL systems, regardless of being a Cray or not. Included are also: Additional, minor updates to the NRL site configs, most notably the update of cray-mpich on Narwhal to the latest version 8.1.26. In template neptune-dev, exclude neptune-python-env with Intel Classic compilers. Yes, the time has come to say goodbye. The new versions of Python packages py-numpy and py-scipy don't build with these compilers, and it's not worth fixing those builds given that these compilers are deprecated and the replacement (%oneapi with icx, icpx, ifort) works fine. Add same conflict for LLVM (clang) compilers. Add AMD AOCC compiler to tier2 site config Bounty. Turn off gssapi variant for package libtircp because of a build error with latest OneAPI compilers (libtircp only needed by hdf@4, and the variant isn't needed) This PR requires a bugfix/workaround in spack for package freetype, see JCSDA/spack#496
Description
This is a specific workaround for more general problem that I logged as an issue the spack upstream repo: spack#48293
In order to build
freetypewith a spack-builtpkg-configand an externallibz, this workaround tells spack where to look forzlib.pcby finding the file in the prefix of the external zlib, and then adding it toPKG_CONFIG_PATH.We need this solution until the general problem has been addressed (or we can push this solution upstream if the spack develop are ok with it).
Testing
See JCSDA/spack-stack#1439.
Temporarily deactivated license header check because it's 2025 now and our spack code still looks for 2024. The next update from spack develop will resolve the problem, and an issue in our spack fork will remind us to reenable the license header check.