[committed] gettext should require threadlib.m4
I committed this patch as it is pretty obvious. Paolo commit 0ff506c791bfacbaf7c99463ea7e7c58dac3f4f4 Author: Paolo Bonzini <[EMAIL PROTECTED]> Date: Thu Aug 21 09:22:03 2008 +0200 2008-08-20 Paolo Bonzini <[EMAIL PROTECTED]> * modules/gettext: Add m4/threadlib.m4. diff --git a/modules/gettext b/modules/gettext index 10beecc..5278b40 100644 --- a/modules/gettext +++ b/modules/gettext @@ -23,6 +23,7 @@ m4/printf-posix.m4 m4/progtest.m4 m4/size_max.m4 m4/stdint_h.m4 +m4/threadlib.m4 m4/uintmax_t.m4 m4/visibility.m4 m4/wchar_t.m4
Re: autobuild.m4 time zone fix
Paul Eggert <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> writes: > >> - date=`date +%Y%m%d-%H%M%S` >> + date=`TZ=UTC date +%Y%m%d-%H%M%S` > > Although this change will work on many hosts, it is not portable in > general. It should say TZ=UTC0 to conform to POSIX. Thanks, I've pushed the patch below. /Simon >From 1a033b0f27e71e0bd6b825215eae0a3eb15529be Mon Sep 17 00:00:00 2001 From: Simon Josefsson <[EMAIL PROTECTED]> Date: Thu, 21 Aug 2008 09:24:17 +0200 Subject: [PATCH] m4/autobuild.m4: Use TZ=UTC0 instead of TZ=UTC. Reported by Paul Eggert <[EMAIL PROTECTED]>. --- ChangeLog |5 + m4/autobuild.m4 |2 +- 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index 17cac59..e970bb8 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2008-08-21 Simon Josefsson <[EMAIL PROTECTED]> + + * m4/autobuild.m4: Use TZ=UTC0 instead of TZ=UTC. Reported by + Paul Eggert <[EMAIL PROTECTED]>. + 2008-08-20 Paolo Bonzini <[EMAIL PROTECTED]> * modules/gettext: Add m4/threadlib.m4. diff --git a/m4/autobuild.m4 b/m4/autobuild.m4 index ccd9b5c..a025e73 100644 --- a/m4/autobuild.m4 +++ b/m4/autobuild.m4 @@ -29,7 +29,7 @@ AC_DEFUN([AB_INIT], ifelse([$1],[],,[AC_MSG_NOTICE([autobuild mode... $1])]) - date=`TZ=UTC date +%Y%m%dT%H%M%SZ` + date=`TZ=UTC0 date +%Y%m%dT%H%M%SZ` if test "$?" != 0; then date=`date` fi -- 1.5.6.3
Re: multithread CPPFLAGS
Le jeudi 21 août 2008 à 00:54 +0200, Bruno Haible a écrit : > Yoann Vandoorselaere wrote: > > - Isolate thread specific CPP flags into THREADCPPFLAGS (this is useful > > for a library to propagate threads specific CPPFLAGS). > > What do you mean by that? Do you mean that the users of a library need to > use the same CPPFLAGS as those with which library was compiled? This would > not be right in the majority of cases, IMO. > > Let's look at the two cases: > > - OSF/1: need to modify CPPFLAGS so that cc groks . > If your library's header files make use of then the user > of your library will require the same CPPFLAGS, otherwise not. > In the first case the program that uses the library should use > threadlib.m4 too. > > - AIX, FreeBSD, Solaris: need to modify CPPFLAGS in order to disable > the single-thread-optimized 'errno'. If the program that uses your library > uses multiple threads, it needs to modify CPPFLAGS. If it is a single- > threaded program, it does not need it. > > What's the case you have in mind? Most program using the library currently don't (and probably won't) depend on GnuLib. They are not multithread programs, and in order to enable the library threaded features, we have to export correct CFLAGS/LIBS to theses application so that they can compile with threading enabled. -- Yoann Vandoorselaere <[EMAIL PROTECTED]>
Re: [committed] gettext should require threadlib.m4
Paolo Bonzini wrote: I committed this patch as it is pretty obvious. And I committed a merge in the meanwhile. Sorry; I'll prepare a patch to git to disable merges on branches where you do not want them. :-) Paolo
Re: [committed] gettext should require threadlib.m4
Hi Paolo, * Paolo Bonzini wrote on Thu, Aug 21, 2008 at 11:32:16AM CEST: >> I committed this patch as it is pretty obvious. > > And I committed a merge in the meanwhile. Sorry; I'll prepare a patch > to git to disable merges on branches where you do not want them. :-) This: [branch "master"] rebase = true in your git config, is quite helpful, in order to let 'pull' rebase by default. Cheers, Ralf
Re: [committed] gettext should require threadlib.m4
Ralf Wildenhues wrote: Hi Paolo, * Paolo Bonzini wrote on Thu, Aug 21, 2008 at 11:32:16AM CEST: I committed this patch as it is pretty obvious. And I committed a merge in the meanwhile. Sorry; I'll prepare a patch to git to disable merges on branches where you do not want them. :-) This: [branch "master"] rebase = true in your git config, is quite helpful, in order to let 'pull' rebase by default. Thanks for the tip (I didn't know about it) but it won't fully help. In this case, I would not have committed a merge, but I would have anyway committed the poll(2) work in progress. My usual workflow is to develop stuff in a separate branch, and I want to catch as soon as possible any deviation from the workflow. Paolo
Re: [RFE] function to read a file descriptor
Debarshi Ray wrote: > > What's the use-case of this function? You said that you want to "safely" > > read from sockfd, but can you explain what you mean by that? > > I am actually reading from a PF_NETLINK socket and want the entire > data, which can be spread over multiple consecutive messages, in a > buffer. I see... > Now the BUFSIZ documentation says its "value is guaranteed to > be at least `256'". It is at least 512 everywhere in practice: 512 on mingw 1024 on MacOS X, FreeBSD, OpenBSD, NetBSD, HP-UX, Solaris, Interix, QNX, Cygwin 4096 on AIX, IRIX 8192 on glibc, OSF/1 > Using read-file might not always be possbile since we would lose the > 'flags' argument of 'recv'. But so far your function uses a flags argument of 0. Would any of the flag values MSG_OOB, MSG_PEEK, MSG_WAITALL make sense here? > there are instances where having the entire data in a buffer > makes it easier to parse it. eg., the routing table example. Sure. But your function does not produce the entire data: it does not read until EOF. It reads only as far as is available. When more packets become available, they will be returned through another recvbuf invocation, thus they will have to be parsed separately. In particular, the parser cannot assume that it has the entire data, otherwise it has timing related bugs. This holds for TCP sockets. NETLINK sockets may well be different; I have no experience with them. Bruno
Re: git workflow
Paolo Bonzini wrote: > ... I would have anyway committed the poll(2) work in progress. > > My usual workflow is to develop stuff in a separate branch, and I want > to catch as soon as possible any deviation from the workflow. Maybe you can include the output of the command git status 2>/dev/null | head -n 1 | sed -e 's/# On branch //' in your bash prompt, as a constant reminder on which branch you are working? Like this: export PS1="[EMAIL PROTECTED]:\\w \$(git status 2>/dev/null | head -n 1 | sed -e 's/# On branch //')\\$ " Bruno
Re: multithread CPPFLAGS
Yoann Vandoorselaere wrote: > Most program using the library currently don't (and probably won't) > depend on GnuLib. They are not multithread programs, and in order to > enable the library threaded features, we have to export correct > CFLAGS/LIBS to theses application so that they can compile with > threading enabled. I agree regarding LIBS, but not regarding CPPFLAGS. If the program only ever sees one thread, even though the library uses multiple threads behind its back, - it does not need to #include , and - it does not need to see a thread-aware errno, hence it does not need to compile with THREADCPPFLAGS. Bruno
Re: multithread CPPFLAGS
Le jeudi 21 août 2008 à 12:28 +0200, Bruno Haible a écrit : > Yoann Vandoorselaere wrote: > > Most program using the library currently don't (and probably won't) > > depend on GnuLib. They are not multithread programs, and in order to > > enable the library threaded features, we have to export correct > > CFLAGS/LIBS to theses application so that they can compile with > > threading enabled. > > I agree regarding LIBS, but not regarding CPPFLAGS. If the program only > ever sees one thread, even though the library uses multiple threads behind > its back, > - it does not need to #include , and I agree on this one. > - it does not need to see a thread-aware errno, > hence it does not need to compile with THREADCPPFLAGS. Not using a thread-aware errno from an application that indirectly use thread through a library (which use thread-aware errno). Are you completely sure this is safe? -- Yoann Vandoorselaere <[EMAIL PROTECTED]>
Re: git workflow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 8/21/2008 4:22 AM: > Maybe you can include the output of the command >git status 2>/dev/null | head -n 1 | sed -e 's/# On branch //' > in your bash prompt, as a constant reminder on which branch you are working? > Like this: >export PS1="[EMAIL PROTECTED]:\\w \$(git status 2>/dev/null | head -n 1 | > sed -e 's/# On branch //')\\$ " Or check out the more efficient git/contrib/completion/git-completion.bash from git.git; it provides a function __git_ps1 that forks fewer processes and is smarter about git workflow, so you can use: PS1='...$(__git_ps1 " (%s)")...' - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkitW7QACgkQ84KuGfSFAYA6IACZAZgqGJ5/3Hia94xa3OdlLiU2 /NYAnAqNsw/4UnTas4Cbaziww8qPwFz2 =8Ktf -END PGP SIGNATURE-
Re: multithread CPPFLAGS
Yoann Vandoorselaere wrote: Le jeudi 21 août 2008 à 12:28 +0200, Bruno Haible a écrit : Yoann Vandoorselaere wrote: Most program using the library currently don't (and probably won't) depend on GnuLib. They are not multithread programs, and in order to enable the library threaded features, we have to export correct CFLAGS/LIBS to theses application so that they can compile with threading enabled. I agree regarding LIBS, but not regarding CPPFLAGS. If the program only ever sees one thread, even though the library uses multiple threads behind its back, - it does not need to #include , and I agree on this one. - it does not need to see a thread-aware errno, hence it does not need to compile with THREADCPPFLAGS. Not using a thread-aware errno from an application that indirectly use thread through a library (which use thread-aware errno). Are you completely sure this is safe? Ah, if the libc uses thread-safe errno and the program doesn't... wouldn't that simply break errno? (i.e. libc would set the thread-safe errno and the program would get back something different, and thus never get the right errno when something goes wrong?) Maybe it would work on some platforms, but I'd be really, *really* nervous about it working in general. -- Matthew Anonymous: I want the following [software] features: Rex Dieter: ...and a pony. Can't forget the pony. (Ones with frickin' laser beams a bonus.)
