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

[Piñeiro <apinheiro igalia com>]

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-devel 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