Chun-Wei: I looked at ATK 2.14 sources and didn't find any variables exported with ATK_AVAILABLE_IN_ALL, only functions. So it would seem ATK has no problems by virtue of not actually exporting any data.
I then looked at Glib 2.42 sources and found quite a few exported variables but they are all exported with GLIB_VAR. As you said for ATK_VAR, GLIB_VAR also correctly varies between dllexport and dllimport depending on whether the header is being used to compile glib.dll or in an application consuming it. So it would seem Glib doesn't have a problem either. -Arnav On Fri, Sep 26, 2014 at 7:36 PM, John Ralls <jra...@ceridwen.us> wrote: > > On Sep 26, 2014, at 7:17 PM, Fan Chun-wei <fanc...@yahoo.com.tw> wrote: > > 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. > > > Sounds like something that should be in GLib, G_EXTERN. Oddly, there isn't > one already. > > Regards, > John Ralls > >
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
