Re: meson: Add _static and _shared suffixes to the library names - Mailing list pgsql-hackers

From Andres Freund
Subject Re: meson: Add _static and _shared suffixes to the library names
Date
Msg-id vytjpmcze3scjuwzvldrixi7dbyqghghudmtfadboyji3rgij3@3xh37jkdzehe
Whole thread Raw
In response to Re: meson: Add _static and _shared suffixes to the library names  (Nazir Bilal Yavuz <byavuz81@gmail.com>)
Responses Re: meson: Add _static and _shared suffixes to the library names
List pgsql-hackers
Hi,

On 2025-08-13 09:36:23 +0300, Nazir Bilal Yavuz wrote:
> Thank you all for sharing your thoughts and I am sorry for the first
> proposal. It is a mistake on my part, I should have thought more.

That's just iterative development, don't worry about it.


> On Tue, 12 Aug 2025 at 21:47, Peter Eisentraut <peter@eisentraut.org> wrote:
> > On 12.08.25 18:37, Jacob Champion wrote:
> > > On Tue, Aug 12, 2025 at 9:27 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > >>> Is there a way to work around this problem in a way that affects Windows only?
> > >>
> > >> Even on Windows, the proposal is unacceptable.
> > >
> > > Sure, but I'm hoping that there's some Windows-specific Meson
> > > twiddling that can be done to disambiguate the debug files on disk.
> >
> > Here is an older discussion that also involved having concurrent
> > shared_library() and static_library() on Windows, and the general
> > sentiment there appeared to be that this should (be made to) work:
> > https://github.com/mesonbuild/meson/issues/459
> 
> I think the problem in the link you shared is different, we have
> problems with Windows debug files (*.pdb files) but they have problems
> with the library files themselves. Our problem is that the latest
> built library tries to overwrite the early built library's .pdb file
> and the build fails. So, my guess is that the libraries are in
> different paths but their .pdb files are still in the same path. I did
> a quick check and found that we have only one .pdb file after the
> build, which I think confirms my guess. After the #1 fix applied, we
> have two .pdb files; one .pdb file for each library type.

Yea.


> > So I don't know what changed now, but I think we should think about in
> > terms of what changed rather than fixing our code.
> 
> I think we had this problem for a long time but the new ninja version
> showed that problem.

Right - I'm fairly sure that if you built sequentially with an older ninja
you'd also see the issue.


> I found two ways to fix that problem, both approaches fix the problem
> by themselves:
> 
> 1- Setting different names for .pdb files for shared libraries only on
> the Windows OS. I think that is the correct fix, it just adds _shared
> suffix to .pdb files of shared libraries on the Windows OS.

I don't think it is right to do this "below" meson - presumably this means
that meson install won't work correctly, as it doesn't know about the changed
pdb file names.


> 2- Using '/DEBUG:FULL' instead of '/DEBUG:FASTLINK' in the Windows CI
> task but this causes more memory to be used. It seems that the error
> appears only when the '/DEBUG:FASTLINK' is set. '/DEBUG:FULL' is a
> default option, so we may decide to not add it at all. I explicitly
> added it as I found this easier to understand. This approach fixes the
> build but I think it is not the correct fix, we will have one .pdb
> file after this fix; not one for each library type.

I think it's an acceptable fix for now. I added /DEBUG:FASTLINK to the CI
task when it was using windows containers, as we'd run out of memory
occasionally. But since we aren't using those anymore, I think the best way to
make CI work again is to simply stop using /DEBUG:FASTLINK.

Separately I think we should report this as a bug to meson. Could you perhaps
create a minimal reproducer of the issue and report it?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: PG 18 release notes draft committed
Next
From: Andres Freund
Date:
Subject: Re: Annoying warning in SerializeClientConnectionInfo