Re: How many spaces after a period?

[Gary V. Vaughan]

Hi Karl,

Thanks for the swift response.

On 13 Sep 2010, at 05:01, Karl Berry wrote:

> Baffled on several fronts ...
> 
>declaring `...@frenchspacing on' conversely indicates the use of a
>single space at the end of a sentence - the exact opposite of how
>the term is normally used:
> 
> No, it is not the opposite, it is the normal meaning.

You're right, @frenchspacing as implemented is quite correct; I must
have been low on caffeine when I thought otherwise.  Sorry for the
noise.

> Also, frenchspacing is definitely not the usual typographic convention
> in English-language typesetting, so I don't think GNU manuals written in
> English should use it.  Normal spacing in English is @frenchspacing off
> (the default).
> 
> Two space chars vs. one after periods in input files and typewriter-ish
> contexts like Info is not exactly the same question as frenchspacing or
> not.

Not that I'm especially opposed to double spacing, – I'd just like to
not have to be religious about requiring it unless single spaces cause
an actual problem – but if @frenchspacing is orthogonal to the use of
single spaces after a period in texinfo documents, will texinfo render
badly spaced dvi (or other) if we use single spaces after a period, or
even if we are inconsistent throughout an input document?

For example, HTML really doesn't care, and renders output consistently
no matter what spacing is used in the raw html document, and I'd be
happy to learn that texinfo is the same.

>Is there some other mandate that explains why we should go against
>modern typographical conventions and insist on double spaces?
> 
> I always thought it was (fundamentally) about Emacs as well.  That's
> what rms told me in 1985, anyway :).  At any rate, the convention ever
> since GNU started was to have two spaces at the end of sentences.  I
> never liked two spaces in my input files either, but I don't see any
> percentage in changing it now.

Well, I'm almost entirely ambivalent.  But I'd certainly like to
avoid having to count spaces during patch reviews.  If double spaces
turn out to be required in texinfo, then I'll write a maintainer
make rule to check for violations - but, if single spaces are okay
too, then we can all relax and type whatever our muscle memory prefers.

> There are plenty of other GCS "rules"/conventions which not every
> package follows, so if you can't bring yourself to type the extra space,
> the world won't come to an end.

Phew! ;-)

Cheers,
-- 
Gary V. Vaughan (g...@gnu.org)

PGP.sig
Description: This is a digitally signed message part

Re: doc: wrapping, categorizing, and indexing improvements.

[Gary V. Vaughan]

Hallo Ralf,

On 12 Sep 2010, at 21:12, Ralf Wildenhues wrote:
> I paged through the PDF version of the manual looking for long lines,
> and went through the index looking for markup errors and wrong entries
> like '(void)' stemming from wrong number of arguments to @deftypefun
> and the like: there must be a space after } in
>  @deftypefun {const char *}lt_dlgetsearchpath (void)
> 
> so that lt_dlgetsearchpath gets indexed.

Cool, thanks!

> OK to push?

Okay with nits addressed.

> diff --git a/doc/libtool.texi b/doc/libtool.texi
> index 9314612..2f30b0c 100644
> --- a/doc/libtool.texi
> +++ b/doc/libtool.texi
> @@ -510,7 +510,7 @@ to the compiler to tell it to generate PIC rather than 
> the standard
> position-dependent code.
> 
> @cindex library object file
> -...@cindex @samp{.lo} files
> +...@cindex @file{.lo} files
> @cindex object files, library
> Since this is a library implementation detail, libtool hides the
> complexity of PIC compiler flags and uses separate library object files
> @@ -585,7 +585,7 @@ pic_object='@value{objdir}/foo.o'
> non_pic_object='foo.o'
> @end example
> 
> -...@cindex -no-suppress, libtool compile mode option
> +...@cindex @option{-no-suppress}, libtool compile mode option
> Notice that the second run of GCC has its output discarded.  This is
> done so that compiler warnings aren't annoyingly duplicated.  If you
> need to see both sets of warnings (you might have conditional code
> @@ -628,7 +628,7 @@ shared libraries, libtool simply acts as a wrapper for 
> the system
> @command{ar} (and possibly @code{ranlib}) commands.
> 
> @cindex libtool libraries
> -...@cindex @samp{.la} files
> +...@cindex @file{.la} files
> Again, the libtool control file name (@samp{.la} suffix) differs from

Why the inconsistency between @file in the cindex entry, and @samp
in the body?

> the standard library name (@samp{.a} suffix).  The arguments to
> libtool are the same ones you would use to produce an executable named
> @@ -636,8 +636,8 @@ libtool are the same ones you would use to produce an 
> executable named
> 
> @example
> a23$ @kbd{libtool --mode=link gcc -g -O -o libhello.la foo.o hello.o}
> -*** Warning: Linking the shared library libhello.la against the non-libtool
> -*** objects  foo.o hello.o is not portable!
> +*** Warning: Linking the shared library libhello.la against the
> +*** non-libtool objects foo.o hello.o is not portable!
> ar cru .libs/libhello.a
> ranlib .libs/libhello.a
> creating libhello.la
> @@ -1617,7 +1617,7 @@ Pass a link-specific flag to the compiler driver 
> (@code{CC}) during linking.
> @end table
> 
> If the @var{output-file} ends in @samp{.la}, then a libtool library is
> -created, which must be built only from library objects (@samp{.lo} files).
> +created, which must be built only from library objects (@file{.lo} files).

Same here: @samp{.la} vs @file{.lo}.  If you have good reason to change
to @file, please do it everywhere.

> The @option{-rpath} option is required.  In the current implementation,
> libtool libraries may not depend on other uninstalled libtool libraries
> (@pxref{Inter-library dependencies}).
> @@ -3264,7 +3264,7 @@ library systems and simple dynamic library systems.
> Some platforms, such as AIX, do not even allow you this
> flexibility.  In order to build a shared library, it must be entirely
> self-contained (that is, have references only to symbols that are found
> -in the @samp{.lo} files or the specified @samp{-l} libraries), and you
> +in the @file{.lo} files or the specified @samp{-l} libraries), and you
> need to specify the @option{-no-undefined} flag.  By default, libtool
> builds only static libraries on these kinds of platforms.
> 
> @@ -3609,7 +3609,7 @@ intrinsics_la_LIBADD= ../libloader/libinterface.la
> cd ../libloader && $(MAKE) $(AM_MAKEFLAGS) libinterface.la
> @end example
> 
> -...@cindex -weak option
> +...@cindex @option{-weak} option
> For a more complex example, see the sources of @file{libltdl} in the
> Libtool distribution, which is built with the help of the @option{-weak}
> option.
> @@ -4039,7 +4039,7 @@ Replace the current user-defined library search path 
> with
> by @code{LT_PATHSEP_CHAR}.  Return 0 on success.
> @end deftypefun
> 
> -...@deftypefun {const char *}lt_dlgetsearchpath (void)
> +...@deftypefun {const char *} lt_dlgetsearchpath (void)
> Return the current user-defined library search path.
> @end deftypefun

Might be nicer to split spacing fixes into a separate commit than
@samp to @file conversions.  The following all belong in a spacing
fixes patch I think:

> @@ -4175,7 +4175,10 @@ Some of the internal information about each loaded 
> module that is
> maintained by libltdl is available to the user, in the form of this
> structure:
> 
> -...@deftypefn {Type} {struct} lt_dlinfo @{ @w{char *...@var{filename};} 
> @w{char *...@var{name};} @w{int @var{ref_count};} @w{int @var{is_resident};} 
> @w{int @var{is_symglobal};} @w{int @var{is_symlocal};}...@}
> +...@deftypefn {Type} {st

Re: How many spaces after a period? [WAS: Re: [PATCH 7/7] Prefer $NM @file over calculating the cmd line length.]

[Karl Berry]

Baffled on several fronts ...

declaring `...@frenchspacing on' conversely indicates the use of a
single space at the end of a sentence - the exact opposite of how
the term is normally used:

No, it is not the opposite, it is the normal meaning.  Turning on
"French" spacing means precisely that punctuation does not affect
spacing, which is also what wikipedia is saying.  That is how TeX and
Texinfo have always used the term.

Also, frenchspacing is definitely not the usual typographic convention
in English-language typesetting, so I don't think GNU manuals written in
English should use it.  Normal spacing in English is @frenchspacing off
(the default).

Two space chars vs. one after periods in input files and typewriter-ish
contexts like Info is not exactly the same question as frenchspacing or
not.

Is there some other mandate that explains why we should go against
modern typographical conventions and insist on double spaces?

I always thought it was (fundamentally) about Emacs as well.  That's
what rms told me in 1985, anyway :).  At any rate, the convention ever
since GNU started was to have two spaces at the end of sentences.  I
never liked two spaces in my input files either, but I don't see any
percentage in changing it now.

There are plenty of other GCS "rules"/conventions which not every
package follows, so if you can't bring yourself to type the extra space,
the world won't come to an end.

karl

[PATCH] * .gitignore: Ignore *.obj files for MSVC (and w32 in general).

[Peter Rosin]

Hi!

I have pushed this as obvious.

Cheers,
Peter

>From 52e86c62786b95f91f32e7020f7eaf3c1be9a59b Mon Sep 17 00:00:00 2001
From: Peter Rosin 
Date: Sun, 12 Sep 2010 18:43:11 +0200
Subject: [PATCH] * .gitignore: Ignore *.obj files for MSVC (and w32 in general).

---
 .gitignore |1 +
 ChangeLog  |2 ++
 2 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/.gitignore b/.gitignore
index e8e1bc2..bc71270 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,6 +10,7 @@
 *.lo
 *.log
 *.o
+*.obj
 *.pg
 *.toc
 *.tp
diff --git a/ChangeLog b/ChangeLog
index 0d5e54d..c7d0336 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,7 @@
 2010-09-12  Peter Rosin  
 
+   * .gitignore: Ignore *.obj files for MSVC (and w32 in general).
+
Adjust to moved auxiliary files and add compile.
* HACKING (Maintenance Notes): Adjust to moved files.  Add the
compile script.
-- 
1.7.1

Re: [PATCH] * HACKING (Maintenance Notes): Adjust to moved files.

[Peter Rosin]

Den 2010-09-11 23:18 skrev Ralf Wildenhues:
> * Peter Rosin wrote on Sat, Sep 11, 2010 at 09:02:54PM CEST:
>> I noticed that HACKING referred to files that have been moved.
>>
>> Should I also add libltdl/config/compile?
> 
> Yes, plase.
> 
>> But that one does not
>> appear to be handled by "make -fMakefile.maint fetch". Shouldn't
>> it?
> 
> It should.  Thanks.
> 
>> Which 'compile' will be bundled with libtool if libtool is
>> released before an automake is released with the latest MSVC
>> fixes for 'compile'?
> 
> That from git master Automake, just like install-sh.

Well, with the above that'is pretty obvious... :-)

>> Subject: [PATCH] * HACKING (Maintenance Notes): Adjust to moved files.
> 
> OK with above changes folded in; or you can do separate patches, as you
> prefer.

I squashed all of it in, pushed as below.  Thanks!

Cheers,
Peter

>From e61b37353e4de33b24c7cf0ecde097e0e4c32aca Mon Sep 17 00:00:00 2001
From: Peter Rosin 
Date: Sun, 12 Sep 2010 18:23:53 +0200
Subject: [PATCH] Adjust to moved auxiliary files and add compile.

* HACKING (Maintenance Notes): Adjust to moved files.  Add the
compile script.
* Makefile.maint (fetch): Also fetch the compile script.

Signed-off-by: Peter Rosin 
---
 ChangeLog  |7 +++
 HACKING|   11 ++-
 Makefile.maint |2 ++
 3 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 3cea4aa..0d5e54d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2010-09-12  Peter Rosin  
+
+   Adjust to moved auxiliary files and add compile.
+   * HACKING (Maintenance Notes): Adjust to moved files.  Add the
+   compile script.
+   * Makefile.maint (fetch): Also fetch the compile script.
+
 2010-09-12  Ralf Wildenhues  
 
tests: avoid empty AT_DATA contents, for zsh.
diff --git a/HACKING b/HACKING
index b462c98..e9184f2 100644
--- a/HACKING
+++ b/HACKING
@@ -28,7 +28,12 @@ and is not part of a release distribution.
   files should never be edited here.  These files are:
COPYING
INSTALL
-   config/
+   doc/
+   + fdl.texi
+   libltdl/
+   + COPYING.LIB
+   libltdl/config/
+   + compile
+ config.guess
+ config.sub
+ depcomp
@@ -36,10 +41,6 @@ and is not part of a release distribution.
+ mdate-sh
+ missing
+ texinfo.tex
-   doc/
-   + fdl.texi
-   libltdl/
-   + COPYING.LIB
   The ones that are important for a release can be udated with,
   `make -fMakefile.maint fetch' (or `make -f../Makefile.maint fetch'
   if you are running from a VPATH build directory, where `../' is the
diff --git a/Makefile.maint b/Makefile.maint
index 64abde6..784b155 100644
--- a/Makefile.maint
+++ b/Makefile.maint
@@ -88,6 +88,7 @@ WGET_CGIT = $(WGET) 
'http://git.savannah.gnu.org/cgit/config.git/plain'
 ## FIXME should be a lot more here
 FETCHFILES = \
 ./INSTALL \
+$(auxdir)/compile \
 $(auxdir)/install-sh \
 $(auxdir)/config.guess \
 $(auxdir)/config.sub \
@@ -101,6 +102,7 @@ fetch:
 ## If a get fails then that is a problem.
(cd Fetchdir && \
$(WGET_GIT)'gnulib.git;f=doc/INSTALL' -O INSTALL && \
+   $(WGET_GIT)'automake.git;f=lib/compile' -O compile && \
$(WGET_GIT)'automake.git;f=lib/install-sh' -O install-sh && \
$(WGET_CGIT)/config.guess -O config.guess && \
$(WGET_CGIT)/config.sub -O config.sub && \
-- 
1.7.1

tests: avoid empty AT_DATA contents, for zsh.

[Ralf Wildenhues]

This fixes the remaining testsuite failures with zsh 4.3.10 on FreeBSD.

cat >file expout
 
 LT_AT_CHECK_LIBTOOLIZE([--copy], 0, expout)
 
@@ -232,7 +232,7 @@ LT_AT_CHECK_LIBTOOLIZE([--copy --install], 0, expout, 
experr)
 ## Next, a second update attempt with everything now updated. ##
 ## -- ##
 
-AT_DATA(expout, [[]])
+: >expout
 
 AT_DATA(experr,
 [[libtoolize: `build-aux/ltmain.sh' is newer: use `--force' to overwrite
@@ -267,7 +267,7 @@ LT_AT_CHECK_LIBTOOLIZE([--copy --force --install], 0, 
expout)
 ## A final update attempt with everything previously force updated. ##
 ##  ##
 
-AT_DATA(expout, [[]])
+: >expout
 
 LT_AT_CHECK_LIBTOOLIZE([--copy --install], 0, expout)
 
@@ -978,7 +978,7 @@ LT_AT_CHECK_LIBTOOLIZE([--copy], 0, [ignore], experr)
 LIBTOOLIZE_OPTIONS=--no-warn,--no-such-option
 export LIBTOOLIZE_OPTIONS
 
-AT_DATA(experr, [[]])
+: >experr
 
 LT_AT_CHECK_LIBTOOLIZE([--copy], 0, [ignore], experr)
 

Re: [PATCH] [cygwin|mingw] Correct static lib symbol extraction failure.

[Charles Wilson]

On 9/12/2010 10:20 AM, Ralf Wildenhues wrote:
> I suggest you commit it so that it can be included
> in the testing.

Pushed as:

When assigning $linklib value, honor [-all]-static[-libtool-libs]

* libltdl/config/ltmain.m4sh (func_mode_link): When prefer_static_libs
and static library exists, ensure old_library name is used as $linklib.
Fixes failure on mingw when both static and shared libraries are
present.

---
 ChangeLog  |9 +
 libltdl/config/ltmain.m4sh |   12 +---
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index b9abe8a..6b76340 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2010-09-12  Charles Wilson  <...>
+
+   When assigning $linklib value, honor [-all]-static[-libtool-libs]
+
+   * libltdl/config/ltmain.m4sh (func_mode_link): When prefer_static_libs
+   and static library exists, ensure old_library name is used as $linklib.
+   Fixes failure on mingw when both static and shared libraries are
+   present.
+
 2010-09-12  Ralf Wildenhues  <...>

tests: work around zsh use of $options variable.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 509a421..6036f4f 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -5652,9 +5652,15 @@ func_mode_link ()

# Get the name of the library we link against.
linklib=
-   for l in $old_library $library_names; do
- linklib="$l"
-   done
+   if test -n "$old_library" &&
+  { test "$prefer_static_libs" = yes ||
+test "$prefer_static_libs,$installed" = "built,no"; }; then
+ linklib=$old_library
+   else
+ for l in $old_library $library_names; do
+   linklib="$l"
+ done
+   fi
if test -z "$linklib"; then
  func_fatal_error "cannot find name of link library for \`$lib'"
fi
-- 
1.7.1

Re: [PATCH] [cygwin|mingw] Correct static lib symbol extraction failure.

[Charles Wilson]

On 9/12/2010 10:25 AM, Ralf Wildenhues wrote:
> Also, $linklib is used for several other things.  It would seem prudent
> to make sure it is clear that this is a very intrusive patch, or use
> another helper variable to make it less intrusive.

Oh, I think linklib was *wrong* no matter what.  If you requested static
(either via -static, -all-static, or -static-libtool-libs), AND you have
an $old_library name...then by golly you ARE going to link against that
$old_library.

So, when assigning $linklib, you really should take into consideration
all those factors.  Prior to this patch, $linklib was always set to the
last element of $library_names -- and was only set to $old_library if
there WERE no dynamic libs, and all you HAD was the static lib.  It
didn't care about the various -static options AT ALL.

--
Chuck

Re: [PATCH] [cygwin|mingw] Correct static lib symbol extraction failure.

[Charles Wilson]

On 9/12/2010 10:20 AM, Ralf Wildenhues wrote:
> Hi Charles,
> 
> * Charles Wilson wrote on Sun, Sep 12, 2010 at 03:19:51PM CEST:
>> * libltdl/config/ltmain.m4sh (func_mode_link): When prefer_static_libs,
>> ensure old_library name is used as linklib when possible.
>> ---
>> This patch corrects the (long-standing?) failure of mdemo-exec.test on
>> mingw, but also some non-fatal anomalies in cygwin on the same tests.
>> Basically, when dlopen'ing static libraries, but when both shared and
>> static libs exist, the extracted symbol names put into the
>> lt__PROGRAM__LTX_preloaded_symbols array were mistakenly extracted from
>> the import library instead of the static one.  For PE/COFF, this makes
>> a difference; and on mingw that difference caused the mdemo_static test
>> to fail.
> 
> Why does the patch have "[cygwin|mingw]" in the summary?  It changes a
> code path that is shared by most systems out there, no?  I'd rather see
> a 'Fixes foo on Cygwin and MinGW' in the details, so that when searching
> the summary log later, this patch isn't mistaken for a w32-only one.

OK, I'll change the summary before committing.

> I think the patch is right, but this is one that *really* needs wide
> range testing on several hosts.  Since I'm about to tick off another
> round of testing, I suggest you commit it so that it can be included
> in the testing.

OK.

--
Chuck

tests: work around zsh use of $options variable.

[Ralf Wildenhues]

../../libtool/tests/getopt-m4sh.at:93: $SHELL ./options -fvi
+ /usr/local/bin/zsh ./options -fvi
--- /dev/null   2010-09-12 14:28:42.575801479 +
+++ /tmp/build/tests/testsuite.dir/at-groups/1/stderr 2010-09-12 
14:28:42.634930285 +
@@ -0,0 +1,2 @@
+./options:950: options: attempt to set associative array to scalar
+./options:981: options: attempt to set associative array to scalar
--- expout  2010-09-12 14:28:41.558461981 +
+++ /tmp/build/tests/testsuite.dir/at-groups/1/stdout 2010-09-12 
14:28:42.560506110 +
@@ -1 +0,0 @@
- force verbose install
../../libtool/tests/getopt-m4sh.at:93: exit code was 1, expected 0
1. getopt-m4sh.at:85:  FAILED (getopt-m4sh.at:93)


Fixed as below, fixing test failures 1-6.  There are still failures of
9, 10, and 19 with this shell, but I haven't analyzed them yet.

I still need to write a patch for autoconf.texi, but for that I'd like
a confirmation from the man page.  Try finding something related to
"\" quickly ...  :-/

Cheers,
Ralf

tests: work around zsh use of $options variable.

* tests/getopt-m4sh.at: Rename $options to $opts, the former is
special for zsh 4.3.10.

diff --git a/tests/getopt-m4sh.at b/tests/getopt-m4sh.at
index 1c2ac26..75a7bf6 100644
--- a/tests/getopt-m4sh.at
+++ b/tests/getopt-m4sh.at
@@ -37,14 +37,14 @@ AT_DATA([options.m4sh],
 nl='
 '
 list=
-options=
+opts=
 M4SH_GETOPTS(
   [a!],[--append], [], [func_append list "$optarg$nl"],
-  [f], [--force],  [], [options="$options force"],
-  [i], [--install],[], [options="$options install"],
-  [v], [--verbose],[], [options="$options verbose"],
-  [!], [--ltdl],   [false],[options="$options ltdl=$optarg"],
-[echo "$list" $options])
+  [f], [--force],  [], [opts="$opts force"],
+  [i], [--install],[], [opts="$opts install"],
+  [v], [--verbose],[], [opts="$opts verbose"],
+  [!], [--ltdl],   [false],[opts="$opts ltdl=$optarg"],
+[echo "$list" $opts])
 ]])
 m4_pattern_forbid([m4_include])
 m4_pattern_forbid([AS_INIT])

Re: [PATCH] [cygwin|mingw] Correct static lib symbol extraction failure.

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Sun, Sep 12, 2010 at 04:20:13PM CEST:
> * Charles Wilson wrote on Sun, Sep 12, 2010 at 03:19:51PM CEST:
> > * libltdl/config/ltmain.m4sh (func_mode_link): When prefer_static_libs,
> > ensure old_library name is used as linklib when possible.

> Why does the patch have "[cygwin|mingw]" in the summary?  It changes a
> code path that is shared by most systems out there, no?  I'd rather see
> a 'Fixes foo on Cygwin and MinGW' in the details, so that when searching
> the summary log later, this patch isn't mistaken for a w32-only one.

Also, $linklib is used for several other things.  It would seem prudent
to make sure it is clear that this is a very intrusive patch, or use
another helper variable to make it less intrusive.

Cheers,
Ralf

Re: [PATCH] [cygwin|mingw] Correct static lib symbol extraction failure.

[Ralf Wildenhues]

Hi Charles,

* Charles Wilson wrote on Sun, Sep 12, 2010 at 03:19:51PM CEST:
> * libltdl/config/ltmain.m4sh (func_mode_link): When prefer_static_libs,
> ensure old_library name is used as linklib when possible.
> ---
> This patch corrects the (long-standing?) failure of mdemo-exec.test on
> mingw, but also some non-fatal anomalies in cygwin on the same tests.
> Basically, when dlopen'ing static libraries, but when both shared and
> static libs exist, the extracted symbol names put into the
> lt__PROGRAM__LTX_preloaded_symbols array were mistakenly extracted from
> the import library instead of the static one.  For PE/COFF, this makes
> a difference; and on mingw that difference caused the mdemo_static test
> to fail.

Why does the patch have "[cygwin|mingw]" in the summary?  It changes a
code path that is shared by most systems out there, no?  I'd rather see
a 'Fixes foo on Cygwin and MinGW' in the details, so that when searching
the summary log later, this patch isn't mistaken for a w32-only one.

I think the patch is right, but this is one that *really* needs wide
range testing on several hosts.  Since I'm about to tick off another
round of testing, I suggest you commit it so that it can be included
in the testing.

And thanks for tracking this down!

Cheers,
Ralf

doc: wrapping, categorizing, and indexing improvements.

[Ralf Wildenhues]

I paged through the PDF version of the manual looking for long lines,
and went through the index looking for markup errors and wrong entries
like '(void)' stemming from wrong number of arguments to @deftypefun
and the like: there must be a space after } in
  @deftypefun {const char *}lt_dlgetsearchpath (void)

so that lt_dlgetsearchpath gets indexed.

OK to push?

Thanks,
Ralf

doc: wrapping, categorizing, and indexing improvements.

* doc/libtool.texi (Creating object files, Linking libraries)
(Link mode, Inter-library dependencies)
(Linking with dlopened modules, Libltdl interface)
(User defined module data, Module loaders for libltdl)
(Cheap tricks): Some texinfo markup and indexing fixes, wrapping
of long lines in input and output.

diff --git a/doc/libtool.texi b/doc/libtool.texi
index 9314612..2f30b0c 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -510,7 +510,7 @@ to the compiler to tell it to generate PIC rather than the 
standard
 position-dependent code.
 
 @cindex library object file
-...@cindex @samp{.lo} files
+...@cindex @file{.lo} files
 @cindex object files, library
 Since this is a library implementation detail, libtool hides the
 complexity of PIC compiler flags and uses separate library object files
@@ -585,7 +585,7 @@ pic_object='@value{objdir}/foo.o'
 non_pic_object='foo.o'
 @end example
 
-...@cindex -no-suppress, libtool compile mode option
+...@cindex @option{-no-suppress}, libtool compile mode option
 Notice that the second run of GCC has its output discarded.  This is
 done so that compiler warnings aren't annoyingly duplicated.  If you
 need to see both sets of warnings (you might have conditional code
@@ -628,7 +628,7 @@ shared libraries, libtool simply acts as a wrapper for the 
system
 @command{ar} (and possibly @code{ranlib}) commands.
 
 @cindex libtool libraries
-...@cindex @samp{.la} files
+...@cindex @file{.la} files
 Again, the libtool control file name (@samp{.la} suffix) differs from
 the standard library name (@samp{.a} suffix).  The arguments to
 libtool are the same ones you would use to produce an executable named
@@ -636,8 +636,8 @@ libtool are the same ones you would use to produce an 
executable named
 
 @example
 a23$ @kbd{libtool --mode=link gcc -g -O -o libhello.la foo.o hello.o}
-*** Warning: Linking the shared library libhello.la against the non-libtool
-*** objects  foo.o hello.o is not portable!
+*** Warning: Linking the shared library libhello.la against the
+*** non-libtool objects foo.o hello.o is not portable!
 ar cru .libs/libhello.a
 ranlib .libs/libhello.a
 creating libhello.la
@@ -1617,7 +1617,7 @@ Pass a link-specific flag to the compiler driver 
(@code{CC}) during linking.
 @end table
 
 If the @var{output-file} ends in @samp{.la}, then a libtool library is
-created, which must be built only from library objects (@samp{.lo} files).
+created, which must be built only from library objects (@file{.lo} files).
 The @option{-rpath} option is required.  In the current implementation,
 libtool libraries may not depend on other uninstalled libtool libraries
 (@pxref{Inter-library dependencies}).
@@ -3264,7 +3264,7 @@ library systems and simple dynamic library systems.
 Some platforms, such as AIX, do not even allow you this
 flexibility.  In order to build a shared library, it must be entirely
 self-contained (that is, have references only to symbols that are found
-in the @samp{.lo} files or the specified @samp{-l} libraries), and you
+in the @file{.lo} files or the specified @samp{-l} libraries), and you
 need to specify the @option{-no-undefined} flag.  By default, libtool
 builds only static libraries on these kinds of platforms.
 
@@ -3609,7 +3609,7 @@ intrinsics_la_LIBADD= ../libloader/libinterface.la
 cd ../libloader && $(MAKE) $(AM_MAKEFLAGS) libinterface.la
 @end example
 
-...@cindex -weak option
+...@cindex @option{-weak} option
 For a more complex example, see the sources of @file{libltdl} in the
 Libtool distribution, which is built with the help of the @option{-weak}
 option.
@@ -4039,7 +4039,7 @@ Replace the current user-defined library search path with
 by @code{LT_PATHSEP_CHAR}.  Return 0 on success.
 @end deftypefun
 
-...@deftypefun {const char *}lt_dlgetsearchpath (void)
+...@deftypefun {const char *} lt_dlgetsearchpath (void)
 Return the current user-defined library search path.
 @end deftypefun
 
@@ -4175,7 +4175,10 @@ Some of the internal information about each loaded 
module that is
 maintained by libltdl is available to the user, in the form of this
 structure:
 
-...@deftypefn {Type} {struct} lt_dlinfo @{ @w{char *...@var{filename};} 
@w{char *...@var{name};} @w{int @var{ref_count};} @w{int @var{is_resident};} 
@w{int @var{is_symglobal};} @w{int @var{is_symlocal};}...@}
+...@deftypefn {Type} {struct} lt_dlinfo @{ @w{char *...@var{filename};} @
+  @w{char *...@var{name};} @w{int @var{ref_count};} @
+  @w{int @var{is_resident};} @w{int @var{is_symglobal};} @
+  @w{int @var{is_sy

[PATCH] [cygwin|mingw] Correct static lib symbol extraction failure.

[Charles Wilson]

* libltdl/config/ltmain.m4sh (func_mode_link): When prefer_static_libs,
ensure old_library name is used as linklib when possible.
---
This patch corrects the (long-standing?) failure of mdemo-exec.test on
mingw, but also some non-fatal anomalies in cygwin on the same tests.
Basically, when dlopen'ing static libraries, but when both shared and
static libs exist, the extracted symbol names put into the
lt__PROGRAM__LTX_preloaded_symbols array were mistakenly extracted from
the import library instead of the static one.  For PE/COFF, this makes
a difference; and on mingw that difference caused the mdemo_static test
to fail.

Test results:

cygwin
--
old test suite: All 122 tests passed (2 tests were not run)
new test suite: 111 tests behaved as expected. 9 tests were skipped.

mingw
-
old test suite: All 122 tests passed (2 tests were not run)
new test suite: 108 tests behaved as expected. 12 tests were skipped.

OK to push?

--
Chuck


 libltdl/config/ltmain.m4sh |   12 +---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index d8e0fe1..6ae2e43 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -5650,9 +5650,15 @@ func_mode_link ()
 
# Get the name of the library we link against.
linklib=
-   for l in $old_library $library_names; do
- linklib="$l"
-   done
+   if test -n "$old_library" &&
+  { test "$prefer_static_libs" = yes ||
+test "$prefer_static_libs,$installed" = "built,no"; }; then
+ linklib=$old_library
+   else
+ for l in $old_library $library_names; do
+   linklib="$l"
+ done
+   fi
if test -z "$linklib"; then
  func_fatal_error "cannot find name of link library for \`$lib'"
fi
-- 
1.7.1

Fix AC_NO_EXECUTABLES test failure on IRIX 6.5.

[Ralf Wildenhues]

I'm pushing this bugfix to fix this failure on IRIX with GCC
(log already expired; Simon bumped the timeout to 24 days now):

../../libtool/tests/no-executables.at:75: : ${CONFIG_SHELL=/bin/sh}; export CONF
IG_SHELL; $CONFIG_SHELL ./configure $configure_options 
stderr:
configure: WARNING: using cross tools not prefixed with host triplet
configure: error: link tests are not allowed after AC_NO_EXECUTABLES
stdout:
checking for gcc... /opt/fsw/gcc42/bin/gcc
checking whether we are cross compiling... yes
[...]
checking if /opt/fsw/gcc42/bin/gcc supports -c -o file.o... (cached) yes
checking whether the /opt/fsw/gcc42/bin/gcc linker (/bin/ld -n32 -n32) supports 
shared libraries... ../../libtool/tests/no-executables.at:75: exit code was 1, e
xpected 0
105. no-executables.at:25: 105. AC_NO_EXECUTABLES (no-executables.at:25): FAILED
 (no-executables.at:75)

The patch introduces some intermixing of configure output, but that's
already there on some other hosts, less critical to fix

Cheers,
Ralf

Fix AC_NO_EXECUTABLES test failure on IRIX 6.5.

* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) [irix]: Cache result
of link check for -Wl,-exported_symbol.
* tests/no-executables.at (AC_NO_EXECUTABLES): Set
lt_cv_irix_exported_symbol, to avoid link check.

diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 895f28d..bbe8c82 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -5183,21 +5183,27 @@ _LT_EOF
# Try to use the -exported_symbol ld option, if it does not
# work, assume that -exports_file does not work either and
# implicitly export all symbols.
-save_LDFLAGS="$LDFLAGS"
-LDFLAGS="$LDFLAGS -shared ${wl}-exported_symbol ${wl}foo 
${wl}-update_registry ${wl}/dev/null"
-AC_LINK_IFELSE(
-  [AC_LANG_SOURCE(
-[AC_LANG_CASE([C], [[int foo (void) { return 0; }]],
-  [C++], [[int foo (void) { return 0; }]],
-  [Fortran 77], [[
-   subroutine foo
-   end]],
-  [Fortran], [[
-   subroutine foo
-   end]])])], [
+   # This should be the same for all languages, so no per-tag cache 
variable.
+   AC_CACHE_CHECK([whether the $host_os linker accepts -exported_symbol],
+ [lt_cv_irix_exported_symbol],
+ [save_LDFLAGS="$LDFLAGS"
+  LDFLAGS="$LDFLAGS -shared ${wl}-exported_symbol ${wl}foo 
${wl}-update_registry ${wl}/dev/null"
+  AC_LINK_IFELSE(
+[AC_LANG_SOURCE(
+   [AC_LANG_CASE([C], [[int foo (void) { return 0; }]],
+ [C++], [[int foo (void) { return 0; }]],
+ [Fortran 77], [[
+  subroutine foo
+  end]],
+ [Fortran], [[
+  subroutine foo
+  end]])])],
+ [lt_cv_irix_exported_symbol=yes],
+ [lt_cv_irix_exported_symbol=no])
+   LDFLAGS="$save_LDFLAGS"])
+   if test "$lt_cv_irix_exported_symbol" = yes; then
   _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag $libobjs 
$deplibs $compiler_flags ${wl}-soname ${wl}$soname `test -n "$verstring" && 
func_echo_all "${wl}-set_version ${wl}$verstring"` ${wl}-update_registry 
${wl}${output_objdir}/so_locations ${wl}-exports_file ${wl}$export_symbols -o 
$lib'
-])
-LDFLAGS="$save_LDFLAGS"
+   fi
   else
_LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs 
$compiler_flags -soname $soname `test -n "$verstring" && func_echo_all 
"-set_version $verstring"` -update_registry ${output_objdir}/so_locations -o 
$lib'
_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $libobjs $deplibs 
$compiler_flags -soname $soname `test -n "$verstring" && func_echo_all 
"-set_version $verstring"` -update_registry ${output_objdir}/so_locations 
-exports_file $export_symbols -o $lib'
diff --git a/tests/no-executables.at b/tests/no-executables.at
index 75b92ef..bcc9cf2 100644
--- a/tests/no-executables.at
+++ b/tests/no-executables.at
@@ -52,6 +52,7 @@ lt_cv_cc_needs_belf=no
 lt_cv_ld_exported_symbols_list=no
 lt_cv_prog_compiler_static_works=no
 lt_cv_aix_libpath="/usr/lib:/lib"
+lt_cv_irix_exported_symbol=yes
 
 # Deal with AC_LIBTOOL_DLOPEN in one of two possible ways:
 # - do not execute it at all in the ac_no_link case

Re: test with old autotools

[Ralf Wildenhues]

* Gary V. Vaughan wrote on Sun, Sep 12, 2010 at 12:58:23PM CEST:
> On 12 Sep 2010, at 17:47, Ralf Wildenhues wrote:
> > <0001-Try-out-new-testsuite-with-old-Autoconf-and-Automake.patch>
> 
> You forgot to `git add tests/old-autoconf.at' before you generated the
> patch though...

D'oh.  That's what you get trying to get something done on the run for
lunch ... thanks for checking.

Cheers,
Ralf
>From b6c48292197a756cd0411dcb6635120272665711 Mon Sep 17 00:00:00 2001
From: Ralf Wildenhues 
Date: Sun, 12 Sep 2010 12:45:44 +0200
Subject: [PATCH] Try out new testsuite with old Autoconf and Automake versions.

* tests/old-autotools.at (old autoconf and automake): New file,
new test.
* Makefile.am (TESTSUITE_AT): Update.
* doc/libtool.texi (Test descriptions): Document new Autotest
keywords `expensive' and `net-access'.
* HACKING: Likewise; also document `interactive'.
Suggested by Gary V. Vaughan.

Signed-off-by: Ralf Wildenhues 
---
 ChangeLog  |   11 ++
 HACKING|7 +++-
 Makefile.am|1 +
 doc/libtool.texi   |9 +
 tests/old-autotools.at |   81 
 5 files changed, 107 insertions(+), 2 deletions(-)
 create mode 100644 tests/old-autotools.at

diff --git a/ChangeLog b/ChangeLog
index 4584882..d6fb995 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2010-09-12  Ralf Wildenhues  
+
+   Try out new testsuite with old Autoconf and Automake versions.
+   * tests/old-autotools.at (old autoconf and automake): New file,
+   new test.
+   * Makefile.am (TESTSUITE_AT): Update.
+   * doc/libtool.texi (Test descriptions): Document new Autotest
+   keywords `expensive' and `net-access'.
+   * HACKING: Likewise; also document `interactive'.
+   Suggested by Gary V. Vaughan.
+
 2010-09-12  Jürgen Reuter(tiny 
change)
Ralf Wildenhues  
 
diff --git a/HACKING b/HACKING
index b462c98..277a011 100644
--- a/HACKING
+++ b/HACKING
@@ -65,11 +65,14 @@ and is not part of a release distribution.
 * The new Autotest testsuite uses keywords to denote test features:
 autoconf   needs Autoconf
 automake   needs Automake
+expensive  very expensive test (only enabled if the environment
+   variable RUN_EXPENSIVE_TESTS is set)
+interactivemight cause popup windows from the system
 libltdlexercises the `libltdl' library
 libtoolexercises the `libtool' script
 libtoolize exercises the `libtoolize' script
-recursive  runs the suite recursively, with a modified
-   `libtool' script and with `-k libtool'
+net-access might download files from the GNU website
+recursive  runs the suite recursively
 CXX F77 FC GCJ exercises a language other than C
 
 
diff --git a/Makefile.am b/Makefile.am
index dcd0876..ff8a225 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -499,6 +499,7 @@ TESTSUITE_AT= tests/testsuite.at \
  tests/stresstest.at \
  tests/cmdline_wrap.at \
  tests/pic_flag.at \
+ tests/old-autotools.at \
  tests/darwin.at \
  tests/deplibs-mingw.at \
  tests/sysroot.at
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 9314612..91f98e8 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -5463,6 +5463,11 @@ by the test group.  The tests are typically skipped if 
the program is
 not installed.  The @samp{automake} keyword may also denote use of the
 @command{aclocal} program.
 
+...@item expensive
+This test group is very expensive, and skipped unless the environment
+variable @env{RUN_EXPENSIVE_TESTS} is also set.  Do not do this unless
+you know what you are doing!
+
 @item interactive
 This test group may require user interaction on some systems.  Typically,
 this means closing a popup window about a DLL load error on Windows.
@@ -5475,6 +5480,10 @@ Denote that the @file{libltdl} library is exercised by 
the test group.
 Denote that the @command{libtool} or @command{libtoolize} scripts are
 exercised by the test group, respectively.
 
+...@item net-access
+This test group might access the internet to download files from GNU
+servers.
+
 @item recursive
 Denote that this test group may recursively re-invoke the test suite
 itself, with changed settings and maybe a changed @command{libtool}
diff --git a/tests/old-autotools.at b/tests/old-autotools.at
new file mode 100644
index 000..f0aa5ce
--- /dev/null
+++ b/tests/old-autotools.at
@@ -0,0 +1,81 @@
+# old-autotools.at -- try running with old Autoconf and Automake -*- Autotest 
-*-
+
+#   Copyright (C) 2010 Free Software Foundation, Inc.
+#
+#   This file is part of GNU Libtool.
+#
+# GNU Libtool is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free 

Re: test with old autotools (was: [PATCH 1/6] Require Automake 1.11.1 for Libtool, enable color-tests.)

[Gary V. Vaughan]

On 12 Sep 2010, at 17:47, Ralf Wildenhues wrote:
> you wanted a way to test old Autoconf and Automake with a git Libtool
> tree:

Awesome, thanks :)

> [[snip]]
> At this point, I'm not actually asking to commit this now.  Consider it
> a test balloon that you could use in your git tree to test things.  :-)
> 
> Cheers,
> Ralf
> <0001-Try-out-new-testsuite-with-old-Autoconf-and-Automake.patch>

You forgot to `git add tests/old-autoconf.at' before you generated the
patch though...

Cheers,
-- 
Gary V. Vaughan (g...@gnu.org)


PGP.sig
Description: This is a digitally signed message part

test with old autotools (was: [PATCH 1/6] Require Automake 1.11.1 for Libtool, enable color-tests.)

[Ralf Wildenhues]

Hello Gary,

you wanted a way to test old Autoconf and Automake with a git Libtool
tree:

* Gary V. Vaughan wrote on Sun, Aug 22, 2010 at 05:41:52PM CEST:
> On 22 Aug 2010, at 22:30, Ralf Wildenhues wrote:
> > * Gary V. Vaughan wrote on Sun, Aug 22, 2010 at 05:24:05PM CEST:
> >> Of course, that doesn't test the patch series you haven't
> >> pushed yet...
> > 
> > Just add 'git checkout origin/parallel-tests'.
> 
> I meant that if I want to check that my next round of m4sh patches
> don't break with older Autotools before I push, this script doesn't
> help, since it wants a fresh libtool checkout.  The script would
> be more useful if it can be run inside a dirty working directory.
> 
> >> And running it as an Autotest inside the existing tree would
> >> get us better coverage, and obviate the need for a separate
> >> checkout of the libtool tree entirely.
> > 
> > Sure.  But look at the existing sort-of-recursive tests.  They are
> > tricky.  I am waiting for the day where we add infinite recursion in
> > some corner case and have developers complain.
> 
> Actually, I've not looked at the details of those recursive tests,
> so I must admit that I don't know how tricky they are.  I just
> assumed that we could reuse that pattern here.
> 
> > The net is abundant now, I think such test helper scripts are a real
> > easy way to get more coverage, but I don't think it is necessary to
> > run them as part of each testsuite run, because they are very expensive.
> 
> A very good point.  Maybe we should add a 'maintainer-test' target or
> similar, which executes this and other expensive test-helper scripts
> in addition to the regular testsuite(s). And it's also worth considering
> migrating our other recursive tests to helper scripts too in that case.

I haven't done that yet; but in the end, that might actually be a better
idea than what I hacked up for now:

This patch checks whether $AUTOCONF and $AUTOMAKE point to the oldest
versions we aim to support, otherwise downloads repective release
tarballs, builds and installs them temporarily below a subdirectory in
the test group, then runs those parts of the new testsuite recursively
which use autoconf.  The old testsuite is not dealt with.

While debugging the patch, I did run into an endless recursion or two.
The test is fragile in that it might need updating when we add more
environment variables that influence general test behavior.

At this point, I'm not actually asking to commit this now.  Consider it
a test balloon that you could use in your git tree to test things.  :-)

Cheers,
Ralf
>From e9930b5cf137500b2c08ceb3e3819dfbc6404be0 Mon Sep 17 00:00:00 2001
From: Ralf Wildenhues 
Date: Sun, 12 Sep 2010 12:45:44 +0200
Subject: [PATCH] Try out new testsuite with old Autoconf and Automake versions.

* tests/old-autotools.at (old autoconf and automake): New file,
new test.
* Makefile.am (TESTSUITE_AT): Update.
* doc/libtool.texi (Test descriptions): Document new Autotest
keywords `expensive' and `net-access'.
* HACKING: Likewise; also document `interactive'.
Suggested by Gary V. Vaughan.

Signed-off-by: Ralf Wildenhues 
---
 ChangeLog|   11 +++
 HACKING  |7 +--
 Makefile.am  |1 +
 doc/libtool.texi |9 +
 4 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 4584882..d6fb995 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2010-09-12  Ralf Wildenhues  
+
+   Try out new testsuite with old Autoconf and Automake versions.
+   * tests/old-autotools.at (old autoconf and automake): New file,
+   new test.
+   * Makefile.am (TESTSUITE_AT): Update.
+   * doc/libtool.texi (Test descriptions): Document new Autotest
+   keywords `expensive' and `net-access'.
+   * HACKING: Likewise; also document `interactive'.
+   Suggested by Gary V. Vaughan.
+
 2010-09-12  Jürgen Reuter(tiny 
change)
Ralf Wildenhues  
 
diff --git a/HACKING b/HACKING
index b462c98..277a011 100644
--- a/HACKING
+++ b/HACKING
@@ -65,11 +65,14 @@ and is not part of a release distribution.
 * The new Autotest testsuite uses keywords to denote test features:
 autoconf   needs Autoconf
 automake   needs Automake
+expensive  very expensive test (only enabled if the environment
+   variable RUN_EXPENSIVE_TESTS is set)
+interactivemight cause popup windows from the system
 libltdlexercises the `libltdl' library
 libtoolexercises the `libtool' script
 libtoolize exercises the `libtoolize' script
-recursive  runs the suite recursively, with a modified
-   `libtool' script and with `-k libtool'
+net-access might download files from the GNU website
+recursive  runs the suite recursively
 CXX F77 FC GCJ exercises a language other than C
 
 
diff --git a/Makefile.am b/Makefile.am
index dcd0876..f

Re: static FORTRAN compilation set-up in libtool.m4

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Thu, Sep 02, 2010 at 07:41:25PM CEST:
> That's fine.  Any support for nagfor is an improvement over no support.

I've pushed the patch below to git master of Libtool now.
Please test as described before, if at all possible.

I changed the pic flag to -PIC so also large codes will work.  If you
need to use -pic for more efficiency, set lt_cv_prog_compiler_pic_F77
and/or ..._FC on the configure command line to override this.

(The "(tiny change)" just denotes that no copyright papers have been
signed.)

Thanks,
Ralf

2010-09-12  Jürgen Reuter(tiny 
change)
Ralf Wildenhues  

Initial support for the NAG Fortran compiler on GNU/Linux.
* libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux] :
New set of entries, for NAG Fortran 5.1 and 5.2.
* NEWS: Update.

diff --git a/NEWS b/NEWS
index 5a2531c..1d4419b 100644
--- a/NEWS
+++ b/NEWS
@@ -36,6 +36,7 @@ New in 2.2.12 2010-08-??: git version 2.2.11a, Libtool team:
 variable MANIFEST_TOOL. Please note that the import library naming
 has changed (from foo-2.lib to foo.dll.lib) from when the code lived
 in its own git branch.
+  - Initial support for the NAG Fortran compiler on GNU/Linux.
 
 * Bug fixes:
 
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 895f28d..a9e91f6 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4247,6 +4247,12 @@ m4_if([$1], [CXX], [
_LT_TAGVAR(lt_prog_compiler_pic, $1)='--shared'
_LT_TAGVAR(lt_prog_compiler_static, $1)='--static'
;;
+  nagfor*)
+   # NAG Fortran compiler
+   _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,-Wl,,'
+   _LT_TAGVAR(lt_prog_compiler_pic, $1)='-PIC'
+   _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+   ;;
   pgcc* | pgf77* | pgf90* | pgf95* | pgfortran*)
 # Portland Group compilers (*not* the Pentium gcc compiler,
# which looks to be a dead project)

Re: getopt-m4sh tests failures with autom4te 2.61

[Gary V. Vaughan]

On 12 Sep 2010, at 16:42, Ralf Wildenhues wrote:
> * Ralf Wildenhues wrote on Thu, Sep 02, 2010 at 10:36:54PM CEST:
>> Hi Gary,

Hallo Ralf,

Sorry I didn't see the original yet... I still have 400 emails backed up
in my Inbox. :(

>> I get testsuite failures of the first six tests with autom4te 2.61 early
>> in PATH (the testsuite itself has been created with 2.67).  See below
>> for an example failure.  Maybe getopt-m4sh.at really relies on >= 2.62?

Yes, you're right.  I had thought my ~/old-autotools/bin had 2.61
installed, but it turns out that it was 2.62 all along, which is 
why I haven't experienced any failures in my tests.

Also, I don't think it is worth worrying about 2.61 compatibility,
since getopt.m4sh is only needed when bootstrapping, which requires
newer autotools anyway.

> I've pushed the patch below to fix this failure now.

Thanks.

Cheers,
-- 
Gary V. Vaughan (g...@gnu.org)


PGP.sig
Description: This is a digitally signed message part

Re: getopt-m4sh tests failures with autom4te 2.61

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Thu, Sep 02, 2010 at 10:36:54PM CEST:
> Hi Gary,
> 
> I get testsuite failures of the first six tests with autom4te 2.61 early
> in PATH (the testsuite itself has been created with 2.67).  See below
> for an example failure.  Maybe getopt-m4sh.at really relies on >= 2.62?

I've pushed the patch below to fix this failure now.

Cheers,
Ralf

Fix getopt.m4sh to require Autoconf 2.62 or newer.

* libltdl/config/getopt.m4sh (m4_version_prereq): Require 2.62,
not 2.61.

diff --git a/libltdl/config/getopt.m4sh b/libltdl/config/getopt.m4sh
index 806c1d4..2196743 100644
--- a/libltdl/config/getopt.m4sh
+++ b/libltdl/config/getopt.m4sh
@@ -50,11 +50,11 @@ m4_pattern_forbid([^_?m4go_])
 ## --- ##
 
 # We prefer m4sugar.m4 from Autoconf-2.64, but have fallbacks in this
-# section that work back as far as Autoconf-2.61.  This file is used
+# section that work back as far as Autoconf-2.62.  This file is used
 # at bootstrap time to generate the shell processing loop for ltmain.sh
 # and libtoolize.in, so it's okay for the requirement to be tighter
 # than the configure time Autoconf prerequisite version.
-m4_version_prereq([2.61])
+m4_version_prereq([2.62])
 
 # m4_chomp(STRING)
 # 

Re: How many spaces after a period? [WAS: Re: [PATCH 7/7] Prefer $NM @file over calculating the cmd line length.]

[Ralf Wildenhues]

Hi Gary,

* Gary V. Vaughan wrote on Sun, Sep 12, 2010 at 11:23:52AM CEST:
> On 12 Sep 2010, at 15:01, Ralf Wildenhues wrote:
> > * Peter Rosin wrote on Sat, Sep 11, 2010 at 02:24:18PM CEST:
> >> * libltdl/config/ltmain.m4sh (func_mode_link): Avoid calculating
> >> the command line length and take the @file branch *if* the file
> >> names needs to be converted for the toolchain and the @file
> >> branch works. Fixes stresstest.at when doing a cross from Cygwin
> > 
> > Two spaces after period.
> 
> Only for texinfo markup I believe, since two spaces after a period are
> widely regarded as typographically bad (see the following and the
> reports it cites at the end):
> 
> http://webword.com/reports/period.html

Maybe.  I thought the two spaces were so that emacs would correctly jump
a sentence ahead; guess that's not needed any more now.

FWIW I consider two spaces to really improve readability in fixed-width
font.[1]  All proportional renderers are better off because they can
just increase the space by a little.  The above URL admits that two
spaces are better for fixed-with.

Thanks,
Ralf

[1] I also regard lines in email wrapped at 72 chars highly improving
readability, by the way.  ;->

How many spaces after a period? [WAS: Re: [PATCH 7/7] Prefer $NM @file over calculating the cmd line length.]

[Gary V. Vaughan]

On 12 Sep 2010, at 15:01, Ralf Wildenhues wrote:
> * Peter Rosin wrote on Sat, Sep 11, 2010 at 02:24:18PM CEST:
>> * libltdl/config/ltmain.m4sh (func_mode_link): Avoid calculating
>> the command line length and take the @file branch *if* the file
>> names needs to be converted for the toolchain and the @file
>> branch works. Fixes stresstest.at when doing a cross from Cygwin
> 
> Two spaces after period.

Only for texinfo markup I believe, since two spaces after a period are widely 
regarded as typographically bad (see the following and the reports it cites at 
the end):

http://webword.com/reports/period.html

And even then, there is still support for normal spacing in texinfo:

http://www.gnu.org/software/hello/manual/texinfo/frenchspacing.html

[[ASIDE: Curious that the default `...@frenchspacing off' is used to indicate 
the use of 2 spaces at the end of a sentence, and declaring `...@frenchspacing 
on' conversely indicates the use of a single space at the end of a sentence - 
the exact opposite of how the term is normally used:

  "French spacing—a term synonymous with single space sentence spacing until 
the late 20th century.[7] Double spacing,[8] or placing two spaces between 
sentences (sometimes referred to as English spacing), came into widespread use 
with the introduction of the typewriter in the late 19th century" -- 
http://en.wikipedia.org/wiki/Sentence_spacing]]

I see that the GCS wants two spaces after a period in code comments, but when I 
tested in emacs, my single spaced sentences worked just fine. It turns out that 
I added the following to my startup so long ago that I'd forgotten I had done 
it:

(setq sentence-end-double-space nil)

Is there some other mandate that explains why we should go against modern 
typographical conventions and insist on double spaces?

Cheers,
-- 
Gary V. Vaughan (g...@gnu.org)

PGP.sig
Description: This is a digitally signed message part

Re: [PATCH 0/3]: Another go at LTO support

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Sun, Aug 29, 2010 at 06:18:05PM CEST:
> OK, so the issues I had with
> 
> was both changing output_verbose_link_cmd to something that might work
> worse in a number of setups, and on the other hand having a reliable way
> to get at postdeps in presence of -flto or -fwhopr or so.
> 
> Here's another try.
[...]

I've merged the lto branch into master now.  If you are interested in
LTO support in Libtool, it would be nice if you could test it, so that
we have a chance of fixing issues before the next release (due pretty
soon).

Thank you,
Ralf

Re: [PATCH 7/7] Prefer $NM @file over calculating the cmd line length.

[Ralf Wildenhues]

Hi Peter,

* Peter Rosin wrote on Sat, Sep 11, 2010 at 02:24:18PM CEST:
> Subject: [PATCH 7/7] Prefer $NM @file when the toolchain isn't native to 
> $build.
> 
> * libltdl/config/ltmain.m4sh (func_mode_link): Avoid calculating
> the command line length and take the @file branch *if* the file
> names needs to be converted for the toolchain and the @file
> branch works. Fixes stresstest.at when doing a cross from Cygwin

Two spaces after period.

> to MinGW using MinGW native tools (a.k.a. a "faked" cross).

> --- a/libltdl/config/ltmain.m4sh
> +++ b/libltdl/config/ltmain.m4sh
> @@ -7341,10 +7341,23 @@ EOF
>   save_ifs="$IFS"; IFS='~'
>   for cmd1 in $cmds; do
> IFS="$save_ifs"
> -   eval cmd=\"$cmd1\"
> -   func_len " $cmd"
> -   len=$func_len_result
> -   if test "$len" -lt "$max_cmd_len" || test "$max_cmd_len" -le -1; 
> then
> +   # Take the normal branch if the nm_file_list_spec branch doesn't
> +   # work or if tool conversion is not needed

Period at end of sentence.

> +   case $nm_file_list_spec~$to_tool_file_cmd in
> + *~func_convert_file_noop | *~func_convert_file_msys_to_w32 | ~*)
> +   tool_conversion_needed_and_working=false
> +   eval cmd=\"$cmd1\"
> +   func_len " $cmd"
> +   len=$func_len_result
> +   ;;
> + *)
> +   tool_conversion_needed_and_working=:
> +   ;;
> +   esac
> +   if { test "$len" -lt "$max_cmd_len" \
> +|| test "$max_cmd_len" -le -1; } \
> +  && ! $tool_conversion_needed_and_working

`! $command' is not portable, please reverse the logic or use
test foo = bar or so.

The logic is flawed here, you are testing potentially-undefined $len.
Did you mean to reverse the && order (the shell does short-circuiting
of || and && so that would seem appropriate here)?

> +   then
>   func_show_eval "$cmd" 'exit $?'

This code has eval problems, but they were before your patch, so I guess
they are not on you to fix.

>   skipped_export=false
> elif test -n "$nm_file_list_spec"; then

Thanks,
Ralf