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
