From: Bjoern V. <bj...@cs...> - 2004-08-06 11:00:52
|
Hello! There is a little build problem for Gaim-0.81/Gaim-CVS on Solaris (I tried Solaris 9/SunOS 5.9 with gcc). The function localtime_r() in src/protocols/jabber/iq.c:174 will not be found by default. This results in= an error message during "make all". Solaris only declares localtime_r() in /usr/include/time.h, if _REENTRANT is set. A small workaround is to pass "-D_REENTRANT" (with gcc and Solaris cc, test= ed) or "-threads" (with gcc, tested) or -mt (with Solaris cc, tested) to CFLAGS= =2E I saw a test for this in glib/configure.in (version 2.4.6). There are also test for other UNIX systems. May be, we can copy something to gaim/configure.ac. Regards, Bj=F6rn |
From: Mark D. <ma...@ki...> - 2004-08-08 00:03:06
|
Any reason we can't just use localtime instead of localtime_r? -Mark On Fri, 6 Aug 2004 13:00:24 +0200 (CEST), Bjoern Voigt wrote > Hello! > > There is a little build problem for Gaim-0.81/Gaim-CVS on Solaris (I > tried Solaris 9/SunOS 5.9 with gcc). The function localtime_r() in > src/protocols/jabber/iq.c:174 will not be found by default. This > results in an error message during "make all". Solaris only declares > localtime_r() in /usr/include/time.h, if _REENTRANT is set. > > A small workaround is to pass "-D_REENTRANT" (with gcc and Solaris > cc, tested) or "-threads" (with gcc, tested) or -mt (with Solaris cc, > tested) to CFLAGS. > > I saw a test for this in glib/configure.in (version 2.4.6). There > are also test for other UNIX systems. May be, we can copy something > to gaim/configure.ac. > > Regards, Björn -- O O Mark Doliner \ | ma...@ki... \ | www.kingant.net "There needs to be a better word for weird." |
From: Mark D. <ma...@ki...> - 2004-08-08 00:07:05
|
A better question: localtime_r is also used in src/util.c, why doesn't that have problems on Solaris? -Mark On Fri, 6 Aug 2004 13:00:24 +0200 (CEST), Bjoern Voigt wrote > Hello! > > There is a little build problem for Gaim-0.81/Gaim-CVS on Solaris (I > tried Solaris 9/SunOS 5.9 with gcc). The function localtime_r() in > src/protocols/jabber/iq.c:174 will not be found by default. This > results in an error message during "make all". Solaris only declares > localtime_r() in /usr/include/time.h, if _REENTRANT is set. > > A small workaround is to pass "-D_REENTRANT" (with gcc and Solaris > cc, tested) or "-threads" (with gcc, tested) or -mt (with Solaris cc, > tested) to CFLAGS. > > I saw a test for this in glib/configure.in (version 2.4.6). There > are also test for other UNIX systems. May be, we can copy something > to gaim/configure.ac. > > Regards, Björn -- O O Mark Doliner \ | ma...@ki... \ | www.kingant.net "There needs to be a better word for weird." |
From: Bjoern V. <bj...@cs...> - 2004-08-08 09:18:26
|
Mark Doliner <ma...@ki...> wrote: > Any reason we can't just use localtime instead of localtime_r? localtime() is not multithreaded-safe, but localtime_r is. If two threads in Gaim use localtime() nearly in the same time, this results in conflicts. But I don't know, how multithreading is used in Gaim. > A better question: localtime_r is also used in src/util.c, why doesn't th= at > have problems on Solaris? There is the same problem (warning: implicit declaration of function=20 `localtime_r'): if gcc -DHAVE_CONFIG_H -I. -I. -I.. -DDATADIR=3D\"/home/pub/share\" =20 -DLIBDIR=3D\"/home/pub/lib/gaim/\" -DLOCALEDIR=3D\"/home/pub/share/locale\= " =20 -DSYSCONFDIR=3D\"/home/pub/etc\" -I../plugins -I/usr/include/gtk-2.= 0=20 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0= =20 -I/usr/openwin/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include = =20 -O2 -I/home/pub/include -Wall -g3 -MT util.o -MD -MP -MF=20 ".deps/util.Tpo" -c -o util.o util.c; \ then mv -f ".deps/util.Tpo" ".deps/util.Po"; else rm -f ".deps/util.Tpo";= =20 exit 1; fi util.c: In function `gaim_base16_decode': util.c:112: warning: subscript has type `char' util.c: In function `gaim_mime_decode_field': util.c:358: warning: subscript has type `char' util.c:369: warning: subscript has type `char' util.c:375: warning: subscript has type `char' util.c:386: warning: subscript has type `char' util.c:392: warning: subscript has type `char' util.c:406: warning: subscript has type `char' util.c: In function `gaim_str_to_time': util.c:518: warning: implicit declaration of function `localtime_r' util.c: In function `gaim_url_encode': util.c:2882: warning: subscript has type `char' util.c: In function `gaim_uri_list_extract_uris': util.c:2964: warning: subscript has type `char' util.c:2973: warning: subscript has type `char' util.c: In function `gaim_utf8_ncr_decode': util.c:3060: warning: subscript has type `char' util.c:3063: warning: subscript has type `char' Regards, Bj=F6rn |
From: Boris de L. <em...@fr...> - 2004-08-08 13:15:47
Attachments:
gaim.patch
|
Le dimanche 08 août 2004 à 11:17 +0200, Bjoern Voigt a écrit : > Mark Doliner <ma...@ki...> wrote: > > > Any reason we can't just use localtime instead of localtime_r? > > localtime() is not multithreaded-safe, but localtime_r is. If two threads > in Gaim use localtime() nearly in the same time, this results in > conflicts. But I don't know, how multithreading is used in Gaim. > > > A better question: localtime_r is also used in src/util.c, why doesn't that > > have problems on Solaris? > > There is the same problem (warning: implicit declaration of function > `localtime_r'): Oh, here is a patch ;) -- Boris de Laage <em...@fr...> GPG Key: 0xC6082D01 |
From: Mark D. <ma...@ki...> - 2004-08-08 14:21:37
|
On Sun, 8 Aug 2004 11:17:31 +0200 (CEST), Bjoern Voigt wrote > Mark Doliner <ma...@ki...> wrote: > > > Any reason we can't just use localtime instead of localtime_r? > > localtime() is not multithreaded-safe, but localtime_r is. If two threads > in Gaim use localtime() nearly in the same time, this results in > conflicts. But I don't know, how multithreading is used in Gaim. > > > A better question: localtime_r is also used in src/util.c, why doesn't that > > have problems on Solaris? > > There is the same problem (warning: implicit declaration of function > `localtime_r'): src/util.c includes src/internal.c which includes time.h. I don't think your patch will have any effect on the "implicit declaration" you're getting, because I think the implicit declaration is caused by the use of localtime_r and the lack of "-D_REENTRANT," as you mentioned earlier. But Gaim doesn't use threads, so I'm just going to change both of these to localtime. (I changed the jabber localtime_r to localtime last night.) -Mark -- O O Mark Doliner \ | ma...@ki... \ | www.kingant.net "There needs to be a better word for weird." |
From: Scott L. <sl...@sl...> - 2004-08-08 18:58:56
Attachments:
PGP.sig
|
On 8 Aug 2004, at 8:57 AM, Mark Doliner wrote: > But Gaim doesn't use threads, so I'm just going to change both of > these to > localtime. (I changed the jabber localtime_r to localtime last night.) Can the same be said of all libgaim-using clients? Adium looks to be okay, as localtime on OS X uses a thread-specific buffer. Not sure about other clients. Thanks, Scott |
From: Mark D. <ma...@ki...> - 2004-08-08 19:53:16
|
On Sun, 8 Aug 2004 13:58:33 -0500, Scott Lamb wrote > On 8 Aug 2004, at 8:57 AM, Mark Doliner wrote: > > > But Gaim doesn't use threads, so I'm just going to change both of > > these to > > localtime. (I changed the jabber localtime_r to localtime last night.) > > Can the same be said of all libgaim-using clients? Adium looks to be > okay, as localtime on OS X uses a thread-specific buffer. Not sure > about other clients. Are you asking if Gaim uses threads anywhere else? It should not. Gaim itself isn't threadsafe, and I'm sure there are things aside from calls to localtime that are not threadsafe. I could be wrong, though. -Mark -- O O Mark Doliner \ | ma...@ki... \ | www.kingant.net "There needs to be a better word for weird." |
From: Scott L. <sl...@sl...> - 2004-08-08 20:20:06
Attachments:
PGP.sig
|
On 8 Aug 2004, at 2:52 PM, Mark Doliner wrote: > On Sun, 8 Aug 2004 13:58:33 -0500, Scott Lamb wrote >> On 8 Aug 2004, at 8:57 AM, Mark Doliner wrote: >> >>> But Gaim doesn't use threads, so I'm just going to change both of >>> these to >>> localtime. (I changed the jabber localtime_r to localtime last >>> night.) >> >> Can the same be said of all libgaim-using clients? Adium looks to be >> okay, as localtime on OS X uses a thread-specific buffer. Not sure >> about other clients. > > Are you asking if Gaim uses threads anywhere else? It should not. > Gaim > itself isn't threadsafe, and I'm sure there are things aside from > calls to > localtime that are not threadsafe. I could be wrong, though. I'm asking if there are any clients which could be negatively affected by non-threadsafe code in libgaim. In fact, maybe the thread safety of libgaim should be made explicit. I think most people would assume that concurrent calls into libgaim are unsafe, but stuff like localtime() is less obvious. Imagine libgaim and some other library both using localtime() internally. They could mess each other up on some platforms, yet unless it's specifically brought up, I wouldn't think of safety problems like this. So I think libgaim should either not make assumptions about clients (such as not using threads) or state those assumptions clearly. Thanks, Scott |
From: Ethan B. <ebl...@cs...> - 2004-08-08 20:47:52
|
Scott Lamb spake unto us the following wisdom: > I'm asking if there are any clients which could be negatively affected=20 > by non-threadsafe code in libgaim. In fact, maybe the thread safety of=20 > libgaim should be made explicit. I think most people would assume that=20 > concurrent calls into libgaim are unsafe, but stuff like localtime() is= =20 > less obvious. Imagine libgaim and some other library both using=20 > localtime() internally. They could mess each other up on some=20 > platforms, yet unless it's specifically brought up, I wouldn't think of= =20 > safety problems like this. So I think libgaim should either not make=20 > assumptions about clients (such as not using threads) or state those=20 > assumptions clearly. I think KingAnt stated those assumptions pretty clearly when he said "libgaim is not threadsafe". It is not. That said, I think we should make an effort to make gaim code safe to use in a threaded application, even if it itself is not reentrant. Glib provides macros and functions for many such typically problematic func- tions (I don't know about localtime), which we should use where possi- ble; in the case of functions for which glib does not have a safe vari- ety, it is not unreasonable to use reentrant varieties (such as local- time_r) on platforms which provide them in a useful fashion. I'm not going to go on a witch hunt for such things, but if they can be detected (at configure or compile time) and fixed cleanly, patches will be accepted. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Luke S. <lsc...@us...> - 2004-08-11 19:04:17
|
> I think KingAnt stated those assumptions pretty clearly when he said > "libgaim is not threadsafe". It is not. *nods* > > That said, I think we should make an effort to make gaim code safe to > use in a threaded application, even if it itself is not reentrant. Glib very much so > provides macros and functions for many such typically problematic func- > tions (I don't know about localtime), which we should use where possi- > ble; in the case of functions for which glib does not have a safe vari- > ety, it is not unreasonable to use reentrant varieties (such as local- > time_r) on platforms which provide them in a useful fashion. I'm not > going to go on a witch hunt for such things, but if they can be detected > (at configure or compile time) and fixed cleanly, patches will be > accepted. Ethan has (as is typical) hit the nail on the head. i'm not interested in making this a priorty, but if someone wants to work towards it, patches are very welcome. luke > > Ethan > |
From: Luke S. <lsc...@us...> - 2004-08-11 19:02:07
|
On Sun, Aug 08, 2004 at 08:57:04AM -0500, Mark Doliner wrote: > On Sun, 8 Aug 2004 11:17:31 +0200 (CEST), Bjoern Voigt wrote > > Mark Doliner <ma...@ki...> wrote: > > > > > Any reason we can't just use localtime instead of localtime_r? > > > > localtime() is not multithreaded-safe, but localtime_r is. If two threads > > in Gaim use localtime() nearly in the same time, this results in > > conflicts. But I don't know, how multithreading is used in Gaim. <snip> > > But Gaim doesn't use threads, so I'm just going to change both of these to > localtime. (I changed the jabber localtime_r to localtime last night.) > -Mark will this affect our dns lookups? i doubt it will affect sounds, but both of these cause additional instances of gaim to show up in ps's output for a short period, though my grasp of the differences between threads and forks and so on is not what it should be, so maybe that's irrelevant to this. luke |
From: Ethan B. <ebl...@cs...> - 2004-08-11 19:58:27
|
Luke Schierer spake unto us the following wisdom: > will this affect our dns lookups? i doubt it will affect sounds, but=20 > both of these cause additional instances of gaim to show up in ps's=20 > output for a short period, though my grasp of the differences between=20 > threads and forks and so on is not what it should be, so maybe that's=20 > irrelevant to this. It's cool, forks are safe. Welcome back. :-) Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |