Re: g_strdup symbol conflict

[Owen Taylor <otaylor redhat com>]

Andrei Zmievski <andrei ispi net> writes:

> 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?

While I have no real measurements, my guess is that GLib is vastly
more commonly used than libgssapi_krb5. And g_strdup() is one of the
most commonly used GLib functions.

Changing the name of g_strdup() from GLib is not really an option --
I wouldn't be suprised however, if its not part of the gssapi
public interface and could safely be renamed there. 

(Evidence for this is provided by the fact that there is no reference
to g_strdup in any of the header files installed in
/usr/kerberos/include)

Regards,
                                        Owen
 
[ CC'ed Nalin Dahyabhai on this mail since he maintains our Kerberos
  packages and may have run into or have some idea about this problem ]