Re: [HACKERS] DLL export with mingw-w64: currently a no-op
On 05/04/2011 01:25 AM, Johann 'Myrkraverk' Oskarsson wrote: On Tue, 03 May 2011 12:40:28 -, Andrew Dunstan and...@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: http://webcache.googleusercontent.com/search?q=cache:tZkweT_cNQQJ:oldwiki.mingw.org/index.php/dllwrap+mingw+dllwrapcd=1hl=isct=clnkgl=isclient=operasource=www.google.is 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] DLL export with mingw-w64: currently a no-op
On Wed, 04 May 2011 15:11:57 -, Andrew Dunstan and...@dunslane.net wrote: On 05/04/2011 01:25 AM, Johann 'Myrkraverk' Oskarsson wrote: On Tue, 03 May 2011 12:40:28 -, Andrew Dunstan and...@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 Oskarssonhttp://www.2ndquadrant.com/|[] PostgreSQL Development, 24x7 Support, Training and Services --+-- | Blog: http://my.opera.com/myrkraverk/blog/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] DLL export with mingw-w64: currently a no-op
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] DLL export with mingw-w64: currently a no-op
On Tue, 03 May 2011 09:32:29 -, Andrew Dunstan and...@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 Oskarssonhttp://www.2ndquadrant.com/|[]
PostgreSQL Development, 24x7 Support, Training and Services --+--
|
Blog: http://my.opera.com/myrkraverk/blog/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] DLL export with mingw-w64: currently a no-op
On 05/03/2011 06:45 AM, Johann 'Myrkraverk' Oskarsson wrote:
On Tue, 03 May 2011 09:32:29 -, Andrew Dunstan
and...@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)?
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] DLL export with mingw-w64: currently a no-op
On Tue, 03 May 2011 12:40:28 -, Andrew Dunstan and...@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: http://webcache.googleusercontent.com/search?q=cache:tZkweT_cNQQJ:oldwiki.mingw.org/index.php/dllwrap+mingw+dllwrapcd=1hl=isct=clnkgl=isclient=operasource=www.google.is -- Johann Oskarssonhttp://www.2ndquadrant.com/|[] PostgreSQL Development, 24x7 Support, Training and Services --+-- | Blog: http://my.opera.com/myrkraverk/blog/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
