Re: Potential bash 2.05 issues with 'set'

> From: "Tim Van Holder" <[EMAIL PROTECTED]> > Date: Fri, 21 Sep 2001 18:44:43 +0200 > > bash's behaviour with regards to the 'set' builtin has changed in 2.05 > This apparently lead to a broken config.cache when using bash 2.05 > > ! ac_cv_path_install=${ac_cv_path_install='ginstall -c'

Re: Portability of find(1)

> From: Sascha Schumann <[EMAIL PROTECTED]> > Date: Tue, 18 Sep 2001 16:00:11 +0200 (CEST) > > '{}' can only be used portably, if it is a separate argument. It's worse than that. Not only must '{}' be separate and not part of any other argument, it must not be followed by another argument '

Re: Libtool and echo (Was: bison-1.29c 'configure' problems on Solaris 8)

> From: "Gary V. Vaughan" <[EMAIL PROTECTED]> > Date: Fri, 5 Oct 2001 22:46:36 +0100 > > libtool needs to store lots of script snippets in shell variables to > be passed to eval later. In order for this to work, it must be > possible to backslash escape shell meta characters, so that eval's > be

Re: use of libtool for linking executables - rpath problem

> From: Bruno Haible <[EMAIL PROTECTED]> > Date: Mon, 19 Nov 2001 19:08:59 +0100 (CET) > > 1) We don't change our packages. We only tell the user that he should have >used LDFLAGS="-L${prefix}/lib -rpath ${prefix}/lib" > > 6) Let each package search for 'libtool' in $PATH and use it if f

Re: use of libtool for linking executables - rpath problem

> From: Bruno Haible <[EMAIL PROTECTED]> > Date: Tue, 11 Dec 2001 15:28:30 +0100 (CET) > ftp://alpha.gnu.org/gnu/gettext/gettext-0.11-pre3.tar.gz. Thanks. I downloaded it and took a very brief look. It doesn't build on Solaris 8 + GCC 3.0.2 due to some really minor problems. If you've already

Re: linkat, LINK_FOLLOWS_SYMLINKS, and Solaris

[Adding libtool to the CC: list, since Bob indicates there are libtool and autoconf implications as well. The thread starts at .] On 12/26/2010 09:51 AM, Bruno Haible wrote: > So, when libposix becomes reality, it may be compile

Re: linkat, LINK_FOLLOWS_SYMLINKS, and Solaris

On 12/27/2010 05:03 AM, Bruno Haible wrote: > Your proposed answer "don't do that" would imply that every library > is distributed in different variants, one for each standards compliance. No, I was thinking more along the lines "don't use -xc99=all". It's clearly a problem to do that, or anything

Re: linkat, LINK_FOLLOWS_SYMLINKS, and Solaris

On 12/27/2010 05:52 PM, Paul Eggert wrote: > I was thinking more along the lines "don't use -xc99=all". Following up on this idea, I installed a change into Autoconf so that Autoconf-generated 'configure' scripts will no longer default to -xc99=all when using S

Re: ksh bug on Tru64 UNIX causes current libtool failure

Ralf Wildenhues <[EMAIL PROTECTED]> writes: > * doc/autoconf.texi (Limitations of Builtins) : Mention > Tru64 ksh pattern matching bug. Thanks. I installed the following slightly-different patch into autoconf. --- autoconf.texi 8 Jun 2005 07:13:50 - 1.907 +++ aut

Re: libtool 2.1a failed mdemo-make.test on Solaris

Bruno Haible <[EMAIL PROTECTED]> writes: > You are right, the presence of $(ARGZ_H) in $(BUILT_SOURCES) makes this > rule unnecessary. (Historically, the rule predates the use of BUILT_SOURCES.) > Thanks for the hint. I propose this patch in gnulib. Thanks; I installed that. At the same time I c

Re: sh portability questions

Akim Demaille <[EMAIL PROTECTED]> writes: > Now that there are no doubts about the portability of shell functions > (in the sense that there's always a shell on the machine that supports > function ---and maybe the documentation should reflect this), Yes, it should. > I'm curious about the suppo

Re: sh portability questions

Andreas Schwab <[EMAIL PROTECTED]> writes: > Paul Eggert <[EMAIL PROTECTED]> writes: > >> Assuming you don't need recursion, here's a thought. Use "local", but >> stick to the convention that all variable names are unique. On >> systems th

Re: sh portability questions

Akim Demaille <[EMAIL PROTECTED]> writes: > Also, maybe I am paranoid, but would you trust shells to support > conditional function definitions? Or function definitions in eval? No, you're not paranoid. But I think I would trust it, yes. Admittedly it might take some iterations to get the test

Re: use of -fno-common on Darwin

"Peter O'Gorman" <[EMAIL PROTECTED]> writes: > getprogname(3), if it exists, can be used as well as other > alternatives (e.g. argv[0]). Thanks, I wasn't aware of the BSD getprogname until now. How about this proposal? * Change the progname module to use the BSD getprogname naming convention.

Re: 1.5.22 fails to configure on AIX 5.1

Ralf Wildenhues <[EMAIL PROTECTED]> writes: > Likewise, I have been unable to reproduce any issues _without_ `sh -vx'. I didn't quite follow everything in that thread, but as I understand it the problem occurs only when one is using "sh -vx configure" on AIX. Ralf Wildenhues <[EMAIL PROTECTED]>

Re: 1.5.22 fails to configure on AIX 5.1

Howard Chu <[EMAIL PROTECTED]> writes: > I was thinking that, or ((set -o posix) >/dev/null 2>*1); ... Will > give it a shot. Another possibility, which I just thought of, is to redirect stdin as well: (set -o posix) /dev/null 2>&1 Another possibility is to try "set +o posix" instead of "set -o

Re: autoreconf --help

Ralf Wildenhues <[EMAIL PROTECTED]> writes: > OK to apply? Yes, and thanks. > Do you think we need to announce this change in NEWS? Not really. ___ http://lists.gnu.org/mailman/listinfo/libtool

Autoconf 2.60 released

ERL, AC_ERLANG_CHECK_LIB, AC_ERLANG_SUBST_ROOT_DIR, AC_ERLANG_SUBST_LIB_DIR. New macros for configuring installation of Erlang libraries: AC_ERLANG_SUBST_INSTALL_LIB_DIR, AC_ERLANG_SUBST_INSTALL_LIB_SUBDIR. ** The manual now mentions Gnulib more prominently. ** New macros to support Objective C. AC_PRO

Autoconf test version 2.60a available

We're happy to announce the release of Autoconf 2.60a. This is a test version. It is mostly a bug-fix release since 2.60. We hope to generate Autoconf 2.61 soon, based on feedback from this test version. The important changes since Autoconf 2.60 are listed below. The sources (1.4 MB) and GPG d

Re: libraries and namespaces

Bruno Haible <[EMAIL PROTECTED]> writes: > I wish to export the symbols of external{i}.c without modifications, > whereas the symbols of internal{j}.c should get a prefix. Doesn't the question of whether a symbol should get a prefix more properly belong to .h files than to .c files? That is, if

Autoconf test version 2.60b available

We're happy to announce the release of Autoconf 2.60b. This is a test version. It is mostly a bug-fix release since 2.60. We hope to generate Autoconf 2.61 soon, based on feedback from this test version. The important changes since Autoconf 2.60a are listed below. The sources and GPG detached

Autoconf 2.61 released

We're happy to announce the release of Autoconf 2.61. Please grab it from one of the gnu.org mirror sites. The important changes since 2.60 are listed below. The BIN_SH change may require special attention by installers on some older-style platforms, but as far as we know this affects only Unixwa

Autoconf test version 2.61a released

We're happy to announce the release of Autoconf 2.61a. This is a test version, meant to shake out bugs in our switch from 'sed' to 'awk' to implement 'configure'-time substitutions, and (if 'printf' is available) from 'echo' to 'printf' to output strings containing special characters. There is al

Re: autoreconf misses ltmain.sh

> From: Akim Demaille <[EMAIL PROTECTED]> > Date: 24 Sep 2002 13:33:43 +0200 > > So as was kindly suggested by TED, we should have autoreconf work > around Libtool problems. I missed that suggestion somewhere in my mailbox (currently with 2035 messages to read, sigh); if you think it preferable

Re: autoreconf misses ltmain.sh

> From: Akim Demaille <[EMAIL PROTECTED]> > Date: 25 Sep 2002 12:03:42 +0200 > > Please, install! OK, done. I did find some errors in my proposed text (it didn't give the obvious workaround, and it credited the wrong people for the patch -- ouch!), so I installed the following patch instead.

Re: Libtool 1.4.3

> From: Sascha Schumann <[EMAIL PROTECTED]> > Date: Wed, 9 Oct 2002 19:49:57 +0200 (CEST) > > > Did you send a bug report? Do you have a test case? > > I'm sorry, it was noticed by so many people, I supposed it > would make its way to you. It's the first I've heard of it. Do you have

Autoconf 2.57 is released

The Autoconf team -- Akim, Alexandre, Jim, Paul, and Tom -- is happy to announce the birth of Autoconf 2.57, a bugfix release. - Where can I find it? ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.57.tar.gz (1.1 MB) ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.57.tar.bz2(811 kB) and soon

Re: 1,000 year backward compatability of tools

"John W. Eaton" <[EMAIL PROTECTED]> writes: > even Ultrix had another shell, /bin/sh5, if I remember correctly, > that did support shell functions, and it would not have been too > difficult for configure to attempt to find it Recent versions of Autoconf generate "configure" scripts that do just

Re: MKS Bourne Shell "case" weirdness...

"Lars J. Aas" <[EMAIL PROTECTED]> writes: > Is it possible that this is a local problem for the given MKS user I > am working with and that he may have a somewhat faulty MKS > installation or something? Possibly. It'd be nice if we could have another MKS user report what happens. Or perhaps you

Autoconf 2.59 available from ftp.gnu.org

Autoconf 2.59 is now available from the following URLs: ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.59.tar.gz ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.59.tar.bz2 Here are the MD5 checksums: d4d45eaa1769d45e59dcb131a4af17a0 autoconf-2.59.tar.gz 1ee40f7a676b3cfdc0e3f7cd81551b5f autoconf-2.59.tar.

Re: Do autotools support free Microsoft compiler?

ago; but it was ignored.) Sorry, I dropped the ball on that. I didn't like your patch, but didn't have time to compose a better one at the time. I just took the time, installed the following patch instead. Please try CVS Autoconf on your compiler installation to see whether this approach

Re: Finish making zsh Bourne-compatible

Noah Misch <[EMAIL PROTECTED]> writes: > I tested this change on a Fedora Core 1 system and all Autoconf > tests continue to pass. Thanks for your detective work and the fix. I installed your patch into Autoconf CVS. > I really cannot run the Autoconf test suite on Mac OS X with zsh, > though.

Re: cvs build prob

`$echo "X$output_verbose_link_cmd" | $Xsed -e "$no_glob_subst"` The outer quotes aren't needed. This issue is discussed in the Autoconf manual's Shellology section. Anyway, here's the Autoconf patch I installed. 2004-07-27 Paul Eggert <[EMAIL PROTECTED]>

Re: cvs build prob

Patrick Welche <[EMAIL PROTECTED]> writes: > -elif test -n "${BASH_VERSION+set}${KSH_VERSION+set}" && (set -o posix) >/dev/null > 2>&1; then > +elif test -n "${BASH_VERSION+set}" && (set -o posix) >/dev/null 2>&1; then >set -o posix > +elif test -n "${KSH_VERSION+set}" && (set +o posix) >/dev

Re: cvs build prob

"Gary V. Vaughan" <[EMAIL PROTECTED]> writes: > it appears that pdksh is confused over what the posix behaviour should > be :-( Yup. That part of the POSIX spec is confusing, but if you look in 2.2.2 it says T

Re: cvs build prob

l have to scan for "pdksh" to see the meat. 2004-07-29 Paul Eggert <[EMAIL PROTECTED]> * doc/autoconf.texi (Shellology): Mention BIN_SH. Document problem with "`""`" in pdksh POSIX mode. Index: autoconf.texi

GNU Autoconf test version 2.59b available

GNU Autoconf test version 2.59b is now available. This version is numbered 2.59b because I've heard of some "2.59a" versions floating around the net, and I wanted to distinguish it. This is an "early beta" release. I expect it to have several problems, particularly porting problems on hosts other

AC_PROG_LIBTOOL error should be fixed by GNU m4 1.4.2

Ludovic CourtÃs <[EMAIL PROTECTED]> writes: > This seems to be a bug in GNU M4 1.4.1 (see [1, 2, 3] for details). That bug should be fixed in GNU m4 1.4.2, available here: ftp://ftp.gnu.org/gnu/m4/m4-1.4.2.tar.gz (I write "should be" because I couldn't reproduce the problem on my Solaris 8 box

Re: License of m4/ltoptions.m4

Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: Some ideas: > > 1. prefix all the m4/*.m4 licenses with `##' so aclocal > omit them from aclocal.m4 (leaving only the "unlimited > permission to ..." license added by aclocal) > > 2. add an exception to all the m4/*.m4 files similar

Re: License of m4/ltoptions.m4

"Gary V. Vaughan" <[EMAIL PROTECTED]> writes: > However, even though our intentions are good, and we are merely > clarifying the existing spirit of the exception clauses we have used > all along, is it okay to just edit the license of existing files without > explicit permission from the authors?

Re: License of m4/ltoptions.m4

"Gary V. Vaughan" <[EMAIL PROTECTED]> writes: > Was anybody unhappy with the exception wording in my last post in the > thread? If not we can start from there. I worry that it's too generous, because it means that if the package uses the .m4 file as input to autoconf, then the package can also u

Re: License of m4/ltoptions.m4

Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: > "or any derived output" is a lame attempt to allow tools such as > aclocal (without singling out aclocal) to preprocess the file, > as long as the intent is to build a configure script. I like the idea, but how about if we generalize it to allo

Re: License of m4/ltoptions.m4

"Gary V. Vaughan" <[EMAIL PROTECTED]> writes: > Now for the note to the FSF that explains why we need it... here > is a first cut to get the ball rolling: That looks fine to me. Thanks. ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/