Re: narwhal and PGDLLIMPORT
Ashesh Vashi <ashesh.vashi@enterprisedb.com>
From: Ashesh Vashi <ashesh.vashi@enterprisedb.com>
To: Craig Ringer <craig@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2014-02-03T03:10:27Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
MinGW: Link with shell32.dll instead of shfolder.dll.
- 53566fc0940c 9.5.0 cited
-
Centralize getopt-related declarations in a new header file pg_getopt.h.
- 60ff2fdd9970 9.4.0 cited
-
Get rid of use of dlltool in Mingw builds.
- 846e91e0223c 9.4.0 cited
-
Export a few more symbols required for test_shm_mq module.
- 7d7eee8bb702 9.4.0 cited
-
Export set_latch_on_sigusr1 symbol for Windows.
- 708c529c7fde 9.4.0 cited
-
Use SHGetFolderPath instead of SHGetSpecialFolderPath to find the
- 889f03812916 8.1.0 cited
On Mon, Feb 3, 2014 at 6:52 AM, Craig Ringer <craig@2ndquadrant.com> wrote: > On 02/02/2014 09:03 AM, Tom Lane wrote: > > According to the buildfarm database, narwhal is running a gcc build on > > Windows 2003. That hardly seems like a mainstream use case. I could > > believe that it might be of interest to developers, but clearly no > > developers are actually running such a build. > > > > I think we should give serious consideration to desupporting this > > combination > > I'm not a fan of MinGW (gcc) on Windows, it's a right pain. It's also > the only open source compiler currently supported for PostgreSQL on > Windows - practically the only one available. I don't know about you, > but I'm not too keen on assuming Microsoft will continue to offer free > toolchains that're usable for our purposes. They're crippling their free > build tools more and more with each release, which isn't a good trend. > > If you wish to eliminate PGDLLIMPORT from the codebase the correct > approach would be building with --export-all-symbols (a MinGW extension > flag to gcc). That would make the MinGW builds consistent with the MSVC > build, which generates a .def file that exports all symbols. > > As for why PGDLLIMPORT appears to be required in some places on the MSVC > build, so far it's looking like we auto-export functions, but not > necessarily variables. In my experience, that is true. During some contrib module development, while accessing a postgresql variable it was crashing on windows, while same was accessible in non-windows platform. > I'd need to read the fairly scary MSVC build > genreator scripts in detail to confirm that, to see how they produce > their DEF files; that'll have to wait until after I've got the > row-security work sorted out. > > -- > Craig Ringer http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- -- Thanks & Regards, Ashesh Vashi EnterpriseDB INDIA: Enterprise PostgreSQL Company<http://www.enterprisedb.com> *http://www.linkedin.com/in/asheshvashi*<http://www.linkedin.com/in/asheshvashi>