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 <postgres@jeltef.nl> wrote:
> > > I think your suggestion of not using any .so files would best there (from w user perspective). I'd be quite
surprisedif 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
