Jacob Champion:
>> libintl is already coming in via frontend_stlib_code, so that's fine.
>> So now I'm wondering if any other static clients of libpq-int.h (if
>> there are any) need the ssl dependency too, for correctness, or if
>> it's just me.
>
> Looks like it's just me. And using partial_dependency for the includes
> seems like overkill, so I've kept the full ssl dependency object, but
> moved it to the staticlib only, which is enough to solve the breakage
> on my machine.
>
> Nathan, if you get a chance, does the attached patch work for you?
I couldn't reproduce the problem, so did not test the latest patch. But
I tested a lot of scenarios on nixpkgs with latest master (250a718a):
- aarch64 + x86_64 architectures, both Linux and MacOS
- Autoconf and Meson
- Various features enabled / disabled in different configurations (NLS,
OpenSSL, GSSAPI)
- And additionally some cross-compiling from x86_64 Linux to aarch64
Linux and x86_64 FreeBSD
Worked very well.
The only inconsistency I was able to find is the autoconf-generated
libpq.pc file, which has this:
Requires.private: libssl, libcrypto libcurl
Note the missing "," before libcurl.
It does *not* affect functionality, though:
pkg-config --print-requires-private libpq
libssl
libcrypto
libcurl
The meson-generated libpq.pc looks like this:
Requires.private: openssl, krb5-gssapi, libcurl >= 7.61.0
I was only able to test the latter in an end-to-end fully static build
of a downstream dependency - works great. The final executable has all
the expected oauth strings in it.
Best,
Wolfgang
