Re: libcurl in libpq.pc

Re: Jacob Champion
> 1) We're doing what they recommend, aren't we?

Maybe by the letter, but I think we have a real problem and need to do
something.

> > I would say this change should make it into 18.1's libpq.pc file.
>
> As in, 18.1 on Debian? Or are you suggesting we apply that change in Postgres?

In Postgres. If we want more libpq.pc adoption in client programs (and
less snowflake solutions based on pg_config), we should make it
hassle-free. Otherwise these users will have to also install libcurl
to compile, even if it's not used, and then the security people will
fire up their scanning tools which we wanted to avoid.

> > $ pkgconf --cflags libpq
> > -I/usr/include/postgresql -I/usr/include/x86_64-linux-gnu -isystem /usr/include/mit-krb5 -I/usr/include/p11-kit-1
> >
> > That might be harmless, but we should avoid it.
>
> I think we can't avoid it; if anyone wants to get Windows support
> working they'll need -DCURL_STATICLIB as provided by libcurl.pc.

That would be in Cflags.private.

> > $ pkgconf --libs --static libpq
> > -lpq -lpgcommon -lpgport -lpq-oauth -lssl -lcrypto -lgssapi_krb5 -lm -lldap -lcurl -lssl -lz -lzstd -ldl -pthread -lcrypto -lz -lzstd -ldl -pthread
>
> Prettier, but wrong? I don't think that's going to link, is it?

Wrong how?

The patch I ended up using is this:

--- a/src/interfaces/libpq/Makefile
+++ b/src/interfaces/libpq/Makefile
@@ -110,10 +110,7 @@ $(call add_to_list,PKG_CONFIG_REQUIRES_P
endif

ifeq ($(with_libcurl),yes)
-# libpq.so doesn't link against libcurl, but libpq.a needs libpq-oauth, and
-# libpq-oauth needs libcurl. Put both into *.private.
-$(call add_to_list,PKG_CONFIG_REQUIRES_PRIVATE,libcurl)
-%.pc: override SHLIB_LINK_INTERNAL += -lpq-oauth
+%.pc: override SHLIB_LINK_INTERNAL += -lpq-oauth -lcurl
endif

all: all-lib libpq-refs-stamp

I tried looking at meson.build as well, but couldn't figure out how to
do exactly this, and since the Debian package hasn't switched yet,
this was good enough.

Christoph