I compiled now with gmodule-export-2.0.pc the symbols get exported: nm -g build/src/ajami | grep '_get_type' [...] 0000000000429b30 T hv_meter_get_type
but when I try to launch I get the same error: (ajami:30289): Gtk-CRITICAL **: Error building template class 'AjamiMainWindow' for an instance of type 'AjamiMainWindow': Invalid object type 'HVMeter' on line 2 Thanks ;) 2015-10-04 6:56 GMT-03:00 Tristan Van Berkom <tris...@upstairslabs.com>: > On Sat, Oct 3, 2015 at 10:14 AM, Victor Aurélio Santos > <victoraur.san...@gmail.com> wrote: >> >> How can I do that ? >> Just build all together results in this warning: >> >>> (ajami:3475): Gtk-CRITICAL **: Error building template class >>> 'AjamiMainWindow' for an instance of type 'AjamiMainWindow': Invalid object >>> type 'HVMeter' on line 2 >> >> >> I've asked on SO[1] and got only one answer. >> >> I stick at "_get_type" workaround/hack but I didn't like it and I >> can't do the same thing in Vala (I've not found how to do the same >> thing). > > > > Hello Victor, > > The regular way to do this is in fact to compile your app with > gmodule-export-2.0.pc > > I.e. adding `pkg-config --libs gmodule-export-2.0` to your link stage (using > autotools you > would just add gmodule-export-2.0 to your regular pkg-config m4 macro > invocations). > > This indeed makes your applications global symbols visible so that they can > be found using dlsym() on unices and other methods on other platforms. > > Regarding the comment on the SO post, the deriving of the _get_type() > function by the type name is not considered a heuristic but rather it is a > standard, which is at least enforced in any code written in the last decade > or so by way of the G_DEFINE_TYPE() macros (vala generated types will also > comply with this standard). So, if you have a type which is named FooBar, > and it's low level GType accessor is not correctly named foo_bar_get_type(), > it is in fact the application/library code declaring the type which is at > fault for not complying with this. > > Granted, one can argument that documentation in this area is weak. Any other > methods provided in GtkBuilder (such as overridable get_type_from_name() > virtual methods) are specifically targeted at language bindings which need > to resolve the type in other ways. > > With all that said, it could be plausible to create some tooling perhaps > which parses your builder files at compile time, perhaps generating a > resource to be compiled into your app which could be automatically inspected > at gtk_init() time, to automate the process of initializing the required > types - and removing the requirement of exporting your symbols in the > regular way - that's one approach I can imagine anyway, perhaps there are > others, there would have to be interest and someone would of course have to > write that code :) > > I hope this clarifies the situation a bit more for you. > > Best, > -Tristan > > > -- Victor Aurélio Santos _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
