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
