Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Dryvnt opened this issue Sep 4, 2024 · 7 comments
Open

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

Dryvnt opened this issue Sep 4, 2024 · 7 comments

Comments

@Dryvnt
Copy link

Dryvnt commented Sep 4, 2024

What is the bug?

gdal.pc is generated during CMake for Windows builds. Per #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
Copy link
Member

rouault commented Sep 4, 2024

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
Copy link
Author

Dryvnt commented Sep 4, 2024

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
Copy link
Member

rouault commented Sep 4, 2024

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
Copy link
Contributor

dg0yt commented Sep 4, 2024

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
Copy link
Contributor

dg0yt commented Sep 4, 2024

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
Copy link
Contributor

dg0yt commented Nov 2, 2024

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
Copy link
Contributor

dg0yt commented Nov 2, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants