[Mingw-w64-public] problems with dllimport / dllexport

Post by Chris Sutcliffe
With the latest gcc/g++ I'm having issues with dllimport / dllexport.
x86_64-w64-mingw32-g++.exe (GCC) 4.5.0 20091011 (experimental)
x86_64-w64-mingw32-g++.exe (GCC) 4.5.0 20091221 (experimental)
spits out errors regarding undefined references to functions that are
dllexported from one of my shared libraries. I'm using
__declspec(dllexport) / __declspec(dllimport) to export / import the
functions, should I be using a different mechanism now?
Cheers!
Chris

Hello Chris,

I didn't noticed this change in behavior. Could you provide to me some
small testcase by which I can reproduce this?

The only thing you should be aware is, that by using shared C++ you
get linker warnings about autoimports, when you didn't specified
--enable-autoimports for linker. Did it helps if you specify option
-static?

Cheers,
Kai

--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Chris Sutcliffe

2009-12-23 12:59:18 UTC

Hi Kai,

Post by Kai Tietz
I didn't noticed this change in behavior. Could you provide to me some
small testcase by which I can reproduce this?

I'll create a simple test case over the holidays. As it stands today,
I see it with my Emerge Desktop application, but it by no means is a
simple test case.

Post by Kai Tietz
The only thing you should be aware is, that by using shared C++ you
get linker warnings about autoimports, when you didn't specified
--enable-autoimports for linker. Did it helps if you specify option
-static?

I see the C++ import warnings, and as you mentioned I addressed them
by adding -Wl,--enable-auto-import but it did not help the problem of
undefined references that I'm seeing. The issue is actually the
classes being export by Emerge Desktop's shared libraries, for
example:

../.objs64/Release/emergeTasks/Config.o:Config.cpp:(.text+0xef):
undefined reference to `_imp___ZN16BasePositionPageD1Ev'
../.objs64/Release/emergeTasks/Config.o:Config.cpp:(.text+0x11f):
undefined reference to `_imp___ZN12SchemeEditorD1Ev'
../.objs64/Release/emergeTasks/Config.o:Config.cpp:(.text+0x882):
undefined reference to
`_imp___ZN16BasePositionPageC1ENSt3tr110shared_ptrI12BaseSettingsEEj'
../.objs64/Release/emergeTasks/Config.o:Config.cpp:(.text+0x90b):
undefined reference to `_imp___ZN12SchemeEditorC1EP6HWND__'

Where BasePositionPage, SchemeEditor and BaseSettings are exported
classes from Emerge Desktop's shared libraries.

Hrm.... interestingly enough, all the undefined references I'm seeing
are from exported classes, exported functions seem to be fine.
Perhaps this is an issue with dllexport / dllimport and C++ classes?

Cheers!

Chris

--
Chris Sutcliffe
http://emergedesktop.org

Kai Tietz

2009-12-23 13:07:25 UTC

Post by Chris Sutcliffe
Hi Kai,

Post by Kai Tietz
I didn't noticed this change in behavior. Could you provide to me some
small testcase by which I can reproduce this?

I'll create a simple test case over the holidays. As it stands today,
I see it with my Emerge Desktop application, but it by no means is a
simple test case.

I see the C++ import warnings, and as you mentioned I addressed them
by adding -Wl,--enable-auto-import but it did not help the problem of
undefined references that I'm seeing. The issue is actually the
classes being export by Emerge Desktop's shared libraries, for
undefined reference to `_imp___ZN16BasePositionPageD1Ev'
undefined reference to `_imp___ZN12SchemeEditorD1Ev'
undefined reference to
`_imp___ZN16BasePositionPageC1ENSt3tr110shared_ptrI12BaseSettingsEEj'
undefined reference to `_imp___ZN12SchemeEditorC1EP6HWND__'
Where BasePositionPage, SchemeEditor and BaseSettings are exported
classes from Emerge Desktop's shared libraries.
Hrm.... interestingly enough, all the undefined references I'm seeing
are from exported classes, exported functions seem to be fine.
Perhaps this is an issue with dllexport / dllimport and C++ classes?
Cheers!
Chris
--
Chris Sutcliffe
http://emergedesktop.org
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Mingw-w64-public mailing list
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Ah, as you describe this, I am remembering, that there is a patch for
C++ FE pending (it is a bug), that the namespace should be able to
contain the dllexport/dllimport here.
So this issue is most likely related to this. Maybe generate your
import-library by using export-all? Does this help?

Cheers,
Kai

PS: Somehow it looks like that mingw.org has no real interest in
fixing the mingwm10.dll issue. But well, I tried to help.

--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Chris Sutcliffe

2009-12-23 22:41:10 UTC

Hi Kai,

Post by Kai Tietz
Ah, as you describe this, I am remembering, that there is a patch for
C++ FE pending (it is a bug), that the namespace should be able to
contain the dllexport/dllimport here.

Fair enough, hopefully the patch will make it in to mainline gcc/g++.

Post by Kai Tietz
So this issue is most likely related to this. Maybe generate your
import-library by using export-all? Does this help?

I tried -Wl,--export-all-symbols but that causes issues with the
tinyxml library I have embedded in one of the libraries. Is there a
way I can do an export-all per file?

Post by Kai Tietz
PS: Somehow it looks like that mingw.org has no real interest in
fixing the mingwm10.dll issue. But well, I tried to help.

Indeed, it really is disheartening. The person I was most hoping
would respond is Aaron, but it looks like he's MIA again.

Similar can be said for the GDB question I posted. It really seems
like there is little interest in MinGW from the rest of the mingw.org
team at this point. Is there any interest in me packaging GDB for
mingw-w32? I can take a stab at packaging it for mingw-w64 as well
(but I don't have a 64-bit machine to test it on).

Cheers!

Chris

--
Chris Sutcliffe
http://emergedesktop.org

Kai Tietz

2009-12-24 06:56:12 UTC

Hello Chris,

Post by Chris Sutcliffe
Hi Kai,

Post by Kai Tietz
Ah, as you describe this, I am remembering, that there is a patch for
C++ FE pending (it is a bug), that the namespace should be able to
contain the dllexport/dllimport here.

Fair enough, hopefully the patch will make it in to mainline gcc/g++.

Yes, if you could prepare a testcase for the scenario you have, I will
try to push a patch for this, or at least open a bug report on gcc's
bugzilla.

Post by Kai Tietz
So this issue is most likely related to this. Maybe generate your
import-library by using export-all? Does this help?

I tried -Wl,--export-all-symbols but that causes issues with the
tinyxml library I have embedded in one of the libraries. Is there a
way I can do an export-all per file?

Hmm, maybe on object level this should be possible, but it is a bit unhandy.

Post by Kai Tietz
PS: Somehow it looks like that mingw.org has no real interest in
fixing the mingwm10.dll issue. But well, I tried to help.

Indeed, it really is disheartening. The person I was most hoping
would respond is Aaron, but it looks like he's MIA again.
Similar can be said for the GDB question I posted. It really seems
like there is little interest in MinGW from the rest of the mingw.org
team at this point. Is there any interest in me packaging GDB for
mingw-w32? I can take a stab at packaging it for mingw-w64 as well
(but I don't have a 64-bit machine to test it on).

Yes, it would be good to provide a mingw-w32 version of gdb, too. In
general it would be good to have somebody taking care about regular
updates for gdb. So a mingw-w32 package would be most welcome.

Cheers,
Kai

--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Chris Sutcliffe

2009-12-24 12:28:52 UTC

Hi Kai,

Post by Kai Tietz
Ah, as you describe this, I am remembering, that there is a patch for
C++ FE pending (it is a bug), that the namespace should be able to
contain the dllexport/dllimport here.

Fair enough, hopefully the patch will make it in to mainline gcc/g++.

Yes, if you could prepare a testcase for the scenario you have, I will
try to push a patch for this, or at least open a bug report on gcc's
bugzilla.

I will create a simple test case over the holidays for this and send it to you.

Post by Chris Sutcliffe
I tried -Wl,--export-all-symbols but that causes issues with the
tinyxml library I have embedded in one of the libraries. Is there a
way I can do an export-all per file?

Hmm, maybe on object level this should be possible, but it is a bit unhandy.

I think I found a solution where I export all symbols only on the
libraries that contain exported classes. Thankfully the library with
the embedded tinyxml doesn't export any classes.

Post by Chris Sutcliffe
Similar can be said for the GDB question I posted. It really seems
like there is little interest in MinGW from the rest of the mingw.org
team at this point. Is there any interest in me packaging GDB for
mingw-w32? I can take a stab at packaging it for mingw-w64 as well
(but I don't have a 64-bit machine to test it on).

Yes, it would be good to provide a mingw-w32 version of gdb, too. In
general it would be good to have somebody taking care about regular
updates for gdb. So a mingw-w32 package would be most welcome.

Excellent, I will work on packaging GDB 7.0.1 for mingw-w32 initially.
Is there going to be an updated 1222(/23) build of mingw-w32 for
mingw or cygwin? Once I have a working mingw-w32 build, I'll see what
I can do to produce a mingw-w64 build.

Out of interest, are the Cygwin builds going to be moved to 1.7.1 now
that it's officially released? The 1.5.25 builds still work, so it's
not a big deal, I'm just curious...

Cheers!

Chris

--
Chris Sutcliffe
http://emergedesktop.org

Kai Tietz

2009-12-27 17:38:09 UTC

Post by Chris Sutcliffe
I will create a simple test case over the holidays for this and send it to you.

Thanks

Post by Chris Sutcliffe
Excellent, I will work on packaging GDB 7.0.1 for mingw-w32 initially.
Is there going to be an updated 1222(/23) build of mingw-w32 for
mingw or cygwin? Once I have a working mingw-w32 build, I'll see what
I can do to produce a mingw-w64 build.

Well, our buildbot has at the moment some troubles for cygwin/msys
builds. Mook and NightStrike are on this (I hope).

Post by Chris Sutcliffe
Out of interest, are the Cygwin builds going to be moved to 1.7.1 now
that it's officially released? The 1.5.25 builds still work, so it's
not a big deal, I'm just curious...

Well, at the moment our cygwin slave is a 1.5 version. When 1.7.1 is
getting a bit more stable and reliable for x64 Windows OSes, we will
surely build for it. But as you said, our 1.5 cygwin-toolchain works
on 1.7 cygwin, too, so there is no real need in updating now.

Hope you had an Merry Christmas.

Cheers,
Kai

--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Chris Sutcliffe

2009-12-30 00:34:45 UTC

Hi Kai,

Post by Chris Sutcliffe
I will create a simple test case over the holidays for this and send it to you.

Thanks

I'm having a heck of a time recreating the issue in a simple test
case. What I see happening with Emerge is that the C++ mangled name
seems to be mismatched between the export and the import but only in
certain circumstances. For example:

../.objs/Release/emergeHotkeys/Settings.o:Settings.cpp:(.text+0x504):
undefined reference to
`__imp___ZN12BaseSettings8IOHelperC1EP12TiXmlElement'

However, looking at the symbols in the emergeBaseClasses import library:

$ nm bin/libemergeBaseClasses.a | grep IOHelper
...
00000000 I __imp___ZN12BaseSettings8IOHelperC2EP12TiXmlElement

I have no idea C2EP12TiXmlElement (in the export) becomes
C1EP12TiXmlElement (in the import). I haven't been able to recreate
it as of yet in a simple case (one exe, one dll), but I'll keep
trying.

Cheers!

Chris

--
Chris Sutcliffe
http://emergedesktop.org

NightStrike

2009-12-29 16:26:30 UTC

Chris, this is fantastic! Would you like to do nightly regression
builds on our buildbot? We have a number of host platforms we build
on.

We will eventually. We have to 1) find time to upgrade our build
machine, and 2) be confident that 1.7 is stable enough for our users.

James K Beard

2009-12-29 19:45:37 UTC

NightStrike, Mook: Let me know if Cliff needs a logon for the SSH server.

James K Beard

-----Original Message-----
From: NightStrike [mailto:***@gmail.com]
Sent: Tuesday, December 29, 2009 11:26 AM
To: Chris Sutcliffe
Cc: mingw-w64-***@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] problems with dllimport / dllexport

Chris, this is fantastic! Would you like to do nightly regression
builds on our buildbot? We have a number of host platforms we build
on.

We will eventually. We have to 1) find time to upgrade our build
machine, and 2) be confident that 1.7 is stable enough for our users.

----------------------------------------------------------------------------
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev

Chris Sutcliffe

2009-12-30 00:39:21 UTC

Hi NightStrike,

Chris, this is fantastic! Would you like to do nightly regression
builds on our buildbot? We have a number of host platforms we build
on.

That sounds excellent! Once I get things down pat building GDB for
mingw-w32 and mingw-w64 (and you guys are happy with the results),
I'll gladly work on setting things up for the buildbot.

We will eventually. We have to 1) find time to upgrade our build
machine, and 2) be confident that 1.7 is stable enough for our users.

I've been using 1.7 for quite some time, and I find it to be very
stable. I'm using the
mingw-w32-1.0-bin_i686-cygwin-1.5.25-15_20091228.tar.bz2 and
mingw-w64-1.0-bin_i686-cygwin-1.5.25-15_20091228.tar.bz2 builds under
1.7.1 with no issues, so it's not a big deal. I'd be happy to test
out 1.7 based builds for you if you like.

Cheers!

Chris

--
Chris Sutcliffe
http://emergedesktop.org

NightStrike

2009-12-30 01:59:28 UTC

Post by Chris Sutcliffe
mingw-w32-1.0-bin_i686-cygwin-1.5.25-15_20091228.tar.bz2 and
mingw-w64-1.0-bin_i686-cygwin-1.5.25-15_20091228.tar.bz2 builds under
1.7.1 with no issues, so it's not a big deal. I'd be happy to test
out 1.7 based builds for you if you like.

Could you run the testsuite on a 1.7 build for Win32?

Chris Sutcliffe

2009-12-30 03:36:05 UTC

Post by NightStrike

Could you run the testsuite on a 1.7 build for Win32?

Sure, how do I go about doing that?

Chris

--
Chris Sutcliffe
http://emergedesktop.org

NightStrike

2009-12-30 18:42:30 UTC

After you compile the toolchain under cygwin 1.7, just run make check.
I'm not sure how familiar you are with what's necessary, so I'll
touch base with you sometime next week to go over it in more details.