Re: narwhal and PGDLLIMPORT - Mailing list pgsql-hackers

From Marco Atzeri
Subject Re: narwhal and PGDLLIMPORT
Date
Msg-id 52FBC606.2060107@gmail.com
Whole thread Raw
In response to Re: narwhal and PGDLLIMPORT  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: narwhal and PGDLLIMPORT  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 12/02/2014 19:19, Andres Freund wrote:
> On 2014-02-12 19:13:07 +0100, Marco Atzeri wrote:
>> On 12/02/2014 17:26, Tom Lane wrote:
>>> Hm.  So if we're giving up on the idea of ever getting rid of PGDLLIMPORT,
>>> we ought to actually remove that, so that the Cygwin build works more like
>>> the other Windows builds?
>
>> If I am not wrong "--enable-auto-import" is already the
>> default on cygwin build chain ( binutils >= 2.19.51 ) so it should make no
>> difference on latest cygwin. Not sure for you 1.7.7 build enviroment.
>
> We're *disabling* not *enabling* it.

remove is not disable if enable is already the default inside
binutils and gcc. Or I am missing something ?


>> About PGDLLIMPORT , my build log is full of "warning: ‘optarg’ redeclared
>> without dllimport attribute: previous dllimport ignored "
>
> That should be fixed then. I guess cygwin's getopt.h declares it that way?

from /usr/include/getopt.h

#ifndef __INSIDE_CYGWIN__
extern int __declspec(dllimport) opterr;        /* if error message 
should be printed */
extern int __declspec(dllimport) optind;        /* index into parent 
argv vector */
extern int __declspec(dllimport) optopt;        /* character checked for 
validity */
extern int __declspec(dllimport) optreset;      /* reset getopt */
extern char __declspec(dllimport) *optarg;      /* argument associated 
with option */
#endif


>
>> I suspect that removing will also make no difference.
>
> The committed patch explicitly disables the functionality.
>
>> PS: we aim unix-like builds not windows one....
>
> Well, there are a significant number of caveats around the auto import
> functionality, so there seems little benefit in using it if all the
> declspec's have to be there anyway.

I think that I am not currently using anymore the declspec in the build.
But I could be wrong, as the the postgresql build way
is the most complicated between all the ones I am dealing with.

> Greetings,
>
> Andres Freund
>

Cheers
Marco



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Recovery inconsistencies, standby much larger than primary
Next
From: Tom Lane
Date:
Subject: Re: narwhal and PGDLLIMPORT