Re: doc: pgevent.dll location

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "Ryohei Takahashi (Fujitsu)" <r(dot)takahashi_2(at)fujitsu(dot)com>, Dave Page <dpage(at)pgadmin(dot)org>, Gurjeet Singh <gurjeet(at)singh(dot)im>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: doc: pgevent.dll location
Date: 2024-11-12 16:52:27
Message-ID: 130a8a66-c5eb-49d4-bba9-8ff473c4a0c2@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12.11.24 17:02, Robert Haas wrote:
> On Wed, Nov 6, 2024 at 11:11 AM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>> I don't have Windows handy to test it out, but looking at the respective
>> build system source files, in master, pgevent is built and installed
>> like a normal shared library in both meson.build and Makefile, so it
>> should end up somewhere in lib.
>>
>> In src/tools/msvc in REL_16_STABLE, I see some code that appears to
>> suggest that it installs in bin.
>>
>> Again, this is just reading the code, but it seems to be backwards from
>> what is claimed earlier.
>>
>> The statements like "in PGxxx it did this" are not precise enough
>> because there are three possible build systems. We need to know what
>> each build system is doing. Also, the consideration of consistency
>> should go in two dimensions: Consistency between versions and
>> consistency between build systems.
>
> To what three systems are you referring? I thought we now only
> supported building with meson on Windows, and this is a
> Windows-specific file. Everyone seems to be saying the file has moved
> in v17, so it seems like we should either move it back or update the
> documentation as proposed. The question of why it has moved is perhaps
> worth some investigation, but seems like a secondary issue.

The three possible build systems are:

1. src/tools/msvc/
2. meson
3. make

The first one was removed, but the second and the third one still exist.

I can tell from the build farm logs (fairywren) that on master with
meson the installation layout is

Installing src\\bin\\pgevent\\pgevent.dll to
C:/tools/xmsys64/home/pgrunner/bf/root/HEAD/inst\\bin
Installing src\\bin\\pgevent\\pgevent.dll.a to
C:/tools/xmsys64/home/pgrunner/bf/root/HEAD/inst\\lib

This appears to be the meson default for shared libraries, because we
also have

Installing src/interfaces/libpq\\libpq.dll to
C:/tools/xmsys64/home/pgrunner/bf/root/HEAD/inst\\bin
Installing src/interfaces/libpq\\libpq.dll.a to
C:/tools/xmsys64/home/pgrunner/bf/root/HEAD/inst\\lib

We don't have any coverage on master for make on Windows, but I can see
on REL_15_STABLE (fairywren)

/usr/bin/install -c -m 755 pgevent.dll
'/home/pgrunner/bf/root/REL_15_STABLE/inst/lib/postgresql/pgevent.dll'

and I strongly suspect that this is unchanged in master.

Note here that meson installs this file as a shared library (like libpq)
but make installs this file as a shared module (like plpgsql).

Also, looking at the source code of the old msvc build system
(Install.pm, sub CopySolutionOutput), it will install this file into lib
in the logic that is is a "dll" file that is *not* a shared library (has
no SO_MAJOR_VERSION set). So the msvc system appears to be consistent
with the make system in that respect.

So the most straightforward way to "make it work like it used to" would
be to change src/bin/pgevent/meson.build to use shared_module() instead
of shared_library().

Based on the explanation in the documentation, this file is really more
of a plugin and less a shared library, so I think that approach would be
more correct than not.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ranier Vilela 2024-11-12 17:05:40 Fix array access (src/bin/pg_dump/pg_dump.c)
Previous Message Alvaro Herrera 2024-11-12 16:50:41 Re: Virtual generated columns