DLL export with mingw-w64: currently a no-op
Hi PostgreSQL Hackers,
When compiling PG with mingw-w64 the PGDLLEXPORT macro is blank.
Here is a patch that "fixes it for me." If this is correct, I'd
appreciate it will be applied to 9.0.x as well as HEAD.
--
Johann Oskarsson http://www.2ndquadrant.com/ |[]
PostgreSQL Development, 24x7 Support, Training and Services --+--
|
Blog: http://my.opera.com/myrkraverk/blog/
Attachments:
pg_dllexport.patchapplication/octet-stream; name=pg_dllexport.patchDownload
diff --git a/src/include/port/win32.h b/src/include/port/win32.h
index 5d41fd3..c5ba5e0 100644
--- a/src/include/port/win32.h
+++ b/src/include/port/win32.h
@@ -78,8 +78,8 @@
#define PGDLLIMPORT __declspec (dllimport)
#endif
-#ifdef _MSC_VER
-#define PGDLLEXPORT __declspec (dllexport)
+#if defined _MSC_VER || defined __MINGW64__
+#define PGDLLEXPORT __declspec (dllexport)
#else
#define PGDLLEXPORT
#endif
On 05/03/2011 02:46 AM, Johann 'Myrkraverk' Oskarsson wrote:
Hi PostgreSQL Hackers,
When compiling PG with mingw-w64 the PGDLLEXPORT macro is blank.
Here is a patch that "fixes it for me." If this is correct, I'd
appreciate it will be applied to 9.0.x as well as HEAD.
AFAICT it's not broken and doesn't need fixing. We don't define this for
the 32 bit MinGW compiler, so why should it be necessary in the 64 bit case?
The buildfarm member pitta builds Postgres and runs a full test suite
with mingw-w64 quite happily without this.
Messing with this setting has broken things badly in the past, so I
think we'd need plenty of evidence that a) it's necessary and b) it's
safe to do so. So far we have neither.
cheers
andrew
On Tue, 03 May 2011 09:32:29 -0000, Andrew Dunstan <andrew@dunslane.net>
wrote:
On 05/03/2011 02:46 AM, Johann 'Myrkraverk' Oskarsson wrote:
When compiling PG with mingw-w64 the PGDLLEXPORT macro is blank.
Here is a patch that "fixes it for me." If this is correct, I'd
appreciate it will be applied to 9.0.x as well as HEAD.AFAICT it's not broken and doesn't need fixing. We don't define this for
the 32 bit MinGW compiler, so why should it be necessary in the 64 bit
case?
I am using a different build procedure for 64bit than 32bit, as adviced
by the mingw-w64 team. The final step I use is:
${CC} -shared -o ${plugin} ${OBJS} ${BE_DLLLIBS} -L. -ljvm
I guess that is my "issue." Without __declspec(dllexport) in the magic
macro Pg_magic_func() isn't exported properly because of that, for ex-
ample.
Now while I can only blame myself for using something different/un-
supported, I have to ask, why was I told to use gcc in the final
link step by the mingw-w64 team while you (postgres) use something
else (I presume dlltool)?
--
Johann Oskarsson http://www.2ndquadrant.com/ |[]
PostgreSQL Development, 24x7 Support, Training and Services --+--
|
Blog: http://my.opera.com/myrkraverk/blog/
On 05/03/2011 06:45 AM, Johann 'Myrkraverk' Oskarsson wrote:
On Tue, 03 May 2011 09:32:29 -0000, Andrew Dunstan
<andrew@dunslane.net> wrote:On 05/03/2011 02:46 AM, Johann 'Myrkraverk' Oskarsson wrote:
When compiling PG with mingw-w64 the PGDLLEXPORT macro is blank.
Here is a patch that "fixes it for me." If this is correct, I'd
appreciate it will be applied to 9.0.x as well as HEAD.AFAICT it's not broken and doesn't need fixing. We don't define this
for the 32 bit MinGW compiler, so why should it be necessary in the
64 bit case?I am using a different build procedure for 64bit than 32bit, as adviced
by the mingw-w64 team. The final step I use is:
${CC} -shared -o ${plugin} ${OBJS} ${BE_DLLLIBS} -L. -ljvmI guess that is my "issue." Without __declspec(dllexport) in the magic
macro Pg_magic_func() isn't exported properly because of that, for ex-
ample.Now while I can only blame myself for using something different/un-
supported, I have to ask, why was I told to use gcc in the final
link step by the mingw-w64 team while you (postgres) use something
else (I presume dlltool)?
Our Makefiles use dlltool and dllwrap to create DLLs. If you used our
recommended build method pgxs would do lots of the work for you.
I'm not sure why you asked the mingw-w64 team about building a Postgres
extension - they are unlikely to know anything much about our build system.
cheers
andrew
On Tue, 03 May 2011 12:40:28 -0000, Andrew Dunstan <andrew@dunslane.net>
wrote:
Our Makefiles use dlltool and dllwrap to create DLLs. If you used our
recommended build method pgxs would do lots of the work for you.I'm not sure why you asked the mingw-w64 team about building a Postgres
extension - they are unlikely to know anything much about our build
system.
However, they do know about the mingw build tools. In particular, from:
http://oldwiki.mingw.org/index.php/dllwrap
"dllwrap is a tool to build DLLs. It seems to be deprecated in favour of
gcc -shared option, but some projects still use it. SQLite, for example."
Armed with this information, it may be prudent review the DLL build
process in PGXS.
For the record: I originally asked the mingw-w64 team for help to link
against the 64bit JVM.DLL for which there was no corresponding .def file.
--
Johann Oskarsson http://www.2ndquadrant.com/ |[]
PostgreSQL Development, 24x7 Support, Training and Services --+--
|
Blog: http://my.opera.com/myrkraverk/blog/
On 05/04/2011 01:25 AM, Johann 'Myrkraverk' Oskarsson wrote:
On Tue, 03 May 2011 12:40:28 -0000, Andrew Dunstan
<andrew@dunslane.net> wrote:Our Makefiles use dlltool and dllwrap to create DLLs. If you used our
recommended build method pgxs would do lots of the work for you.I'm not sure why you asked the mingw-w64 team about building a
Postgres extension - they are unlikely to know anything much about
our build system.However, they do know about the mingw build tools. In particular, from:
http://oldwiki.mingw.org/index.php/dllwrap"dllwrap is a tool to build DLLs. It seems to be deprecated in favour of
gcc -shared option, but some projects still use it. SQLite, for example."Armed with this information, it may be prudent review the DLL build
process in PGXS.For the record: I originally asked the mingw-w64 team for help to link
against the 64bit JVM.DLL for which there was no corresponding .def file.Google cache:
OK, but if we want to get rid of using dllwrap we'd need a complete
patch for it. Just changing the definition of the macro without changing
the rest isn't going to cut it, I think. But it might well be worth doing.
cheers
andrew
On Wed, 04 May 2011 15:11:57 -0000, Andrew Dunstan <andrew@dunslane.net>
wrote:
On 05/04/2011 01:25 AM, Johann 'Myrkraverk' Oskarsson wrote:
On Tue, 03 May 2011 12:40:28 -0000, Andrew Dunstan
<andrew@dunslane.net> wrote:Our Makefiles use dlltool and dllwrap to create DLLs. If you used our
recommended build method pgxs would do lots of the work for you."dllwrap is a tool to build DLLs. It seems to be deprecated in favour of
gcc -shared option, but some projects still use it. SQLite, for
example."Armed with this information, it may be prudent review the DLL build
process in PGXS.OK, but if we want to get rid of using dllwrap we'd need a complete
patch for it. Just changing the definition of the macro without changing
the rest isn't going to cut it, I think. But it might well be worth
doing.
You're right. And now that I know a little bit more about how to build
DLLs
and what's involved I can take a look at this, sometime in the not-too-
distant future.
Until next time, have fun!
--
Johann Oskarsson http://www.2ndquadrant.com/ |[]
PostgreSQL Development, 24x7 Support, Training and Services --+--
|
Blog: http://my.opera.com/myrkraverk/blog/