Re: Missing file versions for a bunch of dll/exe files in Windows builds

On Mon, Jul 14, 2014 at 03:03:28PM -0400, Noah Misch wrote:
> On Fri, Jul 11, 2014 at 11:14:54PM -0700, Michael Paquier wrote:
> > On Fri, Jul 11, 2014 at 10:34 PM, Noah Misch <noah@leadboat.com> wrote:
> > > Please fix the MODULES case, perhaps by linking $(WIN32RES) into each library
> > > implicitly.

That idea was somewhat too broad.

> > Yes, that's exactly what I did in the patch attached by linking
> > WIN32RES and a shared library when the lib is built from a single .o
> > file. The rule in src/makefiles/Makefile.win32 has been updated
> > accordingly. pgxs.mk has been updated as well to remove WIN32RES when
> > clean is invoked for MODULES.
>
> There remained several binaries versioned under MSVC and not versioned under
> MinGW.  With those fixed, I committed this work.

PostgreSQL 9.5 pgxs tries to link $(WIN32RES) into any single-file module, not
just in-tree modules.  Unless the module happens to ship a win32ver.rc file,
the build fails.  MODULE_big modules are unaffected.

I plan to fix this as attached, by linking $(WIN32RES) into single-file
modules only when PGFILEDESC is set in the Makefile.  That better aligns the
GNU make build system with the heuristic in the MSVC build system's
Project::AddDirResourceFile().  External modules wishing to embed a DLL icon
and/or version information should provide a win32ver.rc and set PGFILEDESC.
(As in released versions, MODULE_big modules must additionally mention
$(WIN32RES) in OBJS.)  Modules not desiring Windows file version information
should leave PGFILEDESC unset.  In-tree, installed modules do set PGFILEDESC;
to build one using PGXS, you can first build without PGXS and preserve the
generated win32ver.rc.

One alternative I considered was to link with $(WIN32RES) only when PGXS is
unset.  That would omit version information from in-tree, single-file modules
built with PGXS.  Unlike my plan, it would not break builds of modules that
set PGFILEDESC without intending to trigger inclusion of version information.
However, a grep of the code in PGXN found no affected module.

Thanks,
nm