Обсуждение: 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
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
and
(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 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
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 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
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
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
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.
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
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
> 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
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
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
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
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