On 05.09.21 21:57, Tom Lane wrote:
Peter Eisentraut 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 unhap
Peter Eisentraut 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 p
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 th
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
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:/
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 nam
