Re: [shell functions, was RE: solving of name conflicts inincluded.a]
Bruce> Bootstrap-Bash could use a frozen version of configure. This means freezing at least one copy of Bash. Doable. But I still think it might be a bit too soon. I don't see the urgency to move to shell functions, but I do see how they can simplify our lives. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [shell functions, was RE: solving of name conflicts inincluded.a]
> I don't see the urgency to move to shell functions, but I do > see how they can simplify our lives. Uh... "if not now, when"? Seriously, there's _always_ commercial incentive to do a half assed job and the _real_ ego competition is to reject that incentive and do a good job anyway. Ties are nooses, in a pinch. -t ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Autoconf 2.56 is released
The Autoconf team -- Akim, Alexandre, Jim, Paul, and Tom -- is happy
to annonce the birth of Autoconf 2.56, aka 2.55 with a packaging
problem fixed.
- Why should I upgrade from 2.54?
A few bug fixes, improved portability, no known incompatibility with
2.54 and 2.55, forthcoming Gettext release might require 2.55. See
below for the list of user visible changes.
Running `autoreconf -fv' should be enough.
- Why should I upgrade from 2.13?
This version is no longer maintained. It does not address recent
architectures, recent compilers etc. We know that upgrading from 2.13
to 2.5x is not an easy task, especially because the Autoconf 2.13 was
extremely tolerant to incorrect macro invocations, but waiting longer
endangers the portability of your package and only delays the
conversation to newer Autoconf versions. Worse: some maintainers now
spend a significant amount of time fixing bugs in 2.13 or backporting
macros from 2.55.
- Where can I find it?
ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.56.tar.gz (1.1 MB)
ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.56.tar.bz2 (795 KB)
ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.54-2.56.delta (7 KB)
and soon from the mirrors listed on http://www.gnu.org/order/ftp.html.
Here are the MD5 and SHA1 signatures:
0e142e9bc890786845950e84ffb52adf autoconf-2.56.tar.gz
1b0ecb66f03af3f745981c7d8bfc2a91 autoconf-2.56.tar.bz2
edcb98aa66f5c74a579109aef9cf3270 autoconf-2.55-2.56.xdelta
afff4a43d0b71a05de7b72e5a493a3e94219160c autoconf-2.56.tar.gz
5d2b082c2c76476a28a3b7bc0b537ccf6b5ad6f6 autoconf-2.56.tar.bz2
e1befdcb8d1032964021e29d6ad17975a766aa13 autoconf-2.55-2.56.xdelta
NEWS:
Release tips:
Have your configure.ac checked by autoscan ("autoscan").
Try the warning options ("autoreconf -fv -Wall").
** Documentation
- AC_CHECK_HEADER, AC_CHECK_HEADERS
More information on proper use.
- Writing Test Programs
This sections explains how to write good test sources to use with
AC_COMPILE_IFELSE etc. It documents AC_LANG_PROGRAMS and so forth.
- AC_FOO_IFELSE vs. AC_TRY_FOO
Explains why Autoconf moves from AC_TRY_COMPILE etc. to
AC_COMPILE_IFELSE and AC_LANG_PROGRAM etc.
** autoreconf
- Is more robust to different Gettext installations.
- Produces messages (when --verbose) to be understood by Emacs'
compile mode.
- Supports -W/--warnings.
- -m/--make
Once the GNU Build System reinstalled, run `./config.status
--recheck && ./config.status && make' if possible.
** autom4te
- Supports --cache, and --no-cache.
- ~/.autom4te.cfg makes it possible to disable the caching mechanism
(autom4te.cache). See `Customizing autom4te' in the documentation.
** Obsolete options
Support for the obsoleted options -m, --macrodir, -l, --localdir is
dropped in favor of the safer --include/--prepend-include scheme.
** Macros
- New macros
AC_COMPILER_IFELSE, AC_FUNC_MBRTOWC, AC_HEADER_STDBOOL,
AC_LANG_CONFTEST, AC_LANG_SOURCE, AC_LANG_PROGRAM, AC_LANG_CALL,
AC_LANG_FUNC_TRY_LINK, AC_MSG_FAILURE, AC_PREPROC_IFELSE.
- Obsoleted
Obsoleted macros are kept for Autoconf backward compatibility, but
should be avoided in configure.ac. Running autoupdate is advised.
AC_DECL_SYS_SIGLIST.
** Bug Fixes
- Portability of the Autoconf package to Solaris.
- Spurious warnings caused by config.status.
This bug is benign, but painful: on some systems (typically
FreeBSD), warnings such as:
config.status: creating Makefile
mv: Makefile: set owner/group (was: 1357/0): Operation not permitted
could be issued. This is fixed.
- Parallel Builds
Simultaneous executions of config.status are possible again.
- Precious variables accumulation
config.status could stack several copies of the precious variables
assignments.
** Plans for 2.57
- ./configure
The compatibility hooks with the old scheme will be completely
removed. Please, advice/use `--build', `--host', and `--target'
only.
- AC_CHECK_HEADER, AC_CHECK_HEADERS
The tests will be stricter, please make sure your invocations are
valid.
- shell functions
Shell functions will gradually be introduced, probably starting with
Autotest. If you know machines which are in use that you suspect
*not* to support shell functions, please run the test suite of
Autoconf 2.55 on it, and report the results to
[EMAIL PROTECTED]
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [shell functions, was RE: solving of name conflicts in included.a]
Akim Demaille <[EMAIL PROTECTED]> wrote: > Bruce> Bootstrap-Bash could use a frozen version of configure. > This means freezing at least one copy of Bash. Doable. What about someone (probably a user of a machine that actually needs it) writing a shell function inliner? ltmain.sh could be postprocessed by that on machines which need it, whilst retaining the benefit of shell functions for machines which don't. Max. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Version numbering change on IRIX
Robert, I just noticed this change 2002-10-23 Robert Boehne <[EMAIL PROTECTED]> ltmain.in: Do not add 1 to the version under IRIX, it is not necessary. in CVS libtool. I couldn't find any rationale for it in the archives, and fear that it might be a dangerous incompatible change: Consider you currently have two versions of libx.so: libx.so.1 and libx.so.2. If you rebuild your library (without any configuration change) after the libtool patch above, the current version will suddenly become libx.so.1 and overwrite that older incompatible version at installation time. This cannot really be intended? Rainer - Rainer Orth, Faculty of Technology, Bielefeld University ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
RE: Version numbering change on IRIX
Title: RE: Version numbering change on IRIX Rainer, This change was a long time coming, so many people have complained about having libx.so.1 under Solars/Linux and having libx.so.2 under IRIX. Adding 1 to the version isn't necessary, I've looked everywhere I could think of to find out why this was done in the first place, but found none. I realize this change doesn't "fix" anything, and could potentially cause problems, but these will be transient, and it is consistent with other platforms. HTH, Robert -Original Message- From: Rainer Orth [mailto:[EMAIL PROTECTED]] Sent: Friday, November 15, 2002 10:02 AM To: Robert Boehne Cc: [EMAIL PROTECTED] Subject: Version numbering change on IRIX Robert, I just noticed this change 2002-10-23 Robert Boehne <[EMAIL PROTECTED]> ltmain.in: Do not add 1 to the version under IRIX, it is not necessary. in CVS libtool. I couldn't find any rationale for it in the archives, and fear that it might be a dangerous incompatible change: Consider you currently have two versions of libx.so: libx.so.1 and libx.so.2. If you rebuild your library (without any configuration change) after the libtool patch above, the current version will suddenly become libx.so.1 and overwrite that older incompatible version at installation time. This cannot really be intended? Rainer - Rainer Orth, Faculty of Technology, Bielefeld University
RE: Version numbering change on IRIX
Robert, > This change was a long time coming, so many people have complained > about having libx.so.1 under Solars/Linux and having libx.so.2 under IRIX. > Adding 1 to the version isn't necessary, I've looked everywhere I could > think of to find out why this was done in the first place, but found > none. I realize this change doesn't "fix" anything, and could potentially > cause problems, but these will be transient, and it is consistent with > other platforms. indeed: breaking every application linked against the old (overwritten) version of affected libraries is certainly a problem. This will be transient since people will be forced to rebuild/relink every affected application; something I consider a nightmare in big installations, especially when libraries used all over the place (like the GCC runtime libraries) are affected. I can already hear the outcry from affected users and admins; I don't want to be in the position to explain to them that their applications had to be broken for cosmetic reasons and consistency with other platforms. Rainer - Rainer Orth, Faculty of Technology, Bielefeld University ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [shell functions]
On Thu, Nov 14, 2002 at 02:18:35PM -0500, Charles Wilson wrote: > [EMAIL PROTECTED] wrote: > >Bash uses configure. > > And so does ash :-( which was my first thought for working around this > problem. On the other hand, is it so terrible to ask that those who > wish to continue using systems with 20-year-old shells build bash/ash on > a modern system using a cross-compiler? Hello, I'm a bit of lurker here on the list, but I wanted to throw in my two cents on this issue. I don't have a problem with libtool using shell functions; all POSIX compliant shells are supposed to support them. The danger here is that if we make libtool dependent on some specific shell feature, do we not make any software that uses libtool dependent on that feature? The beauty of libtool is that the developer of a package doesn't need to concern herself with any platform specific issue; libtool abstracts them away. I fear their may be a backlash if now every tool that uses libtool has to include in their documentation a dependency on bash. The other concern is that some systems may have bash installed, but not as /bin/sh. If libtool depends on bash, it will need to locate it, not just assume that its in /bin or /usr/bin Thanks for listening, Christopher ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [shell functions]
Christopher Currie wrote: > I don't have a problem with libtool using shell > functions; all POSIX compliant shells are supposed to support them. The > danger here is that if we make libtool dependent on some specific shell > feature, do we not make any software that uses libtool dependent on that > feature? That's not about to happen. We're talking about moving the minimum age of the bootstrapping shell from 15+ years old to 10 or so. ;-) There would be no dependency on Bash. Maintainers of ancient hobbyiest systems would have to port some old version of bash before they could run configure and libtool. > The beauty of libtool is that the developer of a package doesn't need to > concern herself with any platform specific issue; And we are absolutely not talking about changing libtool's functionality. > The other concern is that some systems may have bash installed, but not > as /bin/sh. If libtool depends on bash, it will need to locate it, not > just assume that its in /bin or /usr/bin Of course. That's why the configure script exists. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Autoconf 2.55 is released!
Also sprach Akim Demaille: } } ** autom4te } } - Supports --cache, and --no-cache. } } - ~/.autom4te.cfg makes it possible to disable the caching mechanism } (autom4te.cache). See `Customizing autom4te' in the documentation. } This doesn't work. [dangermouse self_installed] ls -ACF autoconf-2.53/.autom4te.cfgconfigure.ac autoconf-2.53.tar.gz automake-1.6/libtool-1.4.2/ autoconf-2.55/automake-1.6.tar.gz libtool-1.4.2.tar.gz autoconf-2.55.tar.gz configure* [dangermouse self_installed] ls -ACF autoconf-2.53/.autom4te.cfgconfigure.ac autoconf-2.53.tar.gz automake-1.6/libtool-1.4.2/ autoconf-2.55/automake-1.6.tar.gz libtool-1.4.2.tar.gz autoconf-2.55.tar.gz configure* [dangermouse self_installed] cat .autom4te.cfg ## -- ## ## User Preferences. ## ## -- ## begin-language: "Autoconf" args: --no-cache end-language: "Autoconf" [dangermouse self_installed] autoconf-2.55/bin/autoconf [dangermouse self_installed] ls -ACF autoconf-2.53/autom4te.cache/ configure* autoconf-2.53.tar.gz .autom4te.cfgconfigure.ac autoconf-2.55/automake-1.6/libtool-1.4.2/ autoconf-2.55.tar.gz automake-1.6.tar.gz libtool-1.4.2.tar.gz >From the documentation: Customizing `autom4te' -- One can customize `autom4te' via `~/.autom4te.cfg' (i.e., as found in the user home directory), and `./.autom4te.cfg' (i.e., as found in the directory from which `autom4te' is run). The order is first reading `autom4te.cfg', then `~/.autom4te.cfg', then `./.autom4te.cfg', and finally the command line arguments. In these text files, comments are introduced with `#', and empty lines are ignored. Customization is performed on a per-language basis, wrapped in between a `begin-language: "LANGUAGE"', `end-language: "LANGUAGE"' pair. Customizing a language stands for appending options (*note autom4te Invocation::) to the current definition of the language. Options, and more generally arguments, are introduced by `args: ARGUMENTS'. You may use the traditional shell syntax to quote the ARGUMENTS. As an example, to disable Autoconf caches (`autom4te.cache') globally, include the following lines in `~/.autom4te.cfg': ## -- ## ## User Preferences. ## ## -- ## begin-language: "Autoconf" args: --no-cache end-language: "Autoconf" So, why does it still create that annoying autom4te.cache file? -- || Bill Wendling"Real Programmers have a Snoopy Calendar || [EMAIL PROTECTED]of '69 hanging on their wall" || Coding Simian -- Toon Moene ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Version numbering change on IRIX
On Fri, Nov 15, 2002 at 05:34:33PM +0100, Rainer Orth wrote: > Robert, > > > This change was a long time coming, so many people have complained > > about having libx.so.1 under Solars/Linux and having libx.so.2 under IRIX. > > Adding 1 to the version isn't necessary, I've looked everywhere I could > > think of to find out why this was done in the first place, but found > > none. I realize this change doesn't "fix" anything, and could potentially > > cause problems, but these will be transient, and it is consistent with > > other platforms. > > indeed: breaking every application linked against the old (overwritten) > version of affected libraries is certainly a problem. This will be > transient since people will be forced to rebuild/relink every affected > application; something I consider a nightmare in big installations, > especially when libraries used all over the place (like the GCC runtime > libraries) are affected. > > I can already hear the outcry from affected users and admins; I don't want > to be in the position to explain to them that their applications had to be > broken for cosmetic reasons and consistency with other platforms. I think Rainer has a point. This change shouldn't be made lightly. Perhaps the "add 1 for IRIX" behaviour could be made a libtool option that is ON by default? -S ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Autoconf 2.55 is released!
Congratulations! Are you handing out cigars? ;-). ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
