Re: Problem Compiling CVS Glib v1.1.3

[Owen Taylor <otaylor redhat com>]

Chase Hargraves <absolutk@netrover.com> writes:

> Hi,
>     I have been having some trouble compiling the latest CVS Glib
> v1.1.3. Hopefully this information will help someone working on the
> project to make it better. I run SuSe Linux v5.3, kernel v2.2.0pre3,
> egcs v1.1.1 and XFree86 v3.3.2. If any other information is needed, then
> simply email me. If anyone has any ideas as to something I may have
> setup wrong, also, please email me. Here is the full error message text:
> 
> --------------------------------------------------------------------------
> 
> gcc -DHAVE_CONFIG_H -I. -I. -I. -DG_LOG_DOMAIN=g_log_domain_glib     -g
> -O2 -Wall  -D_REENTRANT -c testglib.c
> /bin/sh ./libtool --mode=link gcc  -g -O2 -Wall  -D_REENTRANT  -o
> testglib  testglib.o libglib.la
> gcc -g -O2 -Wall -D_REENTRANT -o .libs/testglib testglib.o -Wl,--rpath
> -Wl,/usr/local/lib .libs/libglib.so
> .libs/libglib.so: undefined reference to `getpwuid_r'
> collect2: ld returned 1 exit status
> make[2]: *** [testglib] Error 1
> make[2]: Leaving directory `/home/absolute/CVS/gnome/gnome/glib'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/absolute/CVS/gnome/gnome/glib'
> make: *** [all-recursive-am] Error 2
> --------------------------------------------------------------------------

I suspect the problem is that you have some form of POSIX
thread library installed, so GLib is enabling threads and
finding getpwuid_r in your -lpthread library. Then, when
it tries to link a GLib program without threads, and without
-pthread, it fails because GLib is using getpwuid_r.

A workaround is then to configure GLib with the 
--without-threads flag.


Thread development folks:

This is a major problem with  GLib currently. The same 
problem occurs on FreeBSD where getpwuid_r and localtime_r 
are found in -lc_r. This needs to be fixed soon.

There are several possible solutions:

 - Link all programs on such systems with -lpthread
   or -lc_r. This IMO, is not acceptable, since linking
   with -lc_r will presumably be a significant speed
   hit for non-threaded programs due to extra locking
   in C library functions.

 - Only look for the reentrant variants in libc, and
   not in the additional thread libs. This will mean
   that we don't get quite as much thread-safety as
   we could on such systems, but the vast majority
   of GLib/GTK+ programs won't be threaded at all for
   the forseable future.

I favor the second solution, but I'm hoping somebody
will come up with a yet-better alternative. (If we
had guaranteed access to weak symbols, there would
be much nicer ways of doing things, but we don't.)

Regards,
                                        Owen