g_strdup symbol conflict

From: Andrei Zmievski <andrei ispi net>

To: gtk-list gnome org

Subject: g_strdup symbol conflict

Date: Fri, 6 Jul 2001 09:17:02 -0500

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.