Hi,
On 2024-11-12 16:11:44 -0500, Robert Haas wrote:
> On Tue, Nov 12, 2024 at 3:06 PM Peter Eisentraut <pe...@eisentraut.org> wrote:
> > In this context, a shared module is something like plpgsql or hstore
> > that you dlopen, and a shared library is something like libpq or libecpg
> > that you -l at build time.
>
> That's interesting, but I would have thought both of those would go in
> libdir (or a subdirectory) not bindir.
That's true on unixoid systems, but due to the way library searchpaths work on
windows, you pretty much need to store them alongside the binary. Otherwise
the dynamic linker won't find the library. And because that happens before
application code is executed, you don't have a chance to specify a different
path ([1]). So on windows shared libraries are typically located alongside
the executable. Which we did for src/tools/msvc and do for make/meson based
builds on windows.
In contrast to that, if you do dlopen() with an explicit path, you can
obviously locate the file anywhere. So for postgres extension libs etc we
could keep them in lib/.
But it's not entirely clear how to describe pgevent.dll - which lead to the
change between src/tools/msvc and meson based builds.
FWIW, the main reason for the shared_library() vs shared_module() distinction
are macos and windows (and also AIX), where the build process for them is
different than on most unices. Libraries aren't allowed to have undefined
symbols there. That's fine for typical dynamic libraries, but for plugin style
things, it means they explicitly need to told where the symbols come from. On
windows by listing the symbols, on macos by explicitly linking extensions
against the postgres binary.
Greetings,
Andres Freund
[1] well, there are some hacky ways to execute code earlier and change the
library path, but it's quite complicated
