On Sun, Jun 08, 2014 at 06:04:46PM -0400, Tom Lane wrote:
> Noah Misch <n...@leadboat.com> writes:
> > 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.

Good question; they need not distinguish.  !BUILDING_DLL means that the code
being compiled will access backend symbols through dynamic linking to
postgres.exe.  Server modules, such as plpgsql, build with !BUILDING_DLL, and
normal backend code builds with BUILDING_DLL.  The setting is irrelevant for
"frontend"/non-server code, which does not link to backend symbols at all.

> > 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.

Scratch that; configure.in has logic to discard template script CFLAGS changes
if the user had specified CFLAGS.

Noah Misch
EnterpriseDB                                 http://www.enterprisedb.com

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to