Hi, On 2025-04-11 18:21:14 +0200, Wolfgang Walther wrote: > Jacob Champion: > > On Wed, Apr 9, 2025 at 4:42 PM Jelte Fennema-Nio <postg...@jeltef.nl> wrote: > > > I think your suggestion of not using any .so files would best there (from > > > w user perspective). I'd be quite surprised if a static build still > > > resulted in me having to manage shared library files anyway. > > Done this way in v5. I had planned to separate the implementations by > > a #define, but I ran into issues with Makefile.shlib, so I split the > > shared and dynamic versions into separate files. I just now realized > > that we do something about this exact problem in src/common, so I'll > > see if I can copy its technique for the next go round. > > I tried to apply this patch to nixpkgs' libpq build [1]. First, I pinned a > recent commit from master (one where the v5 patch will apply cleanly later) > and enabled --with-libcurl [2]. > > At this stage, without the patch applied, I observe the following: > > 1. The default, dynamically linked, build succeeds and libpq.so is linked to > libcurl.so as expected! > > 2. The statically linked build fails during configure:
What specifically does "statically linked build" mean? There is no such thing in postgres, so this must be either patching upstream or injecting build flags somehow? The [1] link wasn't immediately elucidating. > checking for curl_multi_init in -lcurl... no > configure: error: library 'curl' does not provide curl_multi_init > > config.log tells me that it can't link to libcurl, because of undefined > references, for example: > > undefined reference to `psl_is_cookie_domain_acceptable' > undefined reference to `nghttp2_session_check_request_allowed' > > I assume the many libs listed in Libs.private in libcurl.pc are not added > automatically for this check? The configure test shouldn't link statically, so this doesn't make sense to me? Greetings, Andres Freund
