pkg-config support incomplete

[dabrahams]

Is it reproducible with SwiftPM command-line tools: swift build, swift test, swift package etc?

• Confirmed reproduction steps with SwiftPM CLI.

Description

I've found that (possibly only on Windows—it seems on other platforms I have library names in my pkg-config file), when my pkg-config file contains absolute paths to libraries in the Libs: line (e.g. c:\\path\\to\\Foo.lib), SPM additionally needs .linkedLibrary("Foo") in its linkerSettings. If you replace this line with

llvmLinkerSettings: [LinkerSetting] = []

and run CI on a fork of that project, you'll see what I mean. The code above that line is responsible for extracting the necessary settings from the pkg-config file.

Expected behavior

No additional settings are needed.

Actual behavior

Link errors

Steps to reproduce

See Description.

Swift Package Manager version/commit hash

Swift Package Manager - Swift 5.9.0

Swift & OS version (output of swift --version ; uname -a)

No response

[grynspan]

Paging @compnerd.

[compnerd]

pkg-config is untested on Windows as it is not a native system tool and is not guaranteed to be present. Patches to improve that are welcome, but it is not a high priority item due to the existing litany of shortcomings in SPM that make porting to non-Darwin platforms challenging.

[dabrahams]

With all due respect and gratitude to @compnerd for his tireless and generous support of Swift on Windows, I have some issues with this response

pkg-config is untested on Windows

By whom? Windows is certainly a supported platform. Behavior on Windows is discussed in the pkg-config man page.

as it is not a native system tool and is not guaranteed to be present.

Not sure what "native system tool" means but how is this different from Git, which is absolutely needed for SPM to work?

Patches to improve that are welcome, but it is not a high priority item due to the existing litany of shortcomings in SPM that make porting to non-Darwin platforms challenging.

As you know I am well aware of the many shortcomings in SPM but I don't see how that's relevant here in the SPM bug tracker. This response sounds to me like "SPM is broken, therefore don't expect anyone to fix bugs in it."

If you're really saying @compnerd has given up trying to improve SPM (for good reasons) and nobody else is likely to invest effort in fixing a windows-only problem, I could understand that. Is that what you mean?

[compnerd]

By whom? Windows is certainly a supported platform. Behavior on Windows is discussed in the pkg-config man page.

Sorry, I wasn't clear, I meant pkg-config within SPM is untested. IIRC, even the tests are marked as skipped on Windows.

Not sure what "native system tool" means but how is this different from Git, which is absolutely needed for SPM to work?

Git is something which Microsoft distributes with Visual Studio. While still dependent on other pieces, I consider there to be a difference between the two.

If you're really saying @compnerd has given up trying to improve SPM (for good reasons) and nobody else is likely to invest effort in fixing a windows-only problem, I could understand that. Is that what you mean?

I think that I'm just not sure if the platform specific issues are possible to address within the Open Source process. It may be that it would require @MaxDesiatov to step in and help significantly. There are design considerations which hinder the ability to make significant leaps.

[dabrahams]

I think that I'm just not sure if the platform specific issues are possible to address within the Open Source process. It may be that it would require @MaxDesiatov to step in and help significantly. There are design considerations which hinder the ability to make significant leaps.

OK, that sounds like a real problem, but not specific to this bug report. In theory two things could happen to move this issue forward without "significant leaps:"

• Test whether absolute paths to libraries are even properly supported on macOS
  • if not this bug can be fixed there.
  • if so, implement the Windows-only workaround of internally adding .linkedLibrary("Foo") for each /Absolute/path/to/Foo.libthat's found via pkg-config.

[compnerd]

In theory, -L... with -l... should work on Windows. The problem is that the Swift PM representation of paths is completely unusable. It has no concept of an absolute path, only relative as it assumes that a path starting with / is universally absolute when that is a relative path.

[dabrahams]

I'm telling you, there is no -l... the library paths are (for some reason only on Windows) absolute. The file as written pn linux and windows is here. It was in both cases written by this script.

[compnerd]

Very interesting. The absolute path to the import library (or static library) should be fine. I don't think that should cause any issue unless they are getting filtered by the swift-driver. This might actually be a simpler issue to resolve then! This might be a case that we are miscategorising the input and accidentally dropping it.