gdal icon indicating copy to clipboard operation
gdal copied to clipboard

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

Open Dryvnt opened this issue 1 year ago • 5 comments

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

Dryvnt avatar Sep 04 '24 11:09 Dryvnt

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.

rouault avatar Sep 04 '24 11:09 rouault

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

Dryvnt avatar Sep 04 '24 12:09 Dryvnt

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

rouault avatar Sep 04 '24 12:09 rouault

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 avatar Sep 04 '24 12:09 dg0yt

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 avatar Sep 04 '24 13:09 dg0yt

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

  • Is gdal-config actually used with MSVC?
  • Does gdal-config produce wellformed-output?

dg0yt avatar Nov 02 '24 06:11 dg0yt

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

dg0yt avatar Nov 02 '24 17:11 dg0yt