Hi, This situation would have been hit by GLib and GTK+, if not done properly, as they use things like _GLIB_EXTERN (for glib, gobject, gio) and _GDK_EXTERN (for GDK, gtk) and they also export public variables (data)--but they build and link just fine. In fact the work on using __declspec(dllexport) for ATK is modeled on them. There is a ATK_VAR macro that is used to export (and import using __declspec(dllimport) the public variables, for example, and similar macros are used in GLib and GTK+, since the days of using .symbols/.def files. It might be worth it to see whether we can use __declspec(dllimport) for the functions as well for better efficiency, though, but this would be something we can look into a bit later. For the -mm libraries though, I think it might be good if we use dllimport and dllexport all around, rather than using gendef that makes use of dumpbin, as many other symbols are exported unnecessarily during the process. With blessings. |
| (I haven't looked at the headers in question myself). If I'm understanding the situation correctly, you're building a binary that includes an atk(mm) header that has some functions marked with dllexport (from the POV of the compiler when it's compiling your code). >Technically though, I don't know if a similar issue will arise from declaring dllexport when we meant to use dllimport. It might produce the same problem - or a different problem - or no problem at all. The attribute to be ignored and the function won't be re-exported from your binary, since your binary doesn't provide a definition for it to the linker. However, as you discovered... >At the end of last year I discovered that some very obscure problems can arise if we try to import symbols from a DLL without using '__declspec(dllimport)'. That is correct, and is mentioned in MSDN [1] and also explained in this answer on StackOverflow [2]. It's sub-optimal to not use dllimport for functions and outright incorrect to not use it for data. As I said above, the dllexport parameter will be ignored, which means the item gets treated as if no attribute was specified. So if there is data marked as dllexport in the atk(mm) header then it will be handled incorrectly by any binary that uses that header. [1] http://msdn.microsoft.com/en-us/library/8fskxacy.aspx >Using __declspec(dllimport) is optional on function declarations, but the compiler produces more efficient code if you use this keyword. However, you must use __declspec(dllimport) for the importing executable to access the DLL's public data symbols and objects. [2] http://stackoverflow.com/a/4490536 See also the linked blog post. -Arnav On Fri, Sep 26, 2014 at 12:01 PM, John Emmas <johne53 tiscali co uk> wrote: > On 26/09/2014 11:51, John Emmas wrote: >> >> >>> Also, since my last post I've discovered why atkmm was also failing to >>> build [...] Now that I'm managing to generate those files correctly again, >>> everything's now building fine. >> >> > > Oh, one more thing, before I forget it.... > > I think I'm right in saying that, for Windows, ATK_AVAILABLE_IN_ALL can only > be defined as either 'extern' or '__declspec (dllexport) extern'. This > might cause problems with the fact that libatkmm is routinely #including > 'atk-enum-types.h'. When building atkmm, the symbols declared inside > atk-enum-types.h will be wrongly defined as exported symbols when they > should be defined as imported. When importing for use by some other > library, they should really be defined as '__declspec (dllimport)'. > > At the end of last year I discovered that some very obscure problems can > arise if we try to import symbols from a DLL without using > '__declspec(dllimport)'. Here's my description from the time:- > > https://mail.gnome.org/archives/gtkmm-list/2013-December/msg00002.html > > To be fair, that specific problem was caused by not having any import > specifier at all (and it only affected imported data - not imported > functions). Technically though, I don't know if a similar issue will arise > from declaring dllexport when we meant to use dllimport. It might produce > the same problem - or a different problem - or no problem at all. I > genuinely don't know - but it's always better to be safe, rather than > sorry!! > > I know that Fan Chun-wei is hoping to look into this soon for libatkmm but > it probably needs tidying up in libatk too. Hopefully, someone can find some > time to give it some thought.... Best regards, > > John > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list gnome org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list _______________________________________________ gtk-devel-list mailing list gtk-devel-list gnome org https://mail.gnome.org/mailman/listinfo/gtk-devel-list |