Re: MinGW/Cygwin build snags

Noah Misch <noah(at)leadboat(dot)com> writes:
> First, when I tried to add an Assert() call to a file in src/port, a MinGW-w64
> build failed like this:

> Creating library file: libpostgres.a
> ../../src/port/libpgport_srv.a(fls_srv.o): In function `fls':
> /home/nm/src/pg/mingw-postgresql/src/port/fls.c:63: undefined reference to `__imp_assert_enabled'

FWIW, I think we had consensus to remove the assert_enabled variable
entirely. Not that it wouldn't be good to fix this, but Assert per se
won't need it after we do that.

> Since src/makefiles/Makefile.win32 does not set BUILDING_DLL for src/port,
> PGDLLIMPORT is set improperly for code to be linked directly into the backend.
> Makefile.win32 does set BUILDING_DLL for src/common. (Makefile.cygwin has the
> same discrepancy, though I haven't checked whether it causes an actual build
> failure there. The MSVC build system sets BUILDING_DLL for both src/port and
> src/common files.) This affects any reference to a data symbol from src/port.
> The fix is straightforward enough: cause Makefile.{win32,cygwin} to treat
> src/port like src/common.

I wonder whether these cases shouldn't distinguish between the "frontend"
and "backend" builds of src/port/ and src/common/. In particular, it
seems odd that we're getting this type of failure in the backend build.

> Second, src/template/{win32,cygwin} completely replaces LDFLAGS, so overriding
> LDFLAGS on the "configure" command line is ineffective. Those scripts should
> instead add to the existing LDFLAGS, like other templates do for CPPFLAGS.
> Several other templates completely override CFLAGS; that's undesirable for the
> same reason. I don't have ready access to those affected configurations, so
> I'm leaving the CFLAGS damage alone.

+1 for doing something about CFLAGS while we're at it.

> Both of these changes fix bugs, but I plan not to back-patch.

Agreed; the lack of complaints to date suggests that we should leave
well enough alone in the back branches.

regards, tom lane