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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]