Ralf Wildenhues wrote:
because, for example, OpenBSD uses a modified pdksh as /bin/sh, and one
of the modifications consists of not setting KSH_VERSION any more. :-/
I am at a loss as how to detect this cleanly, suggestions welcome.
if test "X${RANDOM}" != "X${RANDOM}" -a "X${BASH_VERSION+set
Ralf Wildenhues wrote:
OK, thanks. I have applied the following patch to fix these issues,
assuming silent agreement to the other part of my proposed change. ;-)
Looks good to me! Thank you.
Completely off-topic:
Now, I have a curiosity question. Why this (unchanged) construct:
test
Paul Eggert wrote:
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
To tell you the truth, I'm a bit at a loss how to go about this.
How about this idea instead?
for i in `(set -o) 2>/dev/null`; do
case $i in
posix) set -o posix;;
esac
done
Clever. Would it not be easier thus:
case "`
Paul Eggert wrote:
> I don't feel a strong need for 'configure' to default to
> -fstrict-aliasing with GCC. Application code that violates
> strict aliasing assumptions is often unportable in practice
> for other reasons, and needs to be rewritten anyway, even if
> optimization is disabled. So -f
Daniel Berlin wrote:
>> Admittedly it's only two small tests, and it's with 4.1.1. But that's
>> two more tests than the -fwrapv naysayers have done, on
>> bread-and-butter applications like coreutils or gzip or Emacs (or GCC
>> itself, for that matter).
>
> These are not performance needing appl
Daniel Berlin wrote:
> I generally have no problem with turning on -fwrapv at O2, but i'm
> curious where this ends.
> After all, strict aliasing makes it hard to write a bunch of styles of
> code people really want to write, and breaks real world programs and
> GNU software.
>
> Yet we decided t
> I don't agree with this point. There is a substantial number of
> application developers who would prefer -failsafe. There is a
> substantial number who would prefer -frisky. We don't know which set
> is larger. We get a lot of bug reports about missed optimizations.
six vs. half a dozen.
Hi Paul,
On 3/26/07, Paul Eggert <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] Shell Pattern Matching
[EMAIL PROTECTED] Shell Pattern Matching
[EMAIL PROTECTED] Shell pattern matching
+
+Nowadays portable patterns can use negated character classes like
[EMAIL PROTECTED] The older syntax @samp{[^
On 6/28/07, Brett Smith <[EMAIL PROTECTED]> wrote:
Dear GNU Maintainers,
Very soon the FSF sysadmins will freeze software uploads to the GNU FTP
site. You will still be able upload new files at your convenience, but
for now they will not be processed and published. The system will begin
runnin
On Mon, Mar 3, 2008 at 2:48 PM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> Hello Bruce,
>
> * Bruce Korb wrote on Fri, Oct 26, 2007 at 02:45:17AM CEST:
> >
> > I don't necessarily know that it is a "gettext" program.
> > I certainly don't
Hi Ralf,
On Sun, Mar 16, 2008 at 5:26 AM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > > Thanks for the report, and sorry for the long delay. Here's a cheap
> > > patch. Would this be sufficient? It requires you to use -v aka.
> > > --verbose in order to see the message.
> [...]
> > A
This fixes the "I don't know anything about libtool" error message.
Autoconf needs to be fixed, but meanwhile:
bootstrap: 1.49 1.50 bkorb 17/08/16 10:38:39 (modified, needs delta)
@@ -155,6 +155,12 @@ cp depsver.mf sntp/
cp bincheck.mf sntp/
cp depsver.mf sntp/
+export ACLOCAL_PATH=${ACLOCAL_P
It won't hurt. It could (and likely would) slow down the bootstrap by
several milli-seconds. On the other hand, you won't have bootstrap
failures caused by unexpanded LT_LIBTOOL cruft. Fair trade in my book.
Thanks. I fixed that bug. Meanwhile, it seems to me the autotools
ought to be searching installation places for libtool stuff rather
than choking with semi-indecipherable messages.
On Wed, Aug 16, 2017 at 1:39 PM, Eric Blake wrote:
> On 08/16/2017 03:25 PM, Bruce Korb wrote:
>> It won&#
14 matches
Mail list logo
