g_strdup symbol conflict

[Andrei Zmievski <andrei ispi net>]

I have recently come across a problem that stems from g_strdup() symbol
conflict on certain systems. For example, On RH-7.x the imap library is
linked against kerberos, and libgssapi_krb5 defines its own g_strdup()
symbol. When a program is linked both against Gtk+ and the imap library,
a segfault happens with a backtrace similar to the following:

#0  0x40535dd3 in strlen () from /lib/i686/libc.so.6
#1  0x40438c31 in g_strdup () from /usr/kerberos/lib/libgssapi_krb5.so.2
#2  0x40872752 in g_get_any_init () at gutils.c:423
#3  0x40872bc0 in g_get_home_dir () at gutils.c:623
#4  0x40962795 in gtk_rc_append_default_module_path () at gtkrc.c:295
#5  0x40962c0e in gtk_rc_init () at gtkrc.c:462
#6  0x4093d499 in gtk_init_check (argc=0xbfffe374, argv=0xbfffe378) at
gtkmain.c:440

It seems that there is no way to avoid that.  If two shared libraries
define the same symbol (a legitimate case), the earlier loaded library's
symbol will prevail. I guess One way to avoid that would be building
GLIB/GTK with CPPFLAGS=-Dg_strdup=glib_strdup, but is there a more
permanent solution to this problem, perhaps, renaming g_strdup() to
something else? Has anyone else run into this issue?

-Andrei

Hacker: Any person who derives joy from
        discovering ways to circumvent limitations.