OSGeo / gdal

GDAL is an open source MIT licensed translator library for raster and vector geospatial data formats.
https://gdal.org
Other
4.87k stars 2.54k forks source link

CMake: gdal.pc is malformed for Windows/MSVC builds #10727

Open Dryvnt opened 1 month ago

Dryvnt commented 1 month ago

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 by pkg-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:

> pkgconf.exe --libs --msvc-syntax gdal
/libpath:D:/vcpkg/installed/x64-windows/lib gdal.lib

Observed:

> pkgconf.exe --libs --msvc-syntax gdal
/libpath:IBPATH:D:/vcpkg/installed/x64-windows/lib

Specifically, note /libpath:IBPATH and no gdal.lib.

For reference, this is a faulty gdal.pc taken from a recent run action:

CONFIG_VERSION=3.10.0dev
CONFIG_INST_PREFIX=C:/Program Files/gdal
CONFIG_INST_LIBS="-LIBPATH:C:/Program Files/gdal/lib" gdal
CONFIG_INST_CFLAGS="-IC:/Program Files/gdal/include"
CONFIG_INST_DATA="C:/Program Files/gdal/share/gdal"
prefix=${CONFIG_INST_PREFIX}
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${exec_prefix}/include
datadir=${CONFIG_INST_DATA}

Name: libgdal
Description: Geospatial Data Abstraction Library
Version: ${CONFIG_VERSION}
Libs: ${CONFIG_INST_LIBS}
Libs.private: wbemuuid psapi C:/Users/runneradmin/miniconda3/envs/gdalenv/Library/lib/proj.lib
Cflags: ${CONFIG_INST_CFLAGS}

For the above example, these are the changes necessary to make pkg-config provide the correct flags for MSVC:

CONFIG_INST_PREFIX=C:/Program Files/gdal
- CONFIG_INST_LIBS="-LIBPATH:C:/Program Files/gdal/lib" gdal
+ CONFIG_INST_LIBS="-L:C:/Program Files/gdal/lib" -lgdal
CONFIG_INST_CFLAGS="-IC:/Program Files/gdal/include"

Steps to reproduce the issue

Github Build Logs

In a Build and test with CMake workflow, inside the build-windows-conda or build-windows-minimum jobs, look at the Show 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 via vcpkg. In case it's helpful, here's how to reproduce using that:

# Powershell syntax
> cd $env:VCPKG_ROOT
> vcpkg install gdal
> $env:PKG_CONFIG_PATH="$(pwd)\installed\x64-windows\lib\pkgconfig"
> .\installed\x64-windows\tools\pkgconf\pkgconf.exe --libs --msvc-syntax gdal
/libpath:IBPATH:D:/vcpkg/installed/x64-windows/lib

Manually fix .\installed\x64-windows\lib\pkgconfig\gdal.pc: (Note that vcpkg has modified gdal.pc post-build to un-hardcode the prefix. This is not the cause of the issue)

- CONFIG_INST_LIBS=-LIBPATH:${prefix}/lib gdal
+ CONFIG_INST_LIBS=-L${prefix}/lib -lgdal

Confirm manual fix worked:

> .\installed\x64-windows\tools\pkgconf\pkgconf.exe --libs --msvc-syntax gdal
/libpath:D:/vcpkg/installed/x64-windows/lib gdal.lib

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 ref 4e08971f3ddc13018ca858a692efe92d3b6b9fce.

Additional context

No response

rouault commented 1 month ago

My dependence on gdal.pc is very transient for me, and I've only ever built GDAL via vcpkg

Please use the GDAL CMake config file. The gdal.pc has never been thought for MSVC.

Dryvnt commented 1 month ago

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

rouault commented 1 month ago

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

dg0yt commented 1 month ago

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.

dg0yt commented 1 month ago

As a mitigation, any simple pc file error can be handled with an automated pc file fixup if there is a consistent substitution pattern.

dg0yt commented 18 hours ago

The same function generates gdal.pc and gdal-config. The first has --msvc-syntax to change the output, the second hasn't.

dg0yt commented 7 hours ago

And of course the config doesn't carry the debug postfix.