|
Bugzilla – Full Text Bug Listing |
| Summary: | [Build 20230519] gdal failed to rebuild with zstd cmake files (identified after retried build for poppler) | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Dominique Leuenberger <dimstar> |
| Component: | Other | Assignee: | Bernhard Wiedemann <bwiedemann> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | bruno, bwiedemann, code, jengelh, stefan.bruens |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| URL: | https://openqa.opensuse.org/tests/3303025/modules/gdal/steps/3 | ||
| Whiteboard: | |||
| Found By: | openQA | Services Priority: | |
| Business Priority: | Blocker: | Yes | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Dominique Leuenberger
2023-05-20 05:50:15 UTC
This seems to have failed with the latest zstd 'fix' about shipping cmake files osc rq show -d 1085997 +- Add cmake files manually because we do not want to add + cmake to the bootstrap ring0 gdal fails the build with [ 81s] CMake Error at /usr/lib64/cmake/zstd/zstdTargets.cmake:96 (message): [ 81s] The imported target "zstd::libzstd_static" references the file [ 81s] [ 81s] "/usr/lib64/libzstd.a" [ 81s] [ 81s] but this file does not exist. Possible reasons include: [ 81s] [ 81s] * The file was deleted, renamed, or moved to another location. [ 81s] [ 81s] * An install or uninstall procedure did not complete successfully. [ 81s] [ 81s] * The installation package was faulty and contained [ 81s] [ 81s] "/usr/lib64/cmake/zstd/zstdTargets.cmake" [ 81s] [ 81s] but not all the files it references. [ 81s] [ 81s] Call Stack (most recent call first): [ 81s] /usr/lib64/cmake/zstd/zstdConfig.cmake:1 (include) [ 81s] cmake/helpers/CheckDependentLibraries.cmake:137 (find_package) [ 81s] cmake/helpers/CheckDependentLibraries.cmake:376 (gdal_check_package) [ 81s] gdal.cmake:264 (include) [ 81s] CMakeLists.txt:224 (include) (In reply to Dominique Leuenberger from comment #1) > This seems to have failed with the latest zstd 'fix' about shipping cmake > files > > osc rq show -d 1085997 > +- Add cmake files manually because we do not want to add > + cmake to the bootstrap ring0 > > > gdal fails the build with > [ 81s] CMake Error at /usr/lib64/cmake/zstd/zstdTargets.cmake:96 (message): > [ 81s] The imported target "zstd::libzstd_static" references the file > [ 81s] > [ 81s] "/usr/lib64/libzstd.a" > [ 81s] > [ 81s] but this file does not exist. Possible reasons include: > [ 81s] > [ 81s] * The file was deleted, renamed, or moved to another location. > [ 81s] > [ 81s] * An install or uninstall procedure did not complete successfully. > [ 81s] > [ 81s] * The installation package was faulty and contained > [ 81s] > [ 81s] "/usr/lib64/cmake/zstd/zstdTargets.cmake" > [ 81s] > [ 81s] but not all the files it references. > [ 81s] > [ 81s] Call Stack (most recent call first): > [ 81s] /usr/lib64/cmake/zstd/zstdConfig.cmake:1 (include) > [ 81s] cmake/helpers/CheckDependentLibraries.cmake:137 (find_package) > [ 81s] cmake/helpers/CheckDependentLibraries.cmake:376 > (gdal_check_package) > [ 81s] gdal.cmake:264 (include) > [ 81s] CMakeLists.txt:224 (include) I guess shipping cmake file that is refering to static library is not the best idea: from zstdTargets-none.cmake # Import target "zstd::libzstd_static" for configuration "None" set_property(TARGET zstd::libzstd_static APPEND PROPERTY IMPORTED_CONFIGURATIONS NONE) set_target_properties(zstd::libzstd_static PROPERTIES IMPORTED_LINK_INTERFACE_LANGUAGES_NONE "C" IMPORTED_LOCATION_NONE "${_IMPORT_PREFIX}/lib64/libzstd.a" ) I dont think gdal is at fault here The error is due to both targets (zstd::libzstd_static and zstd::libzstd_shared) being part of the same export set. CMake supports multiple export sets (e.g. for shared and static libraries, non-mandatory auxiliary build tools, ...), but unfortunately many projects don't get this right - some even export tools and samples, i.e. forcing installation of the all built packages from the devel project. If gdal worked with previous zstd cmake files, doesn't matter if gdal got it wrong and it backfires now - introduce cmake to Hyrum's law :) On Holidays for a few weeks, with limited access, can't do a lot. But maybe it is worth testing 3.6.4 upstream author's Even being quite responsive on newer lib and tools troubleshooting. Maybe the fix is already there. > If gdal worked with previous zstd cmake files, doesn't matter if gdal got it > wrong and it backfires now - introduce cmake to Hyrum's law :) Actually gdal gets it right with their own cmake files but the introduction of zstd's cmake files in sr#1085997 overrides gdal's own cmake finder. Upstream even knows about the problems with ztd's cmake files and works around it for conda: https://github.com/OSGeo/gdal/pull/5437 The quickfix would be to just have libzstd-devel-static in the build requirements of gdal so that the configuration stage of cmake does not fail even if there is no static linking later on. But I am very hesitant to submit that change. (In reply to Benjamin Greiner from comment #7) > https://build.opensuse.org/request/show/1089288 accepted -> fixed |