libcurl.pc.in: drop LDFLAGS from Libs.private #15533
Conversation
Stop passing linker flags to pkg-config. This was added in v8.11.0 with commit [1]. There are several problems with this, especially: * user may want to link curl and application with different flags * user usually adds the same or similar flags in all components, so this will double the flags when linking application * when building components in temporary directories, these directories are preserved in pkg-config linker flags and are invalid when building application [1] curl@9f56bb6 Signed-off-by: Peter Marko <peter.marko@siemens.com>
|
LDFLAGS were added in a different commit in an earlier release to libcurl.pc for CMake builds (see 296e855). The flags are libpaths and frameworks, which seems critical. The commit referenced in OP added them for autotools, to bring the two build methods closer. Can you give examples of the issues you experienced to understand them better? Are you seeing these with autotools, cmake, both? |
|
I'm seeting this when building within Yocto project, which uses autotools for curl component. |
|
It's pretty difficult to guess in the general case which flags should be in the
.pc file and which shouldn't. Putting them all in there is probably more likely
to work than not, but it's basically expected that libcurl builders will be
modifying the .pc file to suit before use by arbitrary dependents.
|
Can't say off-hand if it would or wouldn't improve the .pc file in general but technically it's probably possible to avoid inheriting custom flags (the majority in this particular example), and instead include just those that resulted from curl's dependency detections. Syncing this with cmake even more. But this would possibly also not satisfy this checker due to the temp libpath. Which in turn is a valid path and can be required in other build-cases. (One may also expect that custom LDFLAGS are inherited.) I'm wondering what more could curl do to satisfy a custom checker? Also, the checker has all the information to strip what it deems unfitting and create the pc file it needs. |
|
it's possible to put things like the curl-config.in has the same issue in it, technically (having LDFLAGS echoed into it for --static), which has been there for much longer than this change in 8.11 |
|
I made a branch omitting inherited Perhaps |
Yocto handles this file differently and has to play the path replacement games to avoid multilib conflicts. Additionally it's used from native build, not from cross-compile build as cross-compiled executables are in general considered unsafe for native execution. And we don't use static linking for libcurl afaik.
I wouldn't expect that reverting this one line would cause test failures (as that was a working implementation for decades until now). Well, I don't know what to do with this PR now to finish it to a mergeable state and there are many opened questions in above comments. |
|
Deleting a macro reference I don't think gets us closer to the desired outcome. It breaks a bunch of critical cases and reverses track on the effort to sync generated config files. The desired outcome is to have For this we'd probably need to decide what's useful to include in them. What keeps me wondering not just in this report but a few others from recently is why are dependent projects using the Here's the WIP branch to stop echoing inherited LDFLAGS: #15550 |
|
#15550 is ready for review and tests. |
|
#15550 is superior to this PR, so closing... |
`libcurl.pc` `Libs.private` (since 8.11.0, and in `Libs` before 7.20.0) and `curl-config` `--static-libs` (since 7.17.1, and in `Libs` between 7.7.2-7.25.0). This included all flags inherited from the environment, in addition to those coming from dependency detections. To avoid spilling all linker flags inherited from the environment to the libcurl config files, this patch omits them all, except `-L`, `-F`, `--library-path=` and `-framework` options, which are still passed. The rationale for the exceptions is that `LIBS` is passed as-is, and `LDFLAGS`, `LIBS` are the canonical way to pass custom libs options to a build. `LIBS` may not work without a matching custom libpath. This brings autotools behaviour closer to cmake, and `curl-config` closer to `libcurl.pc`. Follow-up to 9f56bb6 #14681 Follow-up to 4c8adc8 Reported-by: Peter Marko Fixes #15533 Closes #15550
Stop passing linker flags to pkg-config.
This was added in v8.11.0 with commit [1].
There are several problems with this, especially:
[1] 9f56bb6