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: