Re: libcurl in libpq.pc - Mailing list pgsql-hackers

On Tue, Sep 23, 2025 at 7:01 AM Christoph Berg <myon@debian.org> wrote:
> Libs handling is ok:
>
> $ pkgconf --libs libpq
> -lpq
>
> But CFLAGS is not:
>
> $ pkgconf --cflags libpq
> Package libcurl was not found in the pkg-config search path.
> Perhaps you should add the directory containing `libcurl.pc'
> to the PKG_CONFIG_PATH environment variable
> Package 'libcurl', required by 'libpq', not found

Odd.

> This "we don't care about the difference between static and dynamic in
> CFLAGS" part of pkg-confg is actually a FAQ item:
>
>   3. My library z uses libx internally, but does not expose libx data
>   types in its public API. What do I put in my z.pc file?
>
>   Again, add the module to Requires.private if it supports pkg-config.
>   In this case, the compiler flags will be emitted unnecessarily, but
>   it ensures that the linker flags will be present when linking
>   statically. If libx does not support pkg-config, add the necessary
>   linker flags to Libs.private.

1) We're doing what they recommend, aren't we?
2) pkgconf does care about the difference [1]. Windows builds of
libpq-oauth aren't relevant yet, but libcurl does indeed ship a
Cflags.private setting.

> Since most libpq users are linking dynamically (and certainly
> everything in Debian), I will now patch libpq.pc to drop libcurl from
> Requires.private and add -lcurl to Libs.private.

Makes sense.

> 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?

On Tue, Sep 23, 2025 at 7:16 AM Christoph Berg <myon@debian.org> wrote:
> What I didn't say explicitly in the last message is that I want to
> avoid that all programs now build-depending on libpq-dev would have to
> add libcurl4-openssl-dev, or libpq-dev would have to depend on that.

For a platform that doesn't really do staticlibs, I think I definitely
agree with that.

> Furthermore, with libcurl4-openssl-dev installed, the pkgconf output
> changes, as said in that FAQ entry:
>
> $ 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.

> $ pkgconf --libs --static libpq
> -lpq -lpgcommon -lpgport -lpq-oauth -lssl -lcrypto -lgssapi_krb5 -lm -lldap -lssl -lz -lzstd -ldl -pthread -lcrypto
-lz-lzstd -ldl -pthread -lcurl -lidn2 -llber -lldap -llber -lssh2 -lssl -lcrypto -lcrypto -lunistring -lz -lbrotlidec
-lbrotlicommon-lzstd -pthread -L/usr/lib/x86_64-linux-gnu/mit-krb5 -lgssapi_krb5 -L/usr/lib/x86_64-linux-gnu/mit-krb5
-lkrb5-lk5crypto -lcom_err -lkrb5support -lssl -lz -lzstd -ldl -pthread -lcrypto -lz -lzstd -ldl -pthread -lpsl -lssh2
-lssl-lcrypto -lz -lgpg-error -lcrypto -lzstd -ldl -pthread -lz -lrtmp -lz -lgmp -lgnutls -lgmp -lunistring -latomic
-lnettle-lgmp -lnettle -ltasn1 -lidn2 -lunistring -lp11-kit -lhogweed -lgmp -lnettle -lnghttp2 -lnghttp3 
>
> (ugh)

Very ugly, but looks correct to me at a glance. Transitive
dependencies are fun...

> And after the libpq.pc change I plan:
> [...]
> $ 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?

Thanks,
--Jacob

[1] https://www.msys2.org/docs/pkgconfig/#cflagsprivate-static-libraries