Hi,
I've encountered a bug in tar on OpenSolaris (possibly present in
Solaris 10 and others). I have a tarball that contains a setuid binary
(usr/bin/passwd). When I untar it as root, I see the following error:
tar: usr/bin/passwd: Cannot change mode to r-sr-sr-x: Not owner
Running this under tr
Bruno Haible writes:
> Simon,
>
>> However, do you object to installing the original module to gnulib?
>
> Now that you have shown that it provides access to functionality that
> libtool does not provide portably, I don't object.
Great.
> But I would find it useful to revise the doc and the mod
Thinking even more, "ld-version-script" seems like a better module name,
to avoid confusion with any other non-LD "version" scripts.
The patch below also makes the visibility.texi be part of the gnulib
manual. I assume this was just a mistake and not intentional?
I have pushed the patch below, b
Simon Josefsson wrote:
> Given that the parameter is called --version-script, I think
> "version-script" would be a better name for the module.
Even the suffix "-script" is a bit of a misnomer, IMO. I would call it
'symbol-versions'. If you agree with that, I'll rename the 'visbility'
module to 's
Bruno Haible writes:
> Simon Josefsson wrote:
>> Given that the parameter is called --version-script, I think
>> "version-script" would be a better name for the module.
>
> Even the suffix "-script" is a bit of a misnomer, IMO. I would call it
> 'symbol-versions'. If you agree with that, I'll ren
Bruno, I got this while testing the visibility module in libidn:
/usr/local/bin/gnulib-tool: *** incompatible license on modules:
visibilityLGPL
The module seems to only contain a M4 file, which doesn't use the LGPL
boilerplate but GNU's pe
Bruno, this part of the documentation for the "visibility" module
appears to assume that all public header files are generated from *.in
files via autoconf:
Add a C macro definition, say @samp{-DBUILDING_LIBFOO}, to the CPPFLAGS
for the compilation of the sources that make up the library.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I tried './gnulib-tool --with-tests --test closein', but it failed with:
executing autopoint --force
autopoint: *** The AM_GNU_GETTEXT_VERSION declaration in your configure.ac
file requires the infrastructure from gettext-0.17 but this
v
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When running test-closein.sh, I'm getting spurious output on Darwin:
cat: standard output: Bad file descriptor
PASS: test-closein.sh
$ cat --version | head -n 1
cat (GNU coreutils) 7.1
$ uname -v
Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT
Eric Blake wrote:
> When running test-closein.sh, I'm getting spurious output on Darwin:
>
> cat: standard output: Bad file descriptor
> PASS: test-closein.sh
>
> $ cat --version | head -n 1
> cat (GNU coreutils) 7.1
> $ uname -v
> Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007;
> root:
Simon Josefsson wrote:
> Jim Meyering writes:
>> I've been manually removing MD5 and SHA1 checksums from the template
>> generated by coreutils' "make alpha/beta/major", so have added this
>> so I can automate it:
>
> Btw, is there any point in publishing MD5 checksums?
IMHO, there is no point at
David Bartley wrote:
> I've encountered a bug in tar on OpenSolaris (possibly present in
> Solaris 10 and others). I have a tarball that contains a setuid binary
> (usr/bin/passwd). When I untar it as root, I see the following error:
>
> tar: usr/bin/passwd: Cannot change mode to r-sr-sr-x: Not own
Bruno, I've run into an issue trying to make m4 use the execute module. The
problem boils down to the fact that posix_spawn isn't ported to mingw yet[1].
Even though execute, pipe, and wait-process work just fine on mingw, the fact
that they pull in a dependency on posix_spawn on all other pla
Simon Josefsson wrote:
> The module seems to only contain a M4 file, which doesn't use the LGPL
> boilerplate but GNU's permissive license, so how about this patch?
Applied, thanks.
Bruno
Hi Simon,
> this part of the documentation for the "visibility" module
> appears to assume that all public header files are generated from *.in
> files via autoconf:
Sure. That's the easiest way to ensure that an installed header file is
self-contained.
>Define a macro specific to your libra
Eric Blake wrote:
> I tried './gnulib-tool --with-tests --test closein', but it failed with:
>
> executing autopoint --force
> autopoint: *** The AM_GNU_GETTEXT_VERSION declaration in your configure.ac
> file requires the infrastructure from gettext-0.17 but this
> version
Bruno Haible writes:
> Hi Simon,
>
>> this part of the documentation for the "visibility" module
>> appears to assume that all public header files are generated from *.in
>> files via autoconf:
>
> Sure. That's the easiest way to ensure that an installed header file is
> self-contained.
But it d
Eric Blake wrote:
> When running test-closein.sh, I'm getting spurious output on Darwin:
>
> cat: standard output: Bad file descriptor
> PASS: test-closein.sh
How to reproduce? On Darwin 7 and 9 (MacOS X 10.3.x and 10.9.x) I reproduce an
error from
$ cat foo | :
or
$ { sleep 1; cat foo; } | :
Simon Josefsson writes:
> Thanks, I'm going to test it now.
The instructions seems to work fine, although I have adapted them a bit
to my own preferences.
However, one question. The document says:
1. Add `...@cflag_visibility@' or (in a Makefile.am)
`$(CFLAG_VISIBILITY)' to the CFLAGS
Paul, Jim,
The u64.h file, which is part of the sha512 module now, would be useful
for me in gnutls where we currently have our own uint64_t replacement
types and functions. How about making a separate module for it?
/Simon
>From c0f93a82f337acf77fe909e903b5d2135c558ca3 Mon Sep 17 00:00:00 2001
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 3/3/2009 5:37 PM:
> Eric Blake wrote:
>> When running test-closein.sh, I'm getting spurious output on Darwin:
>>
>> cat: standard output: Bad file descriptor
>> PASS: test-closein.sh
>
> How to reproduce?
$ uname -r
8.11.
Simon Josefsson wrote:
> However, one question. The document says:
>
> 1. Add `...@cflag_visibility@' or (in a Makefile.am)
> `$(CFLAG_VISIBILITY)' to the CFLAGS for the compilation of the
> sources that make up the library.
>
> Does this include source code in helper libraries, such
[oops, sent to bug-coreutils by mistake]
FYI, I've added this comment:
>From 8d2524ce78ca107074727cbd8780c26a203a107c Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Tue, 3 Mar 2009 15:07:45 +0100
Subject: [PATCH] unlinkdir: cannot_unlink_dir may modify process state
* lib/unlinkdir.c (cannot
23 matches
Mail list logo