"$func_quote_result\""
> > }
> > fi
> >
> > Note that with this variant, the portable version converts 'a *"b' into
> > '"a *\"b"', while the bash version converts it into 'a\ \ \*\"b'.
>
> Tha
been historically used to generate
'*.la' files. We should keep that format as is -- so we would have to
have two versions of func_quote (one possibly with printf %q, one
producing the old output).
> Here's a (lightly-tested) idea of what it would look like, where we'd
&g
27;
(necessary in that case).
> +
> +case $func_quote_result in
> + *[\\\`\"\$]*)
Something needs escaping before being placed in double quotes.
> +case $func_quote_result in
> + *'*'*|*'['*)
Problem: shouldn't this also
ld we test the size of the string first ? i've written such raw
> > > > > shell
> > > > > string parsing functions before, and once you hit a certain size
> > > > > (like 1k+
> > > > > iirc), forking out to sed is way faster, es
On 10/05/2015 01:47 AM, Pavel Raiskup wrote:
>
> Hmm, one might-be-a-problem with this (catched by testsuite), when you
s/catched/caught/
> We would like to have an output \"*\". I'm not aware of portable way
> how to disable wildcard expansion in shell, and autoconf 'Shellology'
> section ha
gt; > shell
> > > > string parsing functions before, and once you hit a certain size (like
> > > > 1k+
> > > > iirc), forking out to sed is way faster, especially when running in
> > > > multibyte
> > > > locales (like UTF8) whic
hit a certain size (like
> > > 1k+
> > > iirc), forking out to sed is way faster, especially when running in
> > > multibyte
> > > locales (like UTF8) which most people are doing nowadays.
> > > -mike
> >
> > Well, that optimization would
On Monday 05 of October 2015 00:45:50 Pavel Raiskup wrote:
> > should we test the size of the string first ? i've written such raw shell
> > string parsing functions before, and once you hit a certain size (like 1k+
> > iirc), forking out to sed is way faster, esp
all saw this blogpost where a guy pushed
> > >> the sed regular expression handling into bash-specific
> > >> regular expressions when bash was available. He claims
> > >> there's a significant performance improvement because of
> > >> reduced fork
On Mon, 2015-03-09 at 18:28 +, Mike Gran wrote:
> I don't know if y'all saw this blogpost where a guy pushed
> the sed regular expression handling into bash-specific
> regular expressions when bash was available. He claims
> there's a significant performance impro
On 09 Mar 2015 14:48, Eric Blake wrote:
> On 03/09/2015 01:50 PM, Bob Friesenhahn wrote:
> > On Mon, 9 Mar 2015, Mike Gran wrote:
> >> I don't know if y'all saw this blogpost where a guy pushed
> >> the sed regular expression handling into bash-specific
&
On 03/09/2015 01:50 PM, Bob Friesenhahn wrote:
> On Mon, 9 Mar 2015, Mike Gran wrote:
>
>> Hello libtool,
>>
>> I don't know if y'all saw this blogpost where a guy pushed
>> the sed regular expression handling into bash-specific
>> regular e
On Mon, 9 Mar 2015, Mike Gran wrote:
Hello libtool,
I don't know if y'all saw this blogpost where a guy pushed
the sed regular expression handling into bash-specific
regular expressions when bash was available. He claims
there's a significant performance improvement because of
Hello libtool,
I don't know if y'all saw this blogpost where a guy pushed
the sed regular expression handling into bash-specific
regular expressions when bash was available. He claims
there's a significant performance improvement because of
reduced forking.
http://harald.hoyer
Albert Chin writes:
> On Tue, Feb 04, 2003 at 04:04:29PM +, Lars Hecking wrote:
> > On Solaris 7/8, this list of objects is too long for the native sed,
> > and linking fails (some error messages about "line too long"). I reported
> > this as a bug and
Lars,
You're in luck! CVS Libtool goes to great pains to ensure that
the sed used by it is the best one available. It also has piecewise
linking support, most of this added by me for AutoOpenCascade
@sourceforge.
This doesn't solve the problem completely, it can't work around
On Tue, Feb 04, 2003 at 04:04:29PM +, Lars Hecking wrote:
> On Solaris 7/8, this list of objects is too long for the native sed,
> and linking fails (some error messages about "line too long"). I reported
> this as a bug and was told to use GNU sed instead.
Fixed in lib
onvenience libraries for the
various subdirectory builds. The consequence is that all objects are
passed to libtool on the command line - which can be a very long list,
depending on which features one compiles into php.
On Solaris 7/8, this list of objects is too long for the native sed,
and linking f
On Fri, Dec 13, 2002 at 12:37:14AM -0600, Robert Boehne wrote:
> I'm seeing this sed invocation spitting out complaints
> on any platform not using GNU sed, i.e. OS X, FreeBSD, IRIX, Tru64
> to name a few. Any idea why?
>
> lt_compile=`echo "$ac_compile&qu
Title: RE: SED ?
Patrick,
Yes something is wrong here, I'm currently working on fixing this
but I didn't know it was broken in CVS Libtool. The problem I'm
having is that $SED needs to be set earlier than it currently is,
so the resulting libtool is attempting to operate wit
Using cvs libtool from just now, which passed everything :-), I tried
bootstraping sasl, and found that the libtool generated died at
progname=`$echo "$0" | ${SED} 's%^.*/%%'`
modename="$progname"
because SED was empty - where should SED be defined? (Adding SED=se
Hello,
I'm seeing this sed invocation spitting out complaints
on any platform not using GNU sed, i.e. OS X, FreeBSD, IRIX, Tru64
to name a few. Any idea why?
lt_compile=`echo "$ac_compile" | sed \
-e 's:.*FLAGS\}\? :&$lt_compiler_flag :; t' \
-e 's:
On Sun, Oct 28, 2001 at 01:14:29AM +0100, Gary V. Vaughan wrote:
> On Thu, Oct 04, 2001 at 09:05:18AM +1000, Kevin Ryde wrote:
> > On an sv1-cray-unicos10.0.0.X with the cvs libtool I noticed the
> > following error,
> >
> > configure: creating lib
On Thu, Oct 04, 2001 at 09:05:18AM +1000, Kevin Ryde wrote:
> On an sv1-cray-unicos10.0.0.X with the cvs libtool I noticed the
> following error,
>
> configure: creating libtool
> sed: 1: "s/[-_ABCDEFGHIJKLMNOPQR ...": RE error: [ ] imbalance or syntax
&
>>>>> "Kevin" == Kevin Ryde <[EMAIL PROTECTED]> writes:
Kevin> On an sv1-cray-unicos10.0.0.X with the cvs libtool I noticed
Kevin> the following error,
Kevin> configure: creating libtool sed: 1:
Kevin> "s/[-_ABCDEFGHIJKLMNOPQR ...&
[EMAIL PROTECTED] writes:
>
> If you replace the delimiter with a character other than "/", does the
> sed command work?
Yes, colons worked in last nights build.
--- libtool.m4.old Thu Oct 4 01:40:53 2001
+++ libtool.m4 Thu Oct 4 01:42:27 2001
@@ -1446,7 +1446,7 @
On Thu, Oct 04, 2001 at 09:05:18AM +1000, Kevin Ryde wrote:
> On an sv1-cray-unicos10.0.0.X with the cvs libtool I noticed the
> following error,
>
> configure: creating libtool
> sed: 1: "s/[-_ABCDEFGHIJKLMNOPQR ...": RE error: [ ] imbalance or syntax
&
On an sv1-cray-unicos10.0.0.X with the cvs libtool I noticed the
following error,
configure: creating libtool
sed: 1: "s/[-_ABCDEFGHIJKLMNOPQR ...": RE error: [ ] imbalance or syntax error
appending configuration tag "CXX" to libtool
which I
On Wednesday 18 July 2001 12:33 am, Robert Boehne wrote:
> Alex Hornby wrote:
> > My earlier link line truncation problem on solaris was not due to
> > command line length restrictions (getconf reports a healthy 109kb for
> > ARG_MAX).
> >
> > Solaris 2.6 /usr/b
Alex Hornby wrote:
>
> My earlier link line truncation problem on solaris was not due to
> command line length restrictions (getconf reports a healthy 109kb for
> ARG_MAX).
>
> Solaris 2.6 /usr/bin/sed, as used by libtool during the link, has
> problems with "long&q
My earlier link line truncation problem on solaris was not due to
command line length restrictions (getconf reports a healthy 109kb for
ARG_MAX).
Solaris 2.6 /usr/bin/sed, as used by libtool during the link, has
problems with "long" lines of > 3999 characters, truncating them a
31 matches
Mail list logo
