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
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
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
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: [Help] Error when Glib cross compiled without the support of "_POSIX_THREADS"
hi, On Thu, Sep 25, 2014, at 02:29, Lele MA wrote: > Does it mean the system doesn't define "_POSIX_THREADS"? > If so, can I still use the glib in the Mini-OS without the support of > "_POSIX_THREADS"? Without knowing too much about this MiniOS: GLib has a hard dependency on POSIX threads. It is not possible to build GLib without threading support. If MiniOS lacks threads, then you will not be able to use GLib there, without substantial modification. I hope this helps to clarify things. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re:[Help] Error when Glib cross compiled without the support of "_POSIX_THREADS"
Hi all,
I simply comment the line "#include" in glib.h and
it goes well. It seems it can include the head file successfully.
But when I write some simple codes use the glib:
//main.c
#include
gint i, rc;
GHashTable *h;
h = g_hash_table_new (NULL, NULL);
it yields " undefined reference to `g_hash_table_new' ". It can find the
'GHashTable' definition but cannot find the 'g_hash_table_new', where all of
them are included indirectly in .
Have you anyone come across similar error when cross compiling the glib?
Lele Ma
在 2014-09-25 14:29:11，"Lele MA" 写道：
Hi all,
I am trying to cross compile Glib into xen stubdom (based on Mini-OS), which
has only the libc support from newlib. The cross root directory is
'/cross-root-x86_64/x86_64-xen-elf/'
I add the 'cross-glib' target in Makefile and the cross compile and install is
succeed. The Makefile rules like this:
TARGET_CPPFLAGS += -isystem
$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include/glib-2.0
TARGET_CPPFLAGS += -isystem
$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib/glib-2.0/include
.PHONY: cross-glib
cross-glib: glib-$(GLIB_VERSION) $(NEWLIB_STAMPFILE)
( cd $< && \
CC_FOR_TARGET="$(CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS)"
./configure --prefix=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf --verbose
--host=$(GNU_TARGET_ARCH)-xen-elf && \
$(MAKE) DESTDIR= && \
$(MAKE) DESTDIR= install )
Then I write programs to include , like this:
//file: main.c
#include
#include
#include
int main(void) {
sleep(2);
printf("Hello, world!\n");
return 0;
}
But when cross compiled, it yields:
cross-root-x86_64/x86_64-xen-elf/include/glib-2.0/glib/deprecated/gthread.h:162:5:
error: unknown type name ‘pthread_t’
make[1]: *** [main.o] Error 1
I find pthread_t is defined in , which is included in 'pthread.h':
#if defined(_POSIX_THREADS)
#include
#include
#include
Does it mean the system doesn't define "_POSIX_THREADS"?
If so, can I still use the glib in the Mini-OS without the support of
"_POSIX_THREADS"?
Any advice will be appreciated!
Lele Ma
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
