Re: narwhal and PGDLLIMPORT

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: narwhal and PGDLLIMPORT
Дата
Msg-id 52EF1468.6080107@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: narwhal and PGDLLIMPORT  (Ashesh Vashi <ashesh.vashi@enterprisedb.com>)
Ответы Re: narwhal and PGDLLIMPORT  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
On 02/03/2014 11:10 AM, Ashesh Vashi wrote:
> On Mon, Feb 3, 2014 at 6:52 AM, Craig Ringer <craig@2ndquadrant.com
> <mailto: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 think it's a good thing personally - we shouldn't be exporting every
little internal var in the symbol table.

If we built with -fvisibility=hidden on 'nix there'd be no need to
complain about commits being on on 'nix then breaking on Windows, 'cos
the 'nix build would break in the same place. That's all or nothing
though, there's no "vars hidden, procs exported" option in gcc.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Etsuro Fujita
Дата:
Сообщение: Re: inherit support for foreign tables
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: narwhal and PGDLLIMPORT