Re: Problem Compiling CVS Glib v1.1.3



Hi,

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

Yes, I've got some reports about that too recently.

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

Yes, very bad.

>  - 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'll do exactly that, but leave it in the old place, beause it might be of
use later, see below.

> 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.)

We could do the old game of function vectors again, at least for some
often used ..._r functions. Elliot won't like it, but I still thick it is
good to provide portability support. (BTW: those getpw... functions have a
redicoulus interface, why should I provide a buffer, I'm not using, that I
do not know the initial needed size of etc.?) 

I'll remove the use of _r functions on the affected platforms for now and
will try to come up with a better solution later for 1.3.

Bye,
Sebastian
-- 
Sebastian Wilhelmi                   |            här ovanför alla molnen
mailto:wilhelmi@ira.uka.de           |      är himmlen så förunerligt blå
http://goethe.ira.uka.de/~wilhelmi   |



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]