Hi guys,
So - as part of my -Bdirect work - trying to detect genuine cases of
interposing - I ran my simple perl script over all my gnome libraries:
http://go-oo.org/ooo-build/bin/finterpose (for which I attach the gnome
specific exclusions file [this incidentally shows lots of other bad
behavior in Gnome ;-]):
$ find /opt/gnome/lib -name '*.so' | finterpose ./gnome-exlusions
I got some rather concerning output wrt. gtk+ theme engines eg.
gtk-2.0/2.4.0/engines/libmetal.so exports 'parent_class'
Also - the galloping cut/paste common in theme engine authorship seems
to have resulted in at least these symbols being duplicated across tons
of theme engines:
option_menu_get_props is_combo_box find_combo_box_widget
get_parent_window reverse_engineer_stepper_box theme_create_rc_style
theme_pixbuf_render theme_pixbuf_set_border theme_pixbuf_set_filename
theme_pixbuf_set_stretch theme_pixbuf_destroy theme_pixbuf_new
theme_pixbuf_get_pixbuf is_combo_box_entry object_is_a
combo_box_is_using_list theme_destroy_style theme_realize_style
theme_destroy_rc_style theme_unrealize_style theme_set_background
theme_parse_rc_style theme_merge_rc_style theme_duplicate_style
theme_rc_style_to_style theme_init theme_exit old_vscrollbar_realize
old_hscrollbar_slider_update old_vscrollbar_slider_update
old_hscrollbar_realize old_hpaned_realize old_vpaned_realize
sanitize_parameters is_in_combo_box is_combo is_toolbar_item
is_panel_widget_item old_scrolled_window_map
old_scrolled_window_size_allocate step_vscrollbar_parent_set
So - I guess, this shouldn't be -that- concerning in some ways - but
looking further - it *seems* that the loading of themes is done in such
a way as to include them in the global symbol search path:
gtk/gtkthemes.c:
engine->library = g_module_open (engine_path, 0);
Q1: is it possible to have 2 gtk themes loaded concurrently ? and if so
- why don't we see hideous problems wrt. 'theme_init' being looked up
incorrectly in the 2nd theme ?
Q2: -why- are we routinely loading all these nice separated plugin
libraries into the global symbol search scope ?
$ LD_BINDINGS=symbol gtk-demo
on my machine shows:
16350: symbol=__gmon_start__; lookup in
file=.../gtk-2.0/2.4.0/loaders/libpixbufloader-gif.so
16350: symbol=__gmon_start__; lookup in
file=.../gtk-2.0/2.4.0/engines/libindustrial.so
16350: symbol=__gmon_start__; lookup in
file=.../pango/1.4.0/modules/pango-basic-fc.so
Ok - so they're at the end of the list here it's true - so the effect
for gtk-demo is small; but it's easy to imagine loading other libraries,
plugins / components etc. after that [ eg. the file-selector +
deps ? ;-] and them having to search a number of extra, pointless image
loader / pango / theme engine bits per-symbol without any real need for
that ?
I guess the fix would be to use G_MODULE_BIND_LOCAL ( at least -
assuming that does the right thing ) - in all the g_module_opens - which
would surely be a fairly painless change / patch ?
HTH,
Michael.
--
[EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot
# glib / gtk modules:
g_module_check_init
gtk_module_init
im_module_init
im_module_create
im_module_list
im_module_exit
# gconf
gconf_backend_get_vtable
# ORBit2 / bonobo
orbit_imodule_data
Bonobo_Plugin_info
# gnome-print
gnome_print__transport_get_type
gnome_print__filter_get_type
gpa_module_init
# gnome-vfs
vfs_module_init
vfs_module_shutdown
# glade
glade_module_register_widgets
# gstreamer
gst_plugin_desc
# Nautilus
nst_init_plugin
nautilus_module_shutdown
nautilus_module_list_types
nautilus_module_initialize
# gimp
gimp_module_query
gimp_module_register
# xchat modules
xchat_plugin_init
xchat_plugin_deinit
xchat_plugin_get_info
# epiphany
register_module
# gaim
gaim_init_plugin
# planner
module_init
module_exit
module_new
# a11y modules
gnome_accessibility_module_shutdown
gnome_accessibility_module_init
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
