Proposal:Use PGDLLEXPORT for libpq
Hello hackers.
Why we do not use PGDLLEXPORT (__declspec (dllexport)) for the libpq (and
other dlls)?
Now we are using black magic with gendef.pl for get def (aka export.txt)
from .obj files.
I have set for some functions and it works.
Perhaps there is a circumstance that I do not know but my version seems to
me simplify build under Windows.
Thanks.
--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 26 January 2016 at 23:04, Yury Zhuravlev <u.zhuravlev@postgrespro.ru>
wrote:
Hello hackers.
Why we do not use PGDLLEXPORT (__declspec (dllexport)) for the libpq (and
other dlls)?
Now we are using black magic with gendef.pl for get def (aka export.txt)
from .obj files.
I have set for some functions and it works.
Perhaps there is a circumstance that I do not know but my version seems to
me simplify build under Windows.
See
/messages/by-id/1389762012.24046.2.camel@vanquo.pezone.net
and
/messages/by-id/0LiX1g-1VPi6O3RoS-00d3Jf@mrelayeu.kundenserver.de
(sorry for HTML horror)
for history.
TL;DR: PGDLLEXPORT is considered ugly Windows-droppings in the code and so
a less visible, albeit more convoluted, solution is used.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Craig Ringer wrote:
TL;DR: PGDLLEXPORT is considered ugly Windows-droppings in the
code and so a less visible, albeit more convoluted, solution is
used.
It says more about the modules, and not about libpq. Using gendef.pl for
this library in the light of the development of my CMake build seems silly.
--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 27 January 2016 at 00:16, Yury Zhuravlev <u.zhuravlev@postgrespro.ru>
wrote:
It says more about the modules, and not about libpq. Using gendef.pl for
this library in the light of the development of my CMake build seems silly.
For what it's worth I personally agree. I'd rather have PGDLLEXPORT used
directly, not least because it'd let us built with -fvisibility=hidden
under *nix. But I'm in the minority and not inclined to push the point.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Craig Ringer wrote:
On 27 January 2016 at 00:16, Yury Zhuravlev
<u.zhuravlev@postgrespro.ru> wrote:It says more about the modules, and not about libpq. Using
gendef.pl for this library in the light of the development of my
CMake build seems silly.For what it's worth I personally agree. I'd rather have
PGDLLEXPORT used directly, not least because it'd let us built
with -fvisibility=hidden under *nix. But I'm in the minority and
not inclined to push the point.
If so many problems with MSVC can discard his support of Postgres?
MSVC:
Not supported C99-C1x.
Problems build dynamic library.
Realy problems build out-tree module.
etc
Under windows we can use MinGW64/Msys or LLVM/Clang for MSVC.
The current situation is similar to masochism. We're not trying to change
the code to make it more portable.
But at the same time try using black magic to make Postgres work on
non-POSIX systems.
What's the point now support the MSVC?
Thanks.
--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jan 27, 2016 at 9:30 PM, Yury Zhuravlev wrote:
What's the point now support the MSVC?
Many companies use it, including mine, and likely EDB.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Yury Zhuravlev wrote:
If so many problems with MSVC can discard his support of Postgres?
That doesn't sound likely. Keep in mind that users might want to
compile extension modules, and not everyone is going to use mingw for
that. As far as I know, stuff compiled with MSVC is not compatible with
mingw compiled objects. So even if the main packages switched to
compiling with mingw, we'd probably still want to support MSVC.
Under windows we can use MinGW64/Msys or LLVM/Clang for MSVC.
I'm guessing that LLVM/Clang port would be useful for something, but I'm
not clear what.
Are we moving forward with the CMake stuff? It would be *awesome* to
get rid of the MSVC build scripts, and perhaps we can move forward on
some smaller items such as PGDLLEXPORT markings as well.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, 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
On 27 January 2016 at 20:54, Alvaro Herrera <alvherre@2ndquadrant.com>
wrote:
If so many problems with MSVC can discard his support of Postgres?
I strongly disagree. MSVC is a high quality compiler and the primary tool
for the platform. Yes, it's behind on standards support and that's annoying
- OTOH MinGW relies on reverse-engineered headers, an old gcc fork, and
has had some pretty nasty bugs.
It's a bit like saying we should drop gcc support on Linux and use icc or
clang because it's more convenient for us.
Every platform has warts. We're just more used to ignoring warts on
!windows.
That doesn't sound likely. Keep in mind that users might want to
compile extension modules, and not everyone is going to use mingw for
that. As far as I know, stuff compiled with MSVC is not compatible with
mingw compiled objects. So even if the main packages switched to
compiling with mingw, we'd probably still want to support MSVC.
They are compatible. You can use mingw modules in a MSVC-built postgres.
The other way around should work too.
The main reason why is that on Windows you are expected to be very careful
about your C library, always free()ing memory in the same module (DLL/EXE)
you malloc() it in. Same rules with file handles, etc. This is required to
work correctly with modules compiled with a mix of MSVC versions or mix of
debug and release MSVC runtimes. The same principle applies to MinGW.
Under windows we can use MinGW64/Msys or LLVM/Clang for MSVC.
I'm guessing that LLVM/Clang port would be useful for something, but I'm
not clear what.Are we moving forward with the CMake stuff? It would be *awesome* to
get rid of the MSVC build scripts, and perhaps we can move forward on
some smaller items such as PGDLLEXPORT markings as well.
Yeah, strongly agree there.
CMake has excellent MSVC support btw.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 2016-01-27 21:05:06 +0800, Craig Ringer wrote:
On 27 January 2016 at 20:54, Alvaro Herrera <alvherre@2ndquadrant.com>
wrote:
If so many problems with MSVC can discard his support of Postgres?
I strongly disagree. MSVC is a high quality compiler and the primary tool
for the platform.
I think it's pretty obvious that we're not going to do that, so let's
drop that specific topic.
Yes, it's behind on standards support and that's annoying
They're fixing that largely btw.
- OTOH MinGW relies on reverse-engineered headers, an old gcc fork, and
has had some pretty nasty bugs.
I think that's also mostly fixed with mingw64 et al.
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Michael Paquier wrote:
Many companies use it, including mine, and likely EDB.
Ok, why? I wonder why it is?
--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
So even if the main packages switched to
compiling with mingw, we'd probably still want to support MSVC.
MinGV more accessible. We can always say that after the release of X is not
supported by the MSVC.
I do not propose to abandon the MSVC but its use to be justified.
Are we moving forward with the CMake stuff? It would be *awesome* to
get rid of the MSVC build scripts, and perhaps we can move forward on
some smaller items such as PGDLLEXPORT markings as well.
Linux build done with installcheck tests. We testing this under CentOS7,
Debian8, Gentoo, Ubuntu.
MSVC build 50% done. Yesterday made the work of the gendef.pl under CMake.
Current issues:
https://github.com/stalkerg/postgres_cmake/issues
--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Craig Ringer wrote:
Yeah, strongly agree there.
CMake has excellent MSVC support btw.
Yes... but I found only hack way for call gendef.pl in pre_link stage (get
objects folder name). CMake suggests that we use for normal MSVC ways to
create dll.
OTOH MinGW relies on reverse-engineered headers, an old gcc fork, and has had some pretty nasty bugs.
You about MinGW or MinGW64?
--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Craig Ringer wrote:
I strongly disagree. MSVC is a high quality compiler and the
primary tool for the platform.
Ok. And we not suport MSVC2015 now. Either we support the platform normally
or throwing it.
Now it all looks like a zombie.
--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jan 28, 2016 at 8:51 PM, Yury Zhuravlev
<u.zhuravlev@postgrespro.ru> wrote:
Craig Ringer wrote:
I strongly disagree. MSVC is a high quality compiler and the primary tool
for the platform.Ok. And we not suport MSVC2015 now. Either we support the platform normally
or throwing it. Now it all looks like a zombie.
Well, 2015 is not making things easy visibly by not providing direct
ways to get locale information.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Michael Paquier wrote:
Well, 2015 is not making things easy visibly by not providing direct
ways to get locale information.
pgwin32_putenv broken too...
--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers