Open Dryvnt opened 1 month ago
My dependence on
gdal.pc
is very transient for me, and I've only ever built GDAL viavcpkg
Please use the GDAL CMake config file. The gdal.pc has never been thought for MSVC.
Please use the GDAL CMake config file.
Changing my build process to be based on CMake is unfortunately not a feasible option for me at this time, not counting what vcpkg
does as part of preparing my dependencies.
I am building a Rust project with several C dependencies that I must manually build. Rust-call-C binding libraries don't always agree on how you point them to built libraries and headers, but thankfully all the ones I need fall back to pkg-config
, which works great for my case - except for GDAL on Windows, where I hit this issue.
The gdal.pc has never been thought for MSVC.
I assumed so, given the language used in #5351 and how the broken format has persisted since then.
To be clear, I'm not hard blocked. While annoying to do, there are workarounds for my use case. I primarily figured that if no one made note of this, it would never get better
I assumed so, given the language used in #5351
ah, my bad. Didn't know that pkg-config could be used with MSVC at all! CC @dg0yt so he's aware of that ticket
I can look at in a few days. MSVC-syntax pkg-config was used to build GDAL with nmake in vcpkg, and I tried to keep it working with CMake. But probably it is no longer in scope of any CI coverage.
As a mitigation, any simple pc file error can be handled with an automated pc file fixup if there is a consistent substitution pattern.
The same function generates gdal.pc
and gdal-config
. The first has --msvc-syntax
to change the output, the second hasn't.
gdal-config
actually used with MSVC?gdal-config
produce wellformed-output?And of course the config doesn't carry the debug postfix.
What is the bug?
gdal.pc
is generated during CMake for Windows builds. Per https://github.com/OSGeo/gdal/pull/5351, it seems that this file is provided just in case it can be useful to Windows users. This is nice, and is indeed very helpful to me in theory, but unfortunately the file is malformed and unusable in the current state without applying a manual fix every build.Specifically, the flags provided to the
Libs:
section are not digestible bypkg-config
. It expects Linux-style flags, not MSVC-style ones, even when given the--msvc-syntax
flag. See the man pages for more details.Expected:
Observed:
Specifically, note
/libpath:IBPATH
and nogdal.lib
.For reference, this is a faulty
gdal.pc
taken from a recent run action:For the above example, these are the changes necessary to make
pkg-config
provide the correct flags for MSVC:Steps to reproduce the issue
Github Build Logs
In a
Build and test with CMake
workflow, inside thebuild-windows-conda
orbuild-windows-minimum
jobs, look at theShow gdal.pc
step and see that an incorrect"-LIBPATH:C:/Program Files/gdal" gdal
is passed instead of a correct"-LC:/Program Files/gdal" -lgdal
.Here is a link to a recent one.
Manual reproduction with vcpkg
My dependence on
gdal.pc
is very transient for me, and I've only ever built GDAL viavcpkg
. In case it's helpful, here's how to reproduce using that:Manually fix
.\installed\x64-windows\lib\pkgconfig\gdal.pc
: (Note that vcpkg has modifiedgdal.pc
post-build to un-hardcode the prefix. This is not the cause of the issue)Confirm manual fix worked:
Versions and provenance
For manual reproduction: Windows 11. Tested on both GDAL 3.6.2 and 3.9.2. Download and built through
vcpkg
, git ref4e08971f3ddc13018ca858a692efe92d3b6b9fce
.Additional context
No response