Thread: Fix pkg-config file for static linking
Since https://github.com/postgres/postgres/commit/ea53100d5 (or Postgres 12.0) the shipped pkg-config file is broken for statically linking libpq because libpgcommon and libpgport are missing. This patch adds those two missing private dependencies.
Attachment
On 21.06.21 15:47, Filip Gospodinov wrote: > -PKG_CONFIG_REQUIRES_PRIVATE = libssl libcrypto > +PKG_CONFIG_REQUIRES_PRIVATE = libpgcommon libpgport libssl libcrypto This doesn't work. This patch adds libpgcommon and libpgport to Requires.private. But they are not pkg-config names but library names, so they should be added to Libs.private.
On 06.07.21 15:13, Peter Eisentraut wrote: > This doesn't work. > > This patch adds libpgcommon and libpgport to Requires.private. But they > are not pkg-config names but library names, so they should be added to > Libs.private. Then, I must admit that I have misunderstood this patch at first https://github.com/postgres/postgres/commit/beff361bc1edc24ee5f8b2073a1e5e4c92ea66eb . My impression was that PKG_CONFIG_REQUIRES_PRIVATE ends up in Libs.private because of this line https://github.com/postgres/postgres/blob/d9809bf8694c17e05537c5dd96cde3e67c02d52a/src/Makefile.shlib#L403 . After taking a second look, I've noticed that PKG_CONFIG_REQUIRES_PRIVATE is *filtered out*. But unfortunately, this currently doesn't work as intended because PKG_CONFIG_REQUIRES_PRIVATE seems to be unset in Makefile.shlib which leaves Requires.private empty and doesn't filter out -lcrypto and -lssl for Libs.private. That must be also the reason why I first believed that PKG_CONFIG_REQUIRES_PRIVATE is used to populate Libs.private. Anyway, this issue is orthogonal to my original patch. I'm proposing to hardcode -lpgcommon and -lpgport in Libs.private instead. Patch is attached.
Attachment
On 20.07.21 22:04, Filip Gospodinov wrote: > Anyway, this issue is orthogonal to my original patch. I'm proposing to > hardcode -lpgcommon and -lpgport in Libs.private instead. Patch is > attached. Makes sense. I think we could do it without hardcoding those library names, as in the attached patch. But it comes out to the same result AFAICT.
Attachment
On 02.09.21 13:07, Peter Eisentraut wrote: > On 20.07.21 22:04, Filip Gospodinov wrote: >> Anyway, this issue is orthogonal to my original patch. I'm proposing >> to hardcode -lpgcommon and -lpgport in Libs.private instead. Patch is >> attached. > > Makes sense. I think we could do it without hardcoding those library > names, as in the attached patch. But it comes out to the same result > AFAICT. That is my impression too. Enumerating them in a variable would just lead to an indirection. Please let me know if you'd still prefer a solution without hardcoding.
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> Makes sense. I think we could do it without hardcoding those library
> names, as in the attached patch. But it comes out to the same result
> AFAICT.
This has been pushed, but the CF entry is still open, which is
making the cfbot unhappy. Were you leaving it open pending
pushing to back branches as well? I'm not sure what the point
of waiting is --- the buildfarm isn't going to exercise the
troublesome scenario.
regards, tom lane
On 05.09.21 21:57, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes: >> Makes sense. I think we could do it without hardcoding those library >> names, as in the attached patch. But it comes out to the same result >> AFAICT. > > This has been pushed, but the CF entry is still open, which is > making the cfbot unhappy. Were you leaving it open pending > pushing to back branches as well? I'm not sure what the point > of waiting is --- the buildfarm isn't going to exercise the > troublesome scenario. I noticed another fix that was required and didn't get to it until now. It's all done and backpatched now. CF entry is closed.