Re: atk 'missing symbols' problem since gnome-3-14
On 26 Sep 2014, at 23:33, Arnavion wrote: 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). [...] 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. Yes, that just about summarises the situation. I first discovered this happening in gtkmm (class Gtk::SpinButton) - but during my investigations I realised that the same anomaly might (potentially) be present in the other mm libraries (particularly so in giomm and atkmm). There isn't necessarily a problem right at this moment. It's more the case that there's a problem waiting to happen. FWIW I also noticed that libatk defines ATK_VAR for dealing with data, as opposed to functions. That should help to avoid the data issue but like you said Arnavion, function handling is currently sub-optimal (although it doesn't seem like a massive job to fix it). I'm just flagging the situation up really. It could probably benefit from being tidied up at some stage but it's not something which needs 'imminent' attention... John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: atk 'missing symbols' problem since gnome-3-14
Many thanks for those suggestions guys. It didn't quite fix the problem but it did point me in the right direction. Here's what I've found so far The top of the (auto-generated) file 'atk-enum-types.c' currently looks like this:- /* Generated data (by glib-mkenums) */ #include atk.h I needed to change it to this for atk-2.14 to build correctly:- /* Generated data (by glib-mkenums) */ #include config.h // --- I needed to add this line !! #include atk.h Without that extra line, _ATK_EXTERN is simply defined as 'extern' when it needs to be '__declspec (dllexport) extern'. Adding that extra line fixes the problem whereby the built DLL wasn't exporting those particular symbols - BUT... Unfortunately, quite a few of the source files in atkmm seem to #include atk/atk-enum-types.h directly. In most cases it doesn't cause any problems - but there are 3 or 4 source files from atkmm which refuse to compile now with that extra line added. I'll keep plugging away and see if I can find out why. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: atk 'missing symbols' problem since gnome-3-14
Hi, On 09/26/2014 11:42 AM, John Emmas wrote: Many thanks for those suggestions guys. It didn't quite fix the problem but it did point me in the right direction. Here's what I've found so far The top of the (auto-generated) file 'atk-enum-types.c' currently looks like this:- /* Generated data (by glib-mkenums) */ Well, in fact this comment is missing, probably it would be good to add it. #include atk.h I needed to change it to this for atk-2.14 to build correctly:- /* Generated data (by glib-mkenums) */ #include config.h // --- I needed to add this line !! Well, this line is being included when I build atk. And looking at the 2.14.0 release (the one that is causing problems) tarball: https://download.gnome.org/sources/atk/2.14/atk-2.14.0.tar.xz That include to config.h is also there. From your first email, you mention that you build from git. Could you try to do the same with the tarball? BR -- Alejandro Piñeiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: atk 'missing symbols' problem since gnome-3-14
On 26/09/2014 11:03, Piñeiro wrote: On 09/26/2014 11:42 AM, John Emmas wrote: #include config.h // --- I needed to add this line !! Well, this line is being included when I build atk. And looking at the 2.14.0 release Oops, you're absolutely right. The version in 2.14.0 does already have that line. I must have checked the wrong copy... :-( Also, since my last post I've discovered why atkmm was also failing to build (once again, it was just a problem with my auto-generated atk-enum-types.h). Now that I'm managing to generate those files correctly again, everything's now building fine. Thanks for all your help with this. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: atk 'missing symbols' problem since gnome-3-14
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/msg2.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
Re: atk 'missing symbols' problem since gnome-3-14
(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 john...@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/msg2.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
回覆﹕ Re: atk 'missing symbols' problem since gnome-3-14
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.___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: atk 'missing symbols' problem since gnome-3-14
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
atk 'missing symbols' problem since gnome-3-14
Is this a suitable place for flagging up problems with libatk? Do please let me know if it has a dedicated mailing list somewhere. I couldn't find one. In the meantime I've been building libatk (with MSVC) for many years. I build from the sources in Git and typically, I synchronize with whichever branch is the current stable branch (until very recently, this was gnome-3-12 in the case of libatk). Then (a few days ago) gnome-3-14 got released as the new stable branch. Since then, I can't seem to build it properly with MSVC. Technically, it does actually build - but the following symbols seem to be missing now from the built DLL:- atk_coord_type_get_type atk_layer_get_type atk_role_get_type atk_relation_type_get_type atk_state_type_get_type atk_text_attribute_get_type atk_text_boundary_get_type atk_text_clip_type_get_type There may be others too - but those are the immediately obvious ones. Version 2.12 (i.e. gnome-3-12) used to generate a module definition for the linker (which helpfully contained the above symbols) but version 2.14 (gnome-3-14) doesn't use any module definition file AFAICT. And unless I'm missing something, the above symbols have nothing to mark them as dllexport. Nevertheless, they get called from atkmm (and hence, MSVC complains that it can't find them). It's possible that something's gone awry at my end but I just wondered if this is known about? Thanks. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: atk 'missing symbols' problem since gnome-3-14
Hello John, I was able to get these symbols from the atk-2.14.0 release tarball from the GNOME FTP, and was able to build atkmm without any problems. Probably you will need to look at your atk/atk-enum-types.h and atk/atk-enum-types.c-these symbols are indeed annotated in atk-enum-types.h, which is a generated file that is generated by glib-mkenums.h and included in the release tarball during 'make dist'. You can either: -Re-generate atk-enum-types.h/atk-enum-types.c by deducing the process from atk/Makefile.am Notice that that rule changed a bit during the last dev cycle because we are using __declspec (dllexport) -Grab the atk-2.14.0 tarball which contains atk-enum-types.h and atk-enum-types.c which the correct decorations -Edi atk-enum-types.h to include config.h before everything else, and put a ATK_AVAILABLE_IN_ALL before the prototypes in atk-enum-types.h Then re-do your build. These symbols should be exported then. Hope this helps, with blessings. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: atk 'missing symbols' problem since gnome-3-14
Hello John, Sorry for the bunch of bad english and info here (late night reply here for me): -glib-mkenums.h should read glib-mkenums (which is a PERL script) -Edi atk-enum-types.h to include config.h... should read Edit atk-enum-types.c to include config.h... -put a ATK_AVAILABLE_IN_ALL should be put ATK_AVAILABLE_IN_ALL Please make sure your config.h(.win32) is up-to-date, as _ATK_EXTERN is defined in there to do the __declspec(dllexport) work. With blessings. Fan Chun-wei 於 2014/9/26 01:38 寫道: Hello John, I was able to get these symbols from the atk-2.14.0 release tarball from the GNOME FTP, and was able to build atkmm without any problems. Probably you will need to look at your atk/atk-enum-types.h and atk/atk-enum-types.c-these symbols are indeed annotated in atk-enum-types.h, which is a generated file that is generated by glib-mkenums.h and included in the release tarball during 'make dist'. You can either: -Re-generate atk-enum-types.h/atk-enum-types.c by deducing the process from atk/Makefile.am Notice that that rule changed a bit during the last dev cycle because we are using __declspec (dllexport) -Grab the atk-2.14.0 tarball which contains atk-enum-types.h and atk-enum-types.c which the correct decorations -Edi atk-enum-types.h to include config.h before everything else, and put a ATK_AVAILABLE_IN_ALL before the prototypes in atk-enum-types.h Then re-do your build. These symbols should be exported then. Hope this helps, with blessings. ___ 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
Re: atk 'missing symbols' problem since gnome-3-14
On 09/25/2014 04:42 PM, John Emmas wrote: Is this a suitable place for flagging up problems with libatk? Do please let me know if it has a dedicated mailing list somewhere. As atk is an accessibility module, usually this is discussed on gnome-accessibility-de...@gnome.org. There is not enough traffic to justify specific atk, at-spi2, etc mailing lists. I couldn't find one. In the meantime I don't think that people would mind to talk about this here. I've been building libatk (with MSVC) for many years. I build from the sources in Git and typically, I synchronize with whichever branch is the current stable branch (until very recently, this was gnome-3-12 in the case of libatk). Then (a few days ago) gnome-3-14 got released as the new stable branch. Since then, I can't seem to build it properly with MSVC. Technically, it does actually build - but the following symbols seem to be missing now from the built DLL:- atk_coord_type_get_type atk_layer_get_type atk_role_get_type atk_relation_type_get_type atk_state_type_get_type atk_text_attribute_get_type atk_text_boundary_get_type atk_text_clip_type_get_type There may be others too - but those are the immediately obvious ones. Version 2.12 (i.e. gnome-3-12) used to generate a module definition for the linker (which helpfully contained the above symbols) but version 2.14 (gnome-3-14) doesn't use any module definition file AFAICT. Yes, it was a change done during this cycle (at the beginning). This was the bug: https://bugzilla.gnome.org/show_bug.cgi?id=728031 One of the advantages (among others) was that we didn't need to manually maintain the .symbols file (error prone). The other advantage is that we were more aligned to what gtk and clutter were doing. And unless I'm missing something, the above symbols have nothing to mark them as dllexport. Those symbols are already marked as any other symbol (ATK_AVAILABLE_IN_XXX). And symbols like them (enum based) are also treated in the same way on gtk. Not sure why is just a problem with atk. Nevertheless, they get called from atkmm (and hence, MSVC complains that it can't find them). It's possible that something's gone awry at my end but I just wondered if this is known about? Thanks. I don't have too much experience with MSVC, CCing Chun-wei Fan, that has more experience with MSVC, and did this work. BR -- Alejandro Piñeiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
