Re: atk 'missing symbols' problem since gnome-3-14

[Arnavion <arnavion gmail com>]

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 <jralls ceridwen us> wrote:

On Sep 26, 2014, at 7:17 PM, Fan Chun-wei <fanc999 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