Since this is in the NSPR repo, it needs to be reviewed by an NSPR peer.

In D68693#2100913, @glandium wrote:

-FS is already there. https://searchfox.org/mozilla-central/rev/fa2df28a49883612bd7af4dacd80cdfedcccd2f6/nsprpub/configure#6949

I'll try to reproduce the original error. These patches were done a few months ago. I saw these errors in some failed CI builds and just added this.
That was definitely some newer MSVC and NSS bundle then 2013, so the check

if test "$MSC_VER" -ge "1800"; then

should have correctly added -FS to the $CFLAGS. I'm really puzzled.

Maybe it was just some problem / conflict with some other changes I tried at the time.

FWIW the original work was done in https://gerrit.libreoffice.org/c/core/+/74751

LO tested gyp + ninja last month (some info in https://lists.freedesktop.org/archives/libreoffice/2020-February/084461.html), but had too many different failures on Windows, so that change was reverted in https://gerrit.libreoffice.org/c/core/+/91199

Hmm - thinking about it again, CFLAGS is just used for C files and -FS is not added to CXXFLAGS, but _DEBUG_FLAGS is. Maybe that was the real problem. Adding -FS also to CXXFLAGS shouldn't hurt.

Hmm - so I re-read the makefiles, and from all I can find, CXXFLAGS is never used, as it's just assigned to OS_CXXFLAGS in config/autoconf.mk.in, which is nowhere referenced. But then maybe CXXFLAGS is somehow referenced via some magic automatic make rule, when the %.cpp rule doesn't match. CCCFLAGS also uses OS_CFLAGS, for whatever reason. I'm more confused then before, as the configure.in case of "*-mingw*|*-msys*|*-cygwin*|*-mks*)" doesn't set any CXXFLAGS at all, while there are many assignments in the rest of the script.

Any idea, what might be going on?

Otherwise let's drop this.

I'll check, if LO CI now builds NSS in parallel without that patch. At least it works locally, but that wasn't a good indicator in the past, so…

So after a few builds, I've updated the patch. I still get parallel build failures on Windows, because of PDB access. See the patch commit message for the background of the bug, as I understand it.

In D68693#2149801, @glandium wrote:

It feels like it should still use -FS when compiling objects, and -Fd when linking.

We can't use the -Fd for linking, as NSPR on Windows directly calls the linker, like link -NOLOGO -DEBUG -DEBUGTYPE:CV -INCREMENTAL:NO accept.obj ../../../../dist/out/lib/plc4.lib ../../../../dist/out/lib/nspr4.lib ws2_32.lib -out:accept.exe for DLLs and EXEs. The PDB for these is correctly named, as also documented in the -PDB option of the MS linker: "The default file name for the PDB has the base name of the program and the extension .pdb".

As a side note: I found the following in pr/tests/Makefile.in for WINCE: LDOPTS += -link $(DIST)/lib/mozce_shunt.lib ws2.lib -DEBUG -DEBUGTYPE:CV -INCREMENTAL:NO -PDB:$(@:.exe=.pdb). So it looks like linking on Windows CE is done via the compiler...

Previously I had just checked the DLL pdb, so I missed, that the previous substitution of accept.obj resulted in accept..pdb. The link of the accept.exe still could produce a separate accept.pdb. Therefore I settled for the .obj.pdb postfix.

In D68693#2150186, @jmux wrote:

In D68693#2149801, @glandium wrote:

It feels like it should still use -FS when compiling objects, and -Fd when linking.

We can't use the -Fd for linking, as NSPR on Windows directly calls the linker, like link -NOLOGO -DEBUG -DEBUGTYPE:CV -INCREMENTAL:NO accept.obj ../../../../dist/out/lib/plc4.lib ../../../../dist/out/lib/nspr4.lib ws2_32.lib -out:accept.exe for DLLs and EXEs. The PDB for these is correctly named, as also documented in the -PDB option of the MS linker: "The default file name for the PDB has the base name of the program and the extension .pdb".

Then I don't see what the problem is you're trying to fix. With -FS, it should work.

As a side note: I found the following in pr/tests/Makefile.in for WINCE: LDOPTS += -link $(DIST)/lib/mozce_shunt.lib ws2.lib -DEBUG -DEBUGTYPE:CV -INCREMENTAL:NO -PDB:$(@:.exe=.pdb). So it looks like linking on Windows CE is done via the compiler...

Previously I had just checked the DLL pdb, so I missed, that the previous substitution of accept.obj resulted in accept..pdb. The link of the accept.exe still could produce a separate accept.pdb. Therefore I settled for the .obj.pdb postfix.

I mean, moving -FS to _DEBUG_FLAGS should work.

In D68693#2179830, @glandium wrote:

In D68693#2150186, @jmux wrote:

In D68693#2149801, @glandium wrote:

It feels like it should still use -FS when compiling objects, and -Fd when linking.

We can't use the -Fd for linking, as NSPR on Windows directly calls the linker, like link -NOLOGO -DEBUG -DEBUGTYPE:CV -INCREMENTAL:NO accept.obj ../../../../dist/out/lib/plc4.lib ../../../../dist/out/lib/nspr4.lib ws2_32.lib -out:accept.exe for DLLs and EXEs. The PDB for these is correctly named, as also documented in the -PDB option of the MS linker: "The default file name for the PDB has the base name of the program and the extension .pdb".

Then I don't see what the problem is you're trying to fix. With -FS, it should work.

I'm trying to fix the .../nss/nspr/pr/tests/zerolen.c: fatal error C1041: Programmdatenbank "...\nss\nspr\out\pr\tests\vc140.pdb" kann nicht ge<94>ffnet werden; verwenden Sie /FS, wenn mehrere CL.EXE in dieselbe .PDB-Datei schreiben. error. As you already noticed, the build uses -FS, so that error message is misleading.

-FS is a compiler flag and I don't see an equivalent for the linker. My theory of the failure is, that the linker reads the shared PDB vc140.pdb to generate the PDB for the EXE, but the compiler still want to write to the shared PDB creating the OBJs of the last tests. Any idea how to prove this?

I tried again to build NSPR with tests on Windows, but in the mozilla setup it simply doesn't link the test EXEs and just finishes successful. which puzzles me. Building NSS via LO env incl. this patch works and fails without. And none of LOs additional NSS patches looks like it should affect linking...

In D68693#2179834, @glandium wrote:

I mean, moving -FS to _DEBUG_FLAGS should work.

So I exchanged

-                                                CFLAGS="$CFLAGS -FS"
+                                                _DEBUG_FLAGS="$_DEBUG_FLAGS -FS"

but that still fails in the same way.

I'm trying to build NSPR with unpatched NSPR and NSS sources using the following script:

#!/bin/sh

FLAGS="USE_64=1 MOZ_DEBUG_SYMBOLS=1 USE_DEBUG_RTL=1 OPT_CODE_SIZE=0 OS_TARGET=WIN95"

export PATH="/c/mozilla-source/gyp:$PATH"
export target_arch=x64
. nss/coreconf/msvc.sh

set -x

make -j6 -C nss clobber_nspr $FLAGS >/dev/null 2>&1
rm -rf dist/
rm -rf nspr/WIN954.0_x86_64_64_DBG.OBJ/
make -j6 -C nss build_nspr $FLAGS >nspr.log 2>&1

How can we continue with this? Building parallel NSS without this patch on Windows breaks for me in NSPR most of the time, so I see no point to land all the NSS patches without a fixed NSPR build. Do you also see my described problems?

I have to disconnect the NSPR change from the NSS ones, Lando can't handle both at once.