Thread: 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/
Attachment
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
andServices --+-- | 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. -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
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: http://webcache.googleusercontent.com/search?q=cache:tZkweT_cNQQJ:oldwiki.mingw.org/index.php/dllwrap+mingw+dllwrap&cd=1&hl=is&ct=clnk&gl=is&client=opera&source=www.google.is -- Johann Oskarsson http://www.2ndquadrant.com/ |[] PostgreSQL Development, 24x7 Support, Training andServices --+-- | 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: > > http://webcache.googleusercontent.com/search?q=cache:tZkweT_cNQQJ:oldwiki.mingw.org/index.php/dllwrap+mingw+dllwrap&cd=1&hl=is&ct=clnk&gl=is&client=opera&source=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
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 andServices --+-- | Blog: http://my.opera.com/myrkraverk/blog/