linking / performance / interposing detection ...

[michael meeks <michael meeks novell com>]

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.

-- 
 michael meeks novell com  <><, 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