headers
Ben Walton | 1 Dec 2011 04:30
Picon
Picon

Re: [RFC] sethostname handling patch series

Excerpts from Bruno Haible's message of Wed Nov 30 05:29:14 -0500 2011:

Hi Bruno,

> Your patches look pretty good. In parallel to the tweaking of the
> last details, it will be useful to assign the copyright for the
> change to the FSF. This is needed because Gnulib is central to many
> GNU packages.

Thanks for the great feedback.  I'm implementing the fixes for issues
you noted and testing them.  I'll submit them shortly (hopefully
tomorrow as I won't get to test on cygwin tonight).

The only point I'm not clear on is the note about using a fixed size
array allocation instead of the dynamic one.  Is it acceptable to use
HOST_NAME_MAX + 1 to achieve a size that is known to the compiler at
compile time or did you have some other non-malloc mechanism in mind?

Each patch should also update Changlog as well, correct?  I think that
the patch to add test-sethostname would be best as a fourth patch
since it can't be used until the unistd integration is done.  The
alternate would be to squash 2 and 3 of this series into a single
patch at which point the test suite could be updated as well.  What is
the preferred method?

> To go ahead with this, please fill in the form in the file
> gnulib/doc/Copyright/request-assign.future (if you foresee making
> more contributions to Gnulib) or
> gnulib/doc/Copyright/request-assign.changes (if this will be your
> only contribution) and send it to the FSF.
(Continue reading)

Permalink | Reply | 22 comments |
headers
Bruno Haible | 1 Dec 2011 12:29

Re: [RFC] sethostname handling patch series

Hi Ben,

> The only point I'm not clear on is the note about using a fixed size
> array allocation instead of the dynamic one.  Is it acceptable to use
> HOST_NAME_MAX + 1 to achieve a size that is known to the compiler at
> compile time

Yes. Stack allocations are OK up to a size of ca. 4096. HOST_NAME_MAX
is 64 or 255 or 256 on all known systems, and it wouldn't make sense
to make it longer than 1000.

> Each patch should also update Changlog as well, correct?

Yes, but you can also send the ChangeLog entry separately from the patch
(in the same mail, as a copy&paste), if that's simpler for you.

> I think that
> the patch to add test-sethostname would be best as a fourth patch
> since it can't be used until the unistd integration is done.

Yes, I do it the same way: First the patch that adds new functionality,
then the unit test. Of course, during development, I create both together.
But separating them in the proposal and in the commits makes the review
easier.

Bruno
--

-- 
In memoriam Alfred Herrhausen <http://en.wikipedia.org/wiki/Alfred_Herrhausen>
(Continue reading)

Permalink | Reply | 20 comments |
headers
Werner Koch | 1 Dec 2011 11:32
Picon
Favicon

gen-ChangeLog rule

Hi!

coreutils does not allow to use a VPATH with "make dist"; I now use this
gen-ChangeLog rule in GnuPG to allow VPATH builds:

gen_start_date = 2011-12-01T06:00:00
.PHONY: gen-ChangeLog
gen-ChangeLog:
	if test -d $(top_srcdir)/.git; then				\
	  (cd $(top_srcdir) &&                      			\
	    ./scripts/gitlog-to-changelog				\
	    --amend=scripts/git-log-fix	 				\
	    --since=$(gen_start_date) ) > $(distdir)/cl-t;		\
          cat $(top_srcdir)/scripts/git-log-footer >> $(distdir)/cl-t;  \
	  rm -f $(distdir)/ChangeLog;					\
	  mv $(distdir)/cl-t $(distdir)/ChangeLog;			\
	fi

You may want to s/scripts/build-aux/.

The strange gen_start_date is needed because git seems to default to
noon; there was also a last ChangeLog entry in the night.  I added a
footer to add a copyright notice to the ChangeLog.

Salam-Shalom,

   Werner

--

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Blake | 1 Dec 2011 22:01
Picon
Favicon
Gravatar

[PATCH] mktempd: silence dd usage

When running a testsuite on FreeBSD, I saw a lot of:

1+ records in
0+1 records out
10 bytes transferred in 0.000063 secs (158875 bytes/sec)

literring the testsuite, and traced it to the fact that we
were silencing one, but not the other, dd usage in our fallback.

* build-aux/mktempd (rand_bytes): Silence dd.

Signed-off-by: Eric Blake <eblake <at> redhat.com>
---
 ChangeLog         |    5 +++++
 build-aux/mktempd |    3 ++-
 2 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index fdf8b25..5a616e7 100644
--- a/ChangeLog
+++ b/ChangeLog
 <at>  <at>  -1,1 +1,6  <at>  <at> 
+2011-12-01  Eric Blake  <eblake <at> redhat.com>
+
+	mktempd: silence dd usage
+	* build-aux/mktempd (rand_bytes): Silence dd.
+
 2011-11-30  Simon Josefsson  <simon <at> josefsson.org>

 	manywarnings: Don't mention gcc version in docstring.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Eric Blake | 1 Dec 2011 22:52
Picon
Favicon
Gravatar

Re: Removing -Wunsuffixed-float-constants, -Wdouble-promotion, -Wformat-zero-length

On 11/29/2011 02:05 PM, Paul Eggert wrote:
> On 11/29/11 09:35, Jim Meyering wrote:
>> +  gl_WARN_ADD([-Wno-unsuffixed-float-constants])
> 
> How about if we remove -Wunsuffixed-float-constants from
> manywarnings.m4?  In practice it typically causes more
> trouble than it cures (the above-quoted gzip patch is
> one example, but I've run into it elsewhere).
> 
> While we're on the subject of manywarnings.m4, can we also
> remove -Wdouble-promotion and -Wformat-zero-length?  They
> also seem to be more suited for special- rather than
> general-purpose code.

I've just found another problem with the manywarnings module:

gcc 4.6.2 handles -Wabi and -Wdeprecated just fine for C code (I don't
know if it is silently ignored, or if it could actually trigger); but
gcc 4.2.1 (as shipped on FreeBSD) complains:

cc1: warning: command line option "-Wabi" is valid for C++/ObjC++ but
not for C
cc1: warning: command line option "-Wdeprecated" is valid for C++/ObjC++
but not for C

on every single compilation run.  Is there a way to improve the module
so that these warnings are not added to the command line when dealing
with older (noisier) gcc?

--

--
(Continue reading)

Permalink | Reply | 1 comment |
headers
Simon Josefsson | 2 Dec 2011 08:41
Favicon
Gravatar

Re: Removing -Wunsuffixed-float-constants, -Wdouble-promotion, -Wformat-zero-length

Eric Blake <eblake <at> redhat.com> writes:

> I've just found another problem with the manywarnings module:
>
> gcc 4.6.2 handles -Wabi and -Wdeprecated just fine for C code (I don't
> know if it is silently ignored, or if it could actually trigger); but
> gcc 4.2.1 (as shipped on FreeBSD) complains:
>
> cc1: warning: command line option "-Wabi" is valid for C++/ObjC++ but
> not for C
> cc1: warning: command line option "-Wdeprecated" is valid for C++/ObjC++
> but not for C
>
> on every single compilation run.  Is there a way to improve the module
> so that these warnings are not added to the command line when dealing
> with older (noisier) gcc?

Did you run it through gl_WARN_ADD?  I wonder if we could use -Werror?
However AC_LANG_PROGRAM and -Werror are often incompatible...

We could look to see if -Wabi and -Wdeprecated really does anything in
gcc 4.6.x for C.  If it doesn't, let's remove it.  They are not
mentioned in the manual.

/Simon
Permalink | Reply | 0 comments |
headers
Simon Josefsson | 2 Dec 2011 09:36
Favicon
Gravatar

Re: [sr #107896] gnutls 3.0.8 fails to compile with clang

Has anyone tested the recent stdalign.h stuff with clang?  We got a
report below regarding it.  Do we need to replace clang's stdalign.h
with a more feature-ful gnulib replacement?

/Simon

Elias Pipping <INVALID.NOREPLY <at> gnu.org> writes:

> URL:
>   <http://savannah.gnu.org/support/?107896>
>
>                  Summary: gnutls 3.0.8 fails to compile with clang
>                  Project: GnuTLS
>             Submitted by: pipping
>             Submitted on: Wed 30 Nov 2011 12:38:29 GMT
>                 Category: None
>                 Priority: 5 - Normal
>                 Severity: 3 - Normal
>                   Status: None
>                  Privacy: Public
>              Assigned to: None
>         Originator Email: 
>              Open/Closed: Open
>          Discussion Lock: Any
>         Operating System: None
>
>     _______________________________________________________
>
> Details:
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Eggert | 2 Dec 2011 10:43
Favicon

Re: [sr #107896] gnutls 3.0.8 fails to compile with clang

Thanks, I tried to fix that by pushing the following patch;
please give it a try.

I had tested with Clang before, but I was using Clang 2.x
and the problem is new to Clang 3.x (which I don't have).

It strikes me, though, that this sort of approach cannot work if
<stdalign.h> is installed into a directory intended to be used by
shared libraries or whatnot.  This is because the compiler used in the
configure-time test for <stdalign.h> may not be the same as the
compiler used later, when the shared library is compiled against.
I expect that this isn't the only place where gnulib has this problem,
though, and since it's purely theoretical right now for stdalign.h
I didn't pursue it.

stdalign: port to Clang 3.0
Problem reported by Simon Josefsson in
<http://lists.gnu.org/archive/html/bug-gnulib/2011-12/msg00005.html>.
* doc/posix-headers/stdalign.texi (stdalign.h): Mention Clang 3.0,
which has <stdalign.h> but which does not define alignof.
* m4/stdalign.m4 (gl_STDALIGN_H): Check for Clang 3.0's problem.
diff --git a/doc/posix-headers/stdalign.texi b/doc/posix-headers/stdalign.texi
index b3d39f0..bebc70d 100644
--- a/doc/posix-headers/stdalign.texi
+++ b/doc/posix-headers/stdalign.texi
 <at>  <at>  -13,6 +13,8  <at>  <at>  Portability problems fixed by Gnulib:
  <at> itemize
  <at> item
 This header file is missing on most circa-2011 platforms.
+ <at> item
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jim Meyering | 2 Dec 2011 11:24
Gravatar

Re: [PATCH] mktempd: silence dd usage

Eric Blake wrote:
> When running a testsuite on FreeBSD, I saw a lot of:
>
> 1+ records in
> 0+1 records out
> 10 bytes transferred in 0.000063 secs (158875 bytes/sec)
>
> literring the testsuite, and traced it to the fact that we
> were silencing one, but not the other, dd usage in our fallback.
>
> * build-aux/mktempd (rand_bytes): Silence dd.
>
> Signed-off-by: Eric Blake <eblake <at> redhat.com>
> ---
>  ChangeLog         |    5 +++++
>  build-aux/mktempd |    3 ++-
>  2 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/ChangeLog b/ChangeLog
> index fdf8b25..5a616e7 100644
> --- a/ChangeLog
> +++ b/ChangeLog
>  <at>  <at>  -1,1 +1,6  <at>  <at> 
> +2011-12-01  Eric Blake  <eblake <at> redhat.com>
> +
> +	mktempd: silence dd usage
> +	* build-aux/mktempd (rand_bytes): Silence dd.
> +
>  2011-11-30  Simon Josefsson  <simon <at> josefsson.org>
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Stefano Lattarini | 2 Dec 2011 13:01
Picon

spurious message about include files from `bootstrap' script

Hello gnulibers.

While boostrapping the latest coreutils from master (v8.14-79-g1a85d4a),
I've noticed some spurious lines in the messages generated (I believe)
from the `bootstrap 'script; here is an excerpt that should highlight
them:

  ...
  Creating ./lib/uniwidth/.gitignore
  Creating ./m4/.gitignore
  Finished.

  You may need to add #include directives for the following .h files.
    #include <alloca.h>
    ... [SNIP]
    #include <unistd.h>
    #include <wchar.h>
    /* Include only after all system include files.  */
    GPL
    License
    #include "acl.h"
    #include "alignof.h"
    # ... [SNIP]
    #include "yesno.h"

  You may need to use the following Makefile variables when linking.
  ...

The lines:
(Continue reading)

Permalink | Reply | 6 comments |

Gmane