Re: [PATCH] bootstrap: use $PATH_SEPARATOR instead of :

2015-01-21 Thread Gary V. Vaughan
On Jan 21, 2015, at 3:46 AM, KO Myung-Hun  wrote:
> 
> Hi/2.

Hi!

> Gary V. Vaughan wrote:
>> 
>>> On Jan 20, 2015, at 5:22 AM, KO Myung-Hun  wrote:
>>> 
>>> On OS/2, a path separator is ';' not ':'.
>>> 
>>> * bootstrap (func_find_tool, func_check_tool): Use PATH_SEPARATOR.
>>> * gl/build-aux/bootstrap.in (func_check_tool): Likewise.
>>> * gl/build-aux/extract-trace (fund_find_tool): Likewise.
>> 
>> These files do not belong to Libtool itself, but rather to
>> https://github.com/gvvaughan/bootstrap. 
> 
> Then should I send patches for it to different places ?

The main thing is to check that any bootstrap related issues you find in 
libtool are not already fixed in upstream bootstrap.

If you like, you can queue your pull request directly from your clone of the 
bootstrap github repo to make sure it doesnt get lost on the libtool mailing 
list, but sending here is perfectly fine too.

>> We already fixed one of the
>> PATH_SEPARATOR omissions on your last round of patches (thanks!), but
>> I ported the other one upstream, and then updated libtool with the
>> result, including a couple of other unrelated improvements.
> 
> Thanks.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


Re: [PATCH] bootstrap: use $PATH_SEPARATOR instead of :

2015-01-20 Thread Gary V. Vaughan
Hi,

On Jan 20, 2015, at 5:22 AM, KO Myung-Hun  wrote:
> 
> On OS/2, a path separator is ';' not ':'.
> 
> * bootstrap (func_find_tool, func_check_tool): Use PATH_SEPARATOR.
> * gl/build-aux/bootstrap.in (func_check_tool): Likewise.
> * gl/build-aux/extract-trace (fund_find_tool): Likewise.

These files do not belong to Libtool itself, but rather to
https://github.com/gvvaughan/bootstrap.  We already fixed one of the
PATH_SEPARATOR omissions on your last round of patches (thanks!), but
I ported the other one upstream, and then updated libtool with the
result, including a couple of other unrelated improvements.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



Re: [PATCH] testsuite: fix race conditions in ltdl dryrun

2015-01-20 Thread Gary V. Vaughan
On Dec 15, 2014, at 1:13 PM, Pavel Raiskup  wrote:
> 
> [+cc autoconf, as this seems to be relevant]
> 
> Hi all,

Hi Pavel,

Thanks for the fix.  This one has caught me out occasionally too, so I'll also
be glad to banish it!

Sorry for the delay in applying and pushing... it's been a crazy month!

> after several random [ltdl dryrun] failures, I used the 'make --debug' and
> some stat calls to debug.  Logs are attached for ok & failed runs as
> tarball.  Seems like after 'aclocal' run there should be an explicit
> 'sleep 1', similarly like in autoreconf [1].  Possible fix attached.  The
> problem seems to be in autoheader and Perl's move function (underlying
> utime() handling?):
> 
>   $ touch /tmp/a
>   $ stat /tmp/a
> File: ‘/tmp/a’
> Size: 0   Blocks: 0  IO Block: 4096   regular empty 
> file
>   Device: 23h/35d Inode: 1296845 Links: 1
>   Access: (0664/-rw-rw-r--)  Uid: ( 1000/praiskup)   Gid: ( 1000/praiskup)
>   Context: unconfined_u:object_r:user_tmp_t:s0
>   Access: 2014-12-15 14:03:35.744530946 +0100
>   Modify: 2014-12-15 14:03:35.744530946 +0100
>   Change: 2014-12-15 14:03:35.744530946 +0100
>Birth: -
>   $ perl -MFile::Copy -e 'move ("/tmp/a", "a");'
>   $ stat a
> File: ‘a’
> Size: 0   Blocks: 0  IO Block: 4096   regular empty 
> file
>   Device: fd00h/64768dInode: 11068678Links: 1
>   Access: (0664/-rw-rw-r--)  Uid: ( 1000/praiskup)   Gid: ( 1000/praiskup)
>   Context: unconfined_u:object_r:user_home_t:s0
>   Access: 2014-12-15 14:03:42.0 +0100
>   Modify: 2014-12-15 14:03:35.0 +0100
>   ^^^ floor()-ed
>   Change: 2014-12-15 14:03:42.678581581 +0100
>Birth: -
> 
> [1] http://git.savannah.gnu.org/cgit/autoconf.git/tree/bin/autoreconf.in#n356
> 
> Pavel
> <0001-tests-fix-race-in-aclocal-autoheader-calls.patch>

Applied and pushed.  Thanks again!

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)




Re: [PATCH] libtoolize: fix ltdl installation order

2015-01-16 Thread Gary V. Vaughan
On Jan 16, 2015, at 10:34 AM, Pavel Raiskup  wrote:
> 
> * Makefile.am (pkgltdl_files): Move the Makefile.in file down in
> the list after aclocal.m4.
> ---
> Makefile.am | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/Makefile.am b/Makefile.am
> index f1b7ead..794d58d 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -441,13 +441,14 @@ pkgmacro_files  = libtool.m4 ltargz.m4 ltdl.m4 
> ltoptions.m4 ltsugar.m4 \
> ltversion.m4 lt~obsolete.m4
> 
> ## These are installed as a subdirectory of pkgdatadir so that
> -## libtoolize --ltdl can find them later:
> +## libtoolize --ltdl can find them later.  Note that this list requires
> +## specific order to avoid unnecessary re-autotooling after libtoolize run.
> pkgltdl_files = COPYING.LIB \
> Makefile.am \
> -   Makefile.in \
> README \
> configure.ac \
> aclocal.m4 \
> +   Makefile.in \
> config-h.in \
> configure \
>         libltdl/lt__alloc.h \

Agreed, thank you.  Applied and pushed!

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)




Re: [PATCH] AIX: Optional filename-based shlib versioning

2014-12-05 Thread Gary V. Vaughan
Hi /haubi/ :),

On Dec 5, 2014, at 8:37 AM, Michael Haubenwallner 
 wrote
> On 12/03/2014 11:09 PM, Gary V. Vaughan wrote:
>> 
>> I'm sorry I forgot to thank you for this patch, which I applied in
>> time for the recent 2.4.4 release.
>> 
>> On Nov 24, 2014, at 1:09 PM, Michael Haubenwallner 
>>  wrote:
>>> 
>>> Support filename-based shared library versioning on AIX with the lib.so
>>> library filename extension, which is used with runtime linking only.
>>> Runtime linking is enabled by the -brtl linker flag for executables and
>>> the -G linker flag for Shared Objects. The behaviour is similar to
>>> Linux/SVR4 DT_SONAME, hence the name "aix-soname=svr4".
>> 
>> Much appreciated!  I did make some slight edits after applying, so
>> please check that it still works for you.
> 
> Yes, testsuite results still works as expected.
> 
> One note for the case-separator in tests/versioning.at to remember:
> LDFLAGS may contain both ':' and ',' eventually. OTOH, to break here
> LDFLAGS value would need to be invalid anyway (sth. like "-Wl,,").

Good point, I hadn't considered that when I changed your patch to match the
Libtool style precedent.  However, I think it would take an exceptionally
pathological case to actually fall into the wrong branch of the case statement,
so I'm inclinded not to worry about it just yet.

> Thank you so much!

No problem!

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)




Re: [PATCH] make freebsd-elf version type similar to linux version type

2014-12-04 Thread Gary V. Vaughan
Hi Tijl,

> On Dec 4, 2014, at 9:00 AM, Tijl Coosemans  wrote:
> 
> On Thu, 27 Nov 2014 18:59:56 +0100 Tijl Coosemans  wrote:
>> --- a/m4/libtool.m4
>> +++ b/m4/libtool.m4
>> @@ -2543,7 +2543,8 @@ freebsd* | dragonfly*)
>>   version_type=freebsd-$objformat
>>   case $version_type in
>> freebsd-elf*)
>> -  library_names_spec='$libname$release$shared_ext$versuffix 
>> $libname$release$shared_ext $libname$shared_ext'
>> +  library_names_spec='$libname$release$shared_ext$versuffix 
>> $libname$release$shared_ext$major $libname$shared_ext'
>> +  soname_spec='$libname$release$shared_ext$major'
> 
> This patch seems to have been committed without this soname_spec line.

Argh.  Sorry about that, and thanks for picking up the mistake.  Hopefully,
this also fixes the test failures reported on freebsds recently.

Please confirm that current master is behaving for you, and I'll put out
a patch release.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)




Re: [PATCH] AIX: Optional filename-based shlib versioning

2014-12-03 Thread Gary V. Vaughan
Hi Michael,

I sorry I forgot to thank you for this patch, which I applied in
time for the recent 2.4.4 release.

> On Nov 24, 2014, at 1:09 PM, Michael Haubenwallner 
>  wrote:
> 
> Support filename-based shared library versioning on AIX with the lib.so
> library filename extension, which is used with runtime linking only.
> Runtime linking is enabled by the -brtl linker flag for executables and
> the -G linker flag for Shared Objects. The behaviour is similar to
> Linux/SVR4 DT_SONAME, hence the name "aix-soname=svr4".

Much appreciated!  I did make some slight edits after applying, so
please check that it still works for you.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)




Re: [PATCH] libtoolize.in: remove two umask 0

2014-11-28 Thread Gary V. Vaughan
Hi Tijl,

Thanks for the patches.  Applied already, and will be pushed as soon
as the test suite completes successfully.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

> On Nov 27, 2014, at 5:59 PM, Tijl Coosemans  wrote:
> 
> "libtoolize --ltdl -c" creates some files with write permissions for
> everybody because it sets "umask 0" in two places.  This patch removes
> the umask commands.
> 
> ---
> libtoolize.in | 12 ++--
> 1 file changed, 2 insertions(+), 10 deletions(-)
> 
> diff --git a/libtoolize.in b/libtoolize.in
> index d819470..530232d 100644
> --- a/libtoolize.in
> +++ b/libtoolize.in
> @@ -392,11 +392,7 @@ func_copy ()
> 
> # Filters always take priority.
> if test -n "$my_filter"; then
> -  if $opt_dry_run || {
> -  ( umask 0
> -$SED -e "$my_filter" "$my_srcfile" > "$my_destfile"
> -  ) >/dev/null 2>&1
> -}
> +  if $opt_dry_run || $SED -e "$my_filter" "$my_srcfile" > "$my_destfile" 
> 2>/dev/null
>   then
> func_notquiet_once "$my_msg_var"
> if $opt_verbose; then
> @@ -422,11 +418,7 @@ func_copy ()
> my_copy_msg="$my_copy_type file '$my_destfile'"
> $opt_verbose && my_copy_msg="$my_copycmd $my_srcfile $my_destdir"
> 
> -if $opt_dry_run || {
> -( umask 0
> -  $my_copycmd "$my_srcfile" "$my_destfile"
> -) >/dev/null 2>&1
> -  }
> +if $opt_dry_run || $my_copycmd "$my_srcfile" "$my_destfile" >/dev/null 
> 2>&1
> then
>   func_notquiet_hdr "$my_msg_var" "$my_copy_msg"
> else
> -- 
> 2.1.0
> 
> 




Re: [PATCH] make freebsd-elf version type similar to linux version type

2014-11-27 Thread Gary V. Vaughan
Hi Tijl,

Thanks for the patches.

> On 27 Nov 2014, at 17:59, Tijl Coosemans  wrote:
> 
> On FreeBSD we have switched from using .so.$current as library extension
> to .so.$major.$age.$revision where $major is $current-$age.  Our package
> of libtool has been patched similar to the patch below which you can see
> here: https://svnweb.freebsd.org/ports/head/devel/libtool/files/

What about people who want to build packages for an old BSD a with the
earlier versioning scheme? Is it possible to redo your patch so that the change
only takes effect for *-freebsdx.y* (or similar) where x.y denotes the earliest
release that fully supports the new versioning scheme?

> The "freebsd-elf" version type was also used for SCO UnixWare.  This
> patch creates a separate version type "sco" for that system.

Ack.

> ---
> build-aux/ltmain.in | 14 ++
> m4/libtool.m4   |  5 +++--
> 2 files changed, 13 insertions(+), 6 deletions(-)
> 
> diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
> index 65b5a2d..6cea0f8 100644
> --- a/build-aux/ltmain.in
> +++ b/build-aux/ltmain.in
> @@ -6795,13 +6795,13 @@ func_mode_link ()
>  #
>  case $version_type in
>  # correct linux to gnu/linux during the next big refactor
> -  darwin|linux|osf|windows|none)
> +  darwin|freebsd-elf|linux|osf|windows|none)
>func_arith $number_major + $number_minor
>current=$func_arith_result
>age=$number_minor
>revision=$number_revision
>;;
> -  freebsd-aout|freebsd-elf|qnx|sunos)
> +  freebsd-aout|qnx|sco|sunos)
>current=$number_major
>revision=$number_minor
>age=0
> @@ -6887,8 +6887,9 @@ func_mode_link ()
>  ;;
> 
>freebsd-elf)
> -  major=.$current
> -  versuffix=.$current
> +  func_arith $current - $age
> +  major=.$func_arith_result
> +  versuffix=$major.$age.$revision
>  ;;
> 
>irix | nonstopux)
> @@ -6951,6 +6952,11 @@ func_mode_link ()
>  versuffix=.$current
>  ;;
> 
> +sco)
> +  major=.$current
> +  versuffix=.$current
> +  ;;
> +
>sunos)
>  major=.$current
>  versuffix=.$current.$revision
> diff --git a/m4/libtool.m4 b/m4/libtool.m4
> index 320d8b3..acbda77 100644
> --- a/m4/libtool.m4
> +++ b/m4/libtool.m4
> @@ -2543,7 +2543,8 @@ freebsd* | dragonfly*)
>   version_type=freebsd-$objformat
>   case $version_type in
> freebsd-elf*)
> -  library_names_spec='$libname$release$shared_ext$versuffix 
> $libname$release$shared_ext $libname$shared_ext'
> +  library_names_spec='$libname$release$shared_ext$versuffix 
> $libname$release$shared_ext$major $libname$shared_ext'
> +  soname_spec='$libname$release$shared_ext$major'
>   need_version=no
>   need_lib_prefix=no
>   ;;
> @@ -2888,7 +2889,7 @@ sysv4*MP*)
>   ;;
> 
> sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
> -  version_type=freebsd-elf
> +  version_type=sco
>   need_lib_prefix=no
>   need_version=no
>   library_names_spec='$libname$release$shared_ext$versuffix 
> $libname$release$shared_ext $libname$shared_ext'

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


Re: [PATCH] ltdl: set libltdl_cv_need_uscore to yes on OS/2

2014-11-27 Thread Gary V. Vaughan
Hi,

> On Nov 27, 2014, at 4:53 AM, KO Myung-Hun  wrote:
> Gary V. Vaughan wrote:
>> 
>>> On 27 Nov 2014, at 02:47, KO Myung-Hun  wrote:
>>> I agree.
>>> 
>>> Gary V. Vaughan wrote:
>>>> I pushed the core of a new macro that does exactly that to M4 master just
>>>> now.
>>>> 
>>>> Would you let me know whether this works correctly on OS2 for you please?
>>> 
>>> Of course. Unfortunately, however, it does not work. dlopen() in
>>> configure fails due to 'file not found'.
>> 
>> Thanks for checking.  Can you tell me why it fails (module is not compiled 
>> correctly;
>> path argument to dlopen() is wrong), and maybe suggest what would fix it, 
>> please?
>> 
> 
> I've look into this problem. Module is not built. To build it, some
> additional variables are required. They are soname, libname,
> output_objdir. And archive_cmds on OS/2 consists of multi lines
> separated by ~. So when using it, quotation is needed. And to eval it
> the function such as func_execute_cmds is needed. In addition, make sure
> .libs exist before building a module.
> 
> Finally, please remember that OS/2 does not support DLLs whose base name
> is longer than 8 characters.

Thanks for the swift and helpful feedback.  I pushed some new changes that 
should
address all of those issues.  Please let me know if anything is still wrong, and
in what way it is broken for you if so -- otherwise, I'll port this code into a
new libtool macro and make the next libtool release for m4 master to depend on.

I know I have some other issues you reported to work out in M4, but I'd like to
clear this one up first so I can make the promised libtool release asap.

Many thanks for your help!

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


Re: [PATCH] ltdl: set libltdl_cv_need_uscore to yes on OS/2

2014-11-26 Thread Gary V. Vaughan
Hi!

> On 27 Nov 2014, at 02:47, KO Myung-Hun  wrote:
> 
> Hi/2.
> 
> Gary V. Vaughan wrote:
>> Hi,
>> 
>> Thanks for the report and the patch!
>> 
>>> On Nov 22, 2014, at 4:08 AM, KO Myung-Hun  wrote:
>>> 
>>> On OS/2, dlopen() does not support a program. So libltdl_cv_need_uscore
>>> is set to unknown, but dlsym() requires an underscore prefix. So set
>>> libltdl_cv_need_uscore to yes on OS/2 if lt_cv_sys_symbol_underscore is
>>> yes and libltdl_cv_need_uscore is unknown.
>> 
>> Actually, I think the real problem here is that LT_FUNC_DLSYM_USCORE is
>> making the bad assumption that dlsym() only requires a leading symbol
>> name underscore on machines where self dlopening works.
>> 
>> Better than your suggested patch, we should really be checking whether
>> dlsym of ordinary loadable module symbol names requires a leading underscore.
> 
> I agree.
> 
>> I pushed the core of a new macro that does exactly that to M4 master just
>> now.
>> 
>> Would you let me know whether this works correctly on OS2 for you please?
> 
> Of course. Unfortunately, however, it does not work. dlopen() in
> configure fails due to 'file not found'.

Thanks for checking.  Can you tell me why it fails (module is not compiled 
correctly;
path argument to dlopen() is wrong), and maybe suggest what would fix it, 
please?

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


Re: [PATCH] ltdl: set libltdl_cv_need_uscore to yes on OS/2

2014-11-26 Thread Gary V. Vaughan
Hi,

Thanks for the report and the patch!

On Nov 22, 2014, at 4:08 AM, KO Myung-Hun  wrote:
> 
> On OS/2, dlopen() does not support a program. So libltdl_cv_need_uscore
> is set to unknown, but dlsym() requires an underscore prefix. So set
> libltdl_cv_need_uscore to yes on OS/2 if lt_cv_sys_symbol_underscore is
> yes and libltdl_cv_need_uscore is unknown.

Actually, I think the real problem here is that LT_FUNC_DLSYM_USCORE is
making the bad assumption that dlsym() only requires a leading symbol
name underscore on machines where self dlopening works.

Better than your suggested patch, we should really be checking whether
dlsym of ordinary loadable module symbol names requires a leading underscore.
I pushed the core of a new macro that does exactly that to M4 master just
now.

Would you let me know whether this works correctly on OS2 for you please?

If so, I'll copy the implementation from M4 to libtool prior to the
imminent release, and then have M4 master require that libtool version
to pick up the improved macro definition.

> * m4/ltdl.m4 (LT_FUNC_DLSYM_USCORE): set libltdl_cv_need_uscore to yes
> on os2*.
> ---
> m4/ltdl.m4 | 5 +
> 1 file changed, 5 insertions(+)
> 
> diff --git a/m4/ltdl.m4 b/m4/ltdl.m4
> index eeb37ac..ce7b2b7 100644
> --- a/m4/ltdl.m4
> +++ b/m4/ltdl.m4
> @@ -804,6 +804,11 @@ if test yes = "$lt_cv_sys_symbol_underscore"; then
>   [libltdl_cv_need_uscore=no], [libltdl_cv_need_uscore=yes],
>   [],  [libltdl_cv_need_uscore=cross])
> LIBS=$save_LIBS
> +   if test x"$libltdl_cv_need_uscore" = xunknown; then
> + case $host_os in
> +   os2*) libltdl_cv_need_uscore=yes ;;
> + esac
> +   fi
>   ])
>   fi
> fi
> -- 
> 1.8.5.2

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



Re: [PATCH] Do not test undef symbols across shlibs on AIX.

2014-11-21 Thread Gary V. Vaughan
Hi Michael,

On Nov 21, 2014, at 12:50 PM, Michael Haubenwallner 
 wrote:
> 
> On AIX, undefined symbols across shared libraries can work only when
> the main program explicitly exports those symbols. As this is bad
> practice anyway and -no-undefined should be preferred, we skip this.
> * tests/template.at: Skip test with undef syms across libraries on AIX.
> ---
> tests/template.at | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)

Also, applied and pushed.  Thanks again!
-- 
Gary V. Vaughan (gary AT gnu DOT org)


Re: [PATCH] question mark is extended regex for non-GNU grep

2014-11-21 Thread Gary V. Vaughan
On Nov 21, 2014, at 2:53 PM, Michael Haubenwallner 
 wrote:
> 
> On 11/21/2014 03:06 PM, Eric Blake wrote:
>> On 11/21/2014 05:11 AM, Michael Haubenwallner wrote:
>>> Accepting \? for at-most-once in basic regex is a GNU grep extension,
>>> not accepted by AIX grep for example.
>>> * tests/libtool.at: Need EGREP for ? operator, and ? without \ then.
>>> With EGREP, need one more \ for $.
>> 
>> Or, stick with GREP but use \{0,1\} instead of \?.
> 
> Possible as well, thanks!
> /haubi/
> <0001-question-mark-is-extended-regex-for-non-GNU-grep.patch>

Applied and pushed on master, many thanks!
-- 
Gary V. Vaughan (gary AT gnu DOT org)


Re: [PATCH] Fixed -fvisbility=hidden typo in a comment

2014-11-18 Thread Gary V. Vaughan
Hi Eric,

> On Nov 17, 2014, at 6:52 PM, Eric Blake  wrote:
> On 11/17/2014 10:58 AM, Gary V. Vaughan wrote:
>>> On 17 Nov 2014, at 17:29, Vincent Lefevre  wrote:
>>> 
>>> There are other
>>> ones in libtool, e.g. in NEWS:
>>> 
>>> NEWS:607: propogate  ==> propagate
>>> NEWS:1101: modeled  ==> modelled
>> 
>> The latter is a legitimate spelling (according to my British English 
>> dictionary at least),
>> but unfortunately the NEWS file is checksummed to prevent changes after a 
>> release,
>> so not easy to fix without tweaking the release process :-(
> 
> It's possible to update the expected checksum when intentionally
> correcting old news entries.  Since you are using gnulib's maint.mk,
> look at the update-NEWS-hash target.

Thanks for the prod... I was too lazy to dig for the right target.

I've fixed the propagate mis-spelling too and updated the hash accordingly.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


Re: [PATCH] Fixed -fvisbility=hidden typo in a comment

2014-11-17 Thread Gary V. Vaughan
Hi Vincent,

> On 17 Nov 2014, at 17:29, Vincent Lefevre  wrote:
> 
>> On 2014-11-17 16:01:18 +0000, Gary V. Vaughan wrote:
>> Nice catch! I had no idea people scrutinized the comments so carefully :-)
> 
> It was actually reported by Kiyoshi KANAZAWA in the GNU MPFR list:
> 
>  http://comments.gmane.org/gmane.comp.lib.mpfr.general/2246
> 
> BTW, some typos can be found by using "codespell".

Great tip, thanks, I wasn't aware of that tool.

> There are other
> ones in libtool, e.g. in NEWS:
> 
> NEWS:607: propogate  ==> propagate
> NEWS:1101: modeled  ==> modelled

The latter is a legitimate spelling (according to my British English dictionary 
at least),
but unfortunately the NEWS file is checksummed to prevent changes after a 
release,
so not easy to fix without tweaking the release process :-(

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


Re: [PATCH] Fixed -fvisbility=hidden typo in a comment

2014-11-17 Thread Gary V. Vaughan
Hi Vincent,

> On Nov 15, 2014, at 1:44 PM, Vincent Lefevre  wrote:
> 
> Fixed -fvisbility=hidden typo in a comment.
> 
> Signed-off-by: Vincent Lefevre 
> ---
> m4/libtool.m4 | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/m4/libtool.m4 b/m4/libtool.m4
> index 281e70f..6143541 100644
> --- a/m4/libtool.m4
> +++ b/m4/libtool.m4
> @@ -1840,7 +1840,7 @@ else
> #  endif
> #endif
> 
> -/* When -fvisbility=hidden is used, assume the code has been annotated
> +/* When -fvisibility=hidden is used, assume the code has been annotated
>correspondingly for the symbols needed.  */
> #if defined __GNUC__ && (((__GNUC__ == 3) && (__GNUC_MINOR__ >= 3)) || 
> (__GNUC__ > 3))
> int fnord () __attribute__((visibility("default")));
> -- 
> 2.1.3

Nice catch! I had no idea people scrutinized the comments so carefully :-)

Applied and pushed.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


Re: [PATCH] OS/2 patches

2014-11-04 Thread Gary V. Vaughan
Hi KO,

Very sorry for the immense delay in getting to this.

> On Nov 4, 2014, at 6:12 AM, KO Myung-Hun  wrote:
> 
> Hi/2.
> 
> I've rebased to master.

Awesome, and thanks for persevering :)

> Review, please...
> 
> [PATCH 01/11] libtool: don't eliminate duplications in $postdeps and $predeps 
> on OS/2

no effect on systems other than *-os2*, applied

> [PATCH 02/11] libtool: support to link against static libraries on OS/2

same again, applied with minimal edits to pass `make syntax-check`

> [PATCH 03/11] ltdl: OS/2 uses other APIs to load a DLL than LoadLibrary() on 
> Windows

no effect on systems other than *-os2*, applied

> [PATCH 04/11] libtool: there is no need to relink DLLs on OS/2

same again, reworded commit message

> [PATCH 05/11] libtool: set lt_cv_deplibs_check_method to pass_all on OS/2

likewise

> [PATCH 06/11] libtool: support -Zxxx options used on OS/2

I have some concerns on letting all -Z options through, as this may affect other
compilers that I can't test, so I made -Z conditional on $host matching os2*.

> [PATCH 07/11] libtool: fix DLL creation/installation/uninstallation on OS/2

no effect an systems other than *-os2* again, applied with light edits to commit
message, comments and to fix failures with `make syntax-check`.

> [PATCH 08/11] libtool: add -os2dllname option

applied with some edits for English, and moving the NEWS entry to the correct
release

> [PATCH 09/11] libtool: support -export-symbols and -export-symbols-regex on 
> OS/2

no effect on systems other than *-os2*, applied with edits to pass `make 
syntax-check`

> [PATCH 10/11] libtool: support versioning on OS/2

likewise

> [PATCH 11/11] bootstrap: double quote an expression with a wildcard

imported to upstream bootstrap repo, and synchronised with libtool

Please check that everything still works for you as expected, as I don't have 
OS/2
to maintain the integrity of the OS/2 port.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


Re: [PATCH] libtoolize: do not delete gnulib headers

2014-11-02 Thread Gary V. Vaughan
Hi Mike,

> On Oct 31, 2014, at 9:07 PM, Mike Frysinger  wrote:
> 
> These snippet/ headers are installed by gnulib, not libtool.  There's no
> reason libtool should be trying to delete these for us (and will break
> projects), so drop that logic.
> 
> People who are using gnulib can use gnulib to update/manage these.
> 
> * libtoolize.in (func_require_seen_libtool): Delete snippet/ header files
> from $all_pkgaux_files.
> 
> Signed-off-by: Mike Frysinger 
> ---
> libtoolize.in | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libtoolize.in b/libtoolize.in
> index d819470..d0cbfb0 100644
> --- a/libtoolize.in
> +++ b/libtoolize.in
> @@ -1897,7 +1897,7 @@ func_require_seen_libtool ()
>   # Do not remove config.guess, config.sub or install-sh, we don't
>   # install them without --install, and the project may not be using
>   # Automake.
> -  all_pkgaux_files="compile depcomp missing ltmain.sh snippet/_Noreturn.h 
> snippet/arg-nonnull.h snippet/c++defs.h snippet/warn-on-use.h"
> +  all_pkgaux_files="compile depcomp missing ltmain.sh"
>   all_pkgmacro_files="argz.m4 libtool.m4 ltdl.m4 ltoptions.m4 ltsugar.m4 
> ltversion.in ltversion.m4 lt~obsolete.m4"
>   all_pkgltdl_files="COPYING.LIB Makefile Makefile.in Makefile.inc 
> Makefile.am README acinclude.m4 aclocal.m4 argz_.h argz.c config.h.in 
> config-h.in configure configure.ac configure.in libltdl/lt__alloc.h 
> libltdl/lt__dirent.h libltdl/lt__glibc.h libltdl/lt__private.h 
> libltdl/lt__strl.h libltdl/lt_dlloader.h libltdl/lt_error.h 
> libltdl/lt_system.h libltdl/slist.h loaders/dld_link.c loaders/dlopen.c 
> loaders/dyld.c loaders/load_add_on.c loaders/loadlibrary.c loaders/preopen.c 
> loaders/shl_load.c lt__alloc.c lt__dirent.c lt__strl.c lt_dlloader.c 
> lt_error.c ltdl.c ltdl.h ltdl.mk slist.c"

Thanks for the patch.

Working backwards through my InBox I already applied Pavel Raiskup's identical
patch.  The fix will be in 2.4.4 in any case.

If you'd like me to credit you in the 2.4.4 ChangeLog alongside Pavel, just let
me know and I'll add a ChangeLog edit into build-aux/git-log-fix.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


Re: libtool mailing lists

2014-10-31 Thread Gary V. Vaughan
Hii Pavel,

They've been working fine for me so far... CCed just to be sure! :-)

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

> On 31 Oct 2014, at 07:57, Pavel Raiskup  wrote:
> 
> Hi Gary, has something happened with libtool's mailing lists?  I was
> unable to send there an email yesterday (and I doubt I have done something
> bad;  apart from that I mistakenly did not re-add you to CC and
> "reply-to-all" did also not that for me).
> 
> Pavel
> 



Re: Add dynamic export support for tcc

2014-10-29 Thread Gary V. Vaughan
Hi Reuben,

> On Jul 31, 2014, at 4:55 PM, Reuben Thomas  wrote:
> 
> The attached patch adds support for tcc's -rdynamic, the equivalent of GNU 
> ld's -Wl,--export-dynamic.

Sorry for the long delay.

I found this uncontroversial patch (and your other one) in my libtool archives, 
and applied it to master HEAD just now.

Unfortunately libtool-2.4.3 went out a day or two already, but I'm expecting to 
accumulate a few more patches against it over the next week or two, after which 
I'll roll libtool-2.4.4 including both your tcc patches.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


Re: bug#16452: opt_duplicate_compiler_generated_deps is harmful on Solaris

2014-01-17 Thread Gary V. Vaughan
Hi Rainer,

On Jan 16, 2014, at 1:59 AM, Rainer Orth  wrote:
> diff --git a/ltmain.sh b/ltmain.sh
> --- a/ltmain.sh
> +++ b/ltmain.sh
> @@ -976,7 +976,7 @@ func_enable_tag ()
> 
> 
>   case $host in
> -*cygwin* | *mingw* | *pw32* | *cegcc*)
> +*cygwin* | *mingw* | *pw32* | *cegcc* | *solaris2* )
>   # don't eliminate duplications in $postdeps and $predeps
>   opt_duplicate_compiler_generated_deps=:
>   ;;
> 
> I think that patch should go into upstream libtool as well, although
> this won't help for all the copies of libtool already included in
> released packages.  As described in the PR, I'm uncertain how to move
> forward here.  Suggestions?

I took the liberty of writing a ChangeLog on your behalf.

Pushed, this will be in the incoming release as long as testing doesn't find
any issues.  Thanks.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



Re: libtool fails with uninstalled frameworks and the -F flag

2014-01-13 Thread Gary V. Vaughan
Hi Michael,

[moved to libtool-patches list]

On Jan 14, 2014, at 11:45 AM, Michael C. Grant  wrote:

> I'm trying to compile GNU Octave and its new Qt GUI on a Mac OSX with 
> Homebrew. Homebrew installs the Qt frameworks in 
> /usr/local/Cellar/qt/4.8.5/lib, so after some fiddling with the configure 
> script I get this:
> 
> QT_LDFLAGS=-F/usr/local/Cellar/qt/4.8.5/lib
> QT_LIBS=-framework QtCore -framework QtGui -framework QtNetwork
> 
> However, the libtool script does not handle the -F argument through properly, 
> so it is stripped out of the linking process.
> 
> I created the following patch for the generated libtool script, which causes 
> libtool to treat -F exactly like it treats -L. This seems to do the trick.
> 
> I did notice that scanning through past discussions that this has come up a 
> couple of times, but there is reluctance to provide full support for -F for 
> some reason. Perhaps the relative simplicity of this patch would convince you 
> to reconsider. I'm also discussing this with the Homebrew folks to see if 
> they would consider including in their formula, but they do prefer not to use 
> patches if they can help it.

Thanks for the patch.  Sorry I didn't reply to your earlier emails - I marked 
them for further attention, but didn't make the time to actually go back and 
respond.

My main worry is whether that changing libtool's treatment of -F is going to do 
something unexpected on another platform.  That said, apart from your 
conflating of -L and -F in the case branches with the patch you sent, I'm open 
to including it in the upcoming release if you don't mind reworking it a little?

Please keep the -L and -F branches separate, factoring the branch bodies into a 
shell function if necessary to prevent cut-n-pasting blocks of code between the 
two.  Bonus points if you could also make -F behave as before on all platforms 
but *-darwin*.

If you have github, I keep a mirror of libtool at 
http://github.com/gvvaughan/GNU-libtool, so that might be a more convenient way 
for you to submit a pull request than dropping patch attachments into the 
mailing list.

I have a couple of small fixes of my own that I need to polish and push, and 
then I'll do another round of platform testing to nail down what else is a 
show-stopper for a final pre-release.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: [SCM] GNU Libtool branch, master, updated. v2.4.2.444-2-g581d90b

2014-01-02 Thread Gary V. Vaughan
Hi Peter,

On Jan 3, 2014, at 11:55 AM, Peter Rosin  wrote:

> On 2014-01-02 01:32, Gary V. Vaughan wrote:
>>Peter's a7462c5 fix was applied to the generated bootstrap script
>>instead of the funclib.sh source, and had have been overwritten
>>the next time bootstrap was regenerated.
> 
> Nice catch! As my feeble defense, I claim that there should have been a
> "generated, do not edit" comment in the files that are generated with
> funclib.sh. :-)

┌─┤gary@kamala│~/Dropbox/Projects/libtool--devo--0  

  ├!68795=grep -i 'do not edit' bootstrap   
│master│95e1f34│
## DO NOT EDIT THIS FILE, CUSTOMIZE IT USING A BOOTSTRAP.CONF ##
## DO NOT EDIT THIS FILE! ##

:-p

Joking aside, you're quite right, I'll shuffle the order of bootstrap.in
to leave that warning at the top, and remove the write bit from the
generated file.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


signature.asc
Description: Message signed with OpenPGP using GPGMail


[PATCH] avoid undefined symbols with SunStudio12 f77/f90 in FORTRAN autotests

2013-12-21 Thread Gary V. Vaughan
Hi,

I don't know FORTRAN, or whether this patch is actually sensible, so I'm
posting here for feedback from someone more familiar with such things than
me.  Unless someone tells me that this is wrong, I'll apply in a few days.

First of all, modern SunStudio f77 is just a wrapper for f90, which
explains why current master fails these test groups with:

  Undefined first referenced
   symbol   in file
  __f90_slw_ch  .libs/foof2.o  (symbol belongs to implicit dependency 
/opt/solstudio12.2/lib/libfsu.so.1)
  __f90_sslw.libs/foof2.o  (symbol belongs to implicit dependency 
/opt/solstudio12.2/lib/libfsu.so.1)
  __f90_eslw.libs/foof2.o  (symbol belongs to implicit dependency 
/opt/solstudio12.2/lib/libfsu.so.1)
  ld: fatal: symbol referencing errors. No output written to 
.libs/libfoo2.so.0.0.0

There are two ways to work around this failure:

  1. Add $(FLIBS) to all xx_la_LIBADD lines, which is unlikely to be
 remembered by anyone not using SunStudio because it works fine
 without everywhere else.  Further, the final demo links continue
 to fail for a lack of a printf definition -- but that might well
 be another bug in the tests.  Should we also be adding -lc to a
 mixed mode link?  In the test Makefiles, or automatically with
 libtool?

  2. Allow some undefined symbols in the libraries, which are resolved
 by the $(FLIBS) added to the final binaries in the tests.  This
 seems like the simpler, and less error inducing solution to me.

Comments?

Cheers,
Gary

Index: tests/f77demo.at
===
--- tests/f77demo.at.orig
+++ tests/f77demo.at
@@ -63,17 +63,13 @@ ACLOCAL_AMFLAGS = -I m4
 lib_LTLIBRARIES = libfoo.la libmix.la libfoo2.la libfoo3.la

 libfoo_la_SOURCES = foof.f
-libfoo_la_LDFLAGS = -no-undefined
 libfoo_la_LIBADD = libfoo2.la

 libfoo2_la_SOURCES = foof2.f
-libfoo2_la_LDFLAGS = -no-undefined

 libfoo3_la_SOURCES = foof3.f
-libfoo3_la_LDFLAGS = -no-undefined

 libmix_la_SOURCES = foof.f foof2.f fooc.c
-libmix_la_LDFLAGS = -no-undefined

 noinst_HEADERS = foo.h

Index: tests/fcdemo.at
===
--- tests/fcdemo.at.orig
+++ tests/fcdemo.at
@@ -67,17 +67,13 @@ ACLOCAL_AMFLAGS = -I m4
 lib_LTLIBRARIES = libfoo.la libmix.la libfoo2.la libfoo3.la

 libfoo_la_SOURCES = foof.f90
-libfoo_la_LDFLAGS = -no-undefined
 libfoo_la_LIBADD = libfoo2.la

 libfoo2_la_SOURCES = foof2.f90
-libfoo2_la_LDFLAGS = -no-undefined

 libfoo3_la_SOURCES = foof3.f90
-libfoo3_la_LDFLAGS = -no-undefined

 libmix_la_SOURCES = foof.f90 foof2.f90 fooc.c
-libmix_la_LDFLAGS = -no-undefined

 noinst_HEADERS = foo.h



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: git commit forces bootstrap

2013-12-08 Thread Gary V. Vaughan
On Dec 9, 2013, at 11:52 AM, Peter Rosin  wrote:
> ok to push?

Just to reiterate: I found the barrier for contributing to libtool had
become insanely high in years past, to the point where even I found it
hard to motivate myself to push the smallest of straight forward patches
through...

Nowadays: git makes it very easy to fix up an error after the fact, and
I want to knock down the barrier, so if you have made a good effort to
test your patches, and you have a commit bit, just go ahead and push...
unless you are worried your patch is not right conceptually or something.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: bootstrap breakage starting with fec7d87

2013-11-19 Thread Gary V. Vaughan

On Nov 20, 2013, at 12:32 PM, Gary V. Vaughan  wrote:

> Hi Ozkan, Petor,

^H^H^H^H^H^H^HPeter,  *blush*


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: bootstrap breakage starting with fec7d87

2013-11-19 Thread Gary V. Vaughan
Hi Ozkan, Petor,

On Nov 19, 2013, at 11:57 PM, Peter Rosin  wrote:

> On 2013-11-19 10:08, Ozkan Sezer wrote:
>>> Starting with fec7d87 ("funclib.sh: simplify version comparison
>>> functions") I am getting the following error from bootstrap:
>>> 
>>> bootstrap:   error:   'makeinfo' version == 4.13 is too old
>>> bootstrap:'makeinfo' version >= 4.8 is required
>>> 
>>> 9fd7b88 is fine.
>>> 
>>> This is with Fedora 16, with grep-2.9-3.fc16.x86_64,
>>> sed-4.2.1-9.fc16.x86_64, and bash-4.2.37-1.fc16.x86_64
>>> 
>> 
>> Will this be fixed anytime soon?
> 
> Yes, please.

Ouch, sorry about that.

> I came up with this patch, but I don't know how portable it is, so I would
> like someone knowledgeable to comment on it before pushing it...

I don't have access to any Windows environments, but your patch works
correctly for me on various flavours of  Mac OS, GNU/Linux, Solaris, HPUX,
and AIX -- I no longer have access to Tru64 Unix, SCO Unix or IRIX.

Thanks for the quick fix.  Assuming it works on cygwin, mingw and other
windows variants we support, please go ahead and push.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: bug#15734: libtool 2.4.2.418 in UnixWare

2013-10-27 Thread Gary V. Vaughan
Hi Tim,

Thanks for the report.

On Oct 28, 2013, at 9:06 AM, Tim Rice  wrote:

> On Sun, 27 Oct 2013, Tim Rice wrote:
> 
> | On Sun, 27 Oct 2013, Tim Rice wrote:
> | 
> | > 
> | > UnixWare 7.1.4
> | > 
> | > Things don't look so good on the alpha release.
> | > ..
> | >To: 
> | >Subject: [GNU Libtool 2.4.2.418] testsuite: 9 10 11 15 16 18 21 122 
> 123 124 125 129 failed
> | > ..
> | 
> | Saw this in the build log.
> | --
> |   GEN  libtoolize
> | UX:sed: ERROR: Command garbled:   s|^m4trace: -1- 
> AC_CONFIG_AUX_DIR[([]*||
> |   GEN  libltdl/argz.h
> | --
> 
> This patch helps some.
> 
> .
> --- libtool-2.4.2.418/Makefile.am.old 2013-01-25 20:19:11.0 -0800
> +++ libtool-2.4.2.418/Makefile.am 2013-10-27 12:13:43.776276925 -0700
> @@ -248,7 +248,7 @@
> ##  ##
> 
> abs_aux_dir = `$(lt__cd) '$(srcdir)/$(aux_dir)' && pwd`
> -ltdl_ac_aux_dir = `$(extract_trace) AC_CONFIG_AUX_DIR 
> $(srcdir)/libltdl/configure.ac`
> +ltdl_ac_aux_dir = `SED=$(SED) $(extract_trace) AC_CONFIG_AUX_DIR 
> $(srcdir)/libltdl/configure.ac`
> 
> configure_edit = $(bootstrap_edit) \
>   -e '/^\. /s|@auxscriptsdir\@|'$(abs_aux_dir)'|g' \
> .
> 
>   To: 
>   Subject: [GNU Libtool 2.4.2.418] testsuite: 21 122 123 124 125 129 failed
> 


Most of the remaining failures seem to be caused by the unset variable in the 
testsuite
getting set to ‘no’ rather than ‘unset’ or ‘:’ as was originally intended on 
your host.
However, Autotest already provides as_unset, so the following patch switches to 
that:

diff --git a/tests/demo.at b/tests/demo.at
index f1fd9a8..c0a1486 100644
--- a/tests/demo.at
+++ b/tests/demo.at
@@ -796,7 +796,7 @@ rm -f libhello.la "hell$EXEEXT"

 # If this check fails (i.e. the make succeeds), then the installed library
 # was used, which is wrong.
-AT_CHECK([$unset LIBTOOL LIBTOOLIZE; $MAKE hell$EXEEXT 
libhello_la_OBJECTS=hello.lo || (exit 1)],
+AT_CHECK([$as_unset LIBTOOL; $as_unset LIBTOOLIZE; $MAKE hell$EXEEXT 
libhello_la_OBJECTS=hello.lo || (exit 1)],
  [1], [ignore], [ignore])

 AT_CLEANUP
diff --git a/tests/testsuite.at b/tests/testsuite.at
index ecbdfc2..99122be 100644
--- a/tests/testsuite.at
+++ b/tests/testsuite.at
@@ -51,11 +51,6 @@ fi
 if test -n "$to_tool_file_cmd"; then
   configure_options="$configure_options 
lt_cv_to_tool_file_cmd=$to_tool_file_cmd"
 fi
-if (FOO=bar; unset FOO) >/dev/null 2>&1; then
-  unset=unset
-else
-  unset=false
-fi
 : ${mkdir_p="$abs_top_srcdir/build-aux/install-sh -d"}
 # Fix relative paths in $lt_INSTALL
 case $lt_INSTALL in
@@ -193,7 +188,7 @@ m4_define([LT_AT_CONFIGURE],
 m4_define([LT_AT_MAKE],
 [for target in m4_default([$1], [all])
 do
-  AT_CHECK([$unset LIBTOOL LIBTOOLIZE; $MAKE $target $2], [0], [ignore], 
[ignore])
+  AT_CHECK([$as_unset LIBTOOL; $as_unset LIBTOOLIZE; $MAKE $target $2], [0], 
[ignore], [ignore])
 done
 ])

I’ve pushed this patch already.

The remaining failure looks to be a similar problem to the sed issue you 
discovered but with
grep.  Since extract-trace is supposed to work standalone, I’ll find a way to 
have funclib.sh
find a suitable sed and grep, which will fix not only the problems your patch 
works on, but
also the remaining test failure, and no doubt similar latent bugs in other 
funclib.sh clients
(bootstrap and libtoolize).

Please, let me know if your still having issues after that.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: Bad IFS initialisation breaks gcc build of libsanitizer

2013-08-23 Thread Gary V. Vaughan
Hi Alan,

On Aug 23, 2013, at 7:24 PM, Alan Modra  wrote:
> Putting tab first in IFS breaks func_echo_all usage of $*,
> resulting in failure of func_infer_tag to match a command line using a
> $CC with trailing spaces.  The trailing spaces were stripped out of
> CC_expanded but words in $CC were separated by tabs.  This didn't
> match the makefile expansion of $CC using the standard IFS with a
> first char of space.
> 
>   * gl/build-aux/funclib.sh (IFS): Make first char a space.

Nice catch.  Applied - funclib.sh is used by libtoolize too, so
you've likely fixed a latent bug there as a bonus :)

This situation came about due to a historical accident, where self
tests prohibited  by default (for obvious reasons), before
we switched to sp=' '.  Now that you point it out, I'm surprised it
hasn't tripped us up sooner.  Thanks for the patch.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: Patch for mips64 libtool.m4

2013-08-23 Thread Gary V. Vaughan
Hi Steve,

On Aug 20, 2013, at 4:35 AM, Steve Ellcey  wrote:

> A user was trying to build the buildroot product for mips64 with the -mabi=64
> option and ran into a libtool problem when building libiscsi because it calls
> the linker via libtool and the linker was defaulting to the n32 ABI instead of
> the 64 bit ABI.  This patch to libtool.m4 checks for the correct ABI to use
> like IA64, AIX, and other platforms already do and passes the correct 
> emulation
> mode into the linker.
> 
> I am hoping someone can review this patch and check it in to libtool, though
> the list appears very quiet lately.

Thanks for the patch.  Applied.

I took the liberty of writing a ChangeLog entry for you, correcting some
syntax standards violations flagged by 'make syntax-check', and then massaging
a little to match the surrounding code better.  Please pull the latest revision
and check that I didn't break your patch in the process.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: [patch] Comments for linker-option section, was Re: powerpc*le-linux support

2013-08-22 Thread Gary V. Vaughan
Hi Brooks,

On Aug 23, 2013, at 5:52 AM, Brooks Moses  wrote:
> Based on Alan's explanation and what I could tell from looking at the code, 
> I've tried to expand the comments to explain what's going on, as per the 
> attached patch.  Does this look like a useful improvement to the situation?

Perfect!

And applied.  Many thanks.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: Two-month patch ping: Re: powerpc*le-linux support

2013-08-22 Thread Gary V. Vaughan
Hi Alan,

Thanks for the fast feedback.

On Aug 22, 2013, at 10:48 PM, Alan Modra  wrote:
> On Thu, Aug 22, 2013 at 09:34:10PM +0700, Gary V. Vaughan wrote:
>>> How can it be correct to say "-m elf32lppclinux" (32-bit) when $host is
>>> explicitly 64-bit? That seems like utter garbage to me. What am I
>>> missing this time?
> 
> As far as I understand, this piece of libtool is supplying ld options
> when your host compiler defaults to something other than what $host
> implies.  Which sounds very strange, but consider that on a
> powerpc64-linux host your gcc will usually compile to both 32-bit and
> 64-bit objects.  Both 32-bit and 64-bit objects will run on the host,
> and whether gcc produces 32-bit by default (most common a few years
> ago) or 64-bit (most common now), depends on how gcc was configured.
> 
> So if $host is powerpc64-linux and $CC is gcc and gcc produces 64-bit
> by default, and $LD is powerpc64-linux-ld then no ld options are
> needed.  When generating 32-bit libraries on this system, $host is
> powerpc-linux, $CC is still gcc, and $LD may be powerpc-linux-ld.
> That's a problem because $CC with no options produces 64-bit objects
> but $LD with no options is expecting 32-bit.
> 
> This is all somewhat of a guess on my part, but I've seen these $LD
> and $CC selections.  Most configure scripts seem to prefer
> "powerpc64-linux-ld" over plain "ld" when $host is powerpc64-linux,
> and similarly "powerpc-linux-ld" for $host of powerpc-linux.
> 
>> I don't get it either, and I can't test it.

Thanks for the explanation, I finally do get it.  Phew :)

>>  I trust the ppcle community
>> will commence shouting if the patches have done something horrible.
> 
> It's broken.  Please apply exactly the tested patch I submitted, or if
> powerpc-* and similar in the switch statement is somehow the wrong
> style (we've tested for powerpc*-*linux* already!), then make them
> powerpc-*linux*.  Not powerpc*-*linux*, which is exactly the same
> mistake I made with my first patch..

I believe I already fixed it with the most recent amendment committed
under your name (exactly by removing the errant * from the case branch
matches).  Please pull the most recent revision and let me know if I still
didn't fix everything I broke recently.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: Two-month patch ping: Re: powerpc*le-linux support

2013-08-22 Thread Gary V. Vaughan
Hi Peter,

On Aug 22, 2013, at 8:58 PM, Peter Rosin  wrote:
> On 2013-08-22 10:20, Gary V. Vaughan wrote:
>> On Aug 22, 2013, at 2:54 PM, Peter Rosin  wrote:
>>> On 2013-08-22 09:40, Gary V. Vaughan wrote:
>>>>> Can we please get this simple patch pushed?
>>>> 
>>>> Done.
>>> 
>>> To me, it appears as if what you actually pushed was not what was posted?
>> 
>> I am an idiot.  Thanks for the heads up, fixed in the following change set.
> 
> Still not right though, sorry.

Indeed.  I am still an idiot.  I am the one who needs to apologise here, thank
you for paying attention and catching it so quickly.

Note to self: make sure to only apply patches directly from emails from now on.

> You ended up doing:
> 
> -   ppc64-*linux*|powerpc64-*linux*)
> +   powerpcle-*)
> + LD="${LD-ld} -m elf32lppclinux"
> + ;;
> +   powerpc-*)
> 
> but the original wanted:
> 
> -   ppc64-*linux*|powerpc64-*linux*)
> +   powerpc64le-*)
> + LD="${LD-ld} -m elf32lppclinux"
> + ;;
> +   powerpc64-*)
> 
> But, the originally supplied version confuses me yet again, so I'm not
> committing the fix myself...
> 
> How can it be correct to say "-m elf32lppclinux" (32-bit) when $host is
> explicitly 64-bit? That seems like utter garbage to me. What am I
> missing this time?

I don't get it either, and I can't test it.  I trust the ppcle community
will commence shouting if the patches have done something horrible. However,
if there is any nonsense here, it predates my recent patch butchering,
because even the pre-patched code seems to mix 32bit and 64bit concepts
liberally.

If someone would like to apply (or send me) a patch that adds a comment
explaining why this code needs to look so odd, that would be very helpful!

Hopefully the repository at least reflects the changes you wanted now in
any case.  Sorry for the earlier sloppiness.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: powerpc*le-linux support

2013-08-22 Thread Gary V. Vaughan
Hi Peter,

On Aug 22, 2013, at 3:19 PM, "Gary V. Vaughan"  wrote:
>> All other inner cases match one of the outer or-ed expressions (i.e.
>> from the first hunk) quite closely, but the outer match is still
>> powerpc*-*linux* while the inner match has dropped the trailing
>> -*linux* part. I would have kept them in sync.
> 
> The other branches are inconsistent here too, so either is fine IMHO.

Oh, I see what you mean, and I agree.  I was fixating on the *linux*
suffix.  Fixed, thanks.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: Two-month patch ping: Re: powerpc*le-linux support

2013-08-22 Thread Gary V. Vaughan
Hi Peter,

On Aug 22, 2013, at 2:54 PM, Peter Rosin  wrote:

> On 2013-08-22 09:40, Gary V. Vaughan wrote:
>>> Can we please get this simple patch pushed?
>> 
>> Done.
> 
> To me, it appears as if what you actually pushed was not what was posted?

I am an idiot.  Thanks for the heads up, fixed in the following change set.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: powerpc*le-linux support

2013-08-22 Thread Gary V. Vaughan
On Aug 22, 2013, at 2:59 PM, Peter Rosin  wrote:
> Hi!
> 
> Ok, Gary pushed something while I wrote this, but I'm sending it
> anyway since what he pushed didn't look quite right to me…

Argh.  I pasted the patch from my browser to a terminal to save hunting
my archives for the original email, and mangled the hunks during application.
I pushed a fix too, so that the last two commits do match the original
patch.

> On 2013-06-06 07:18, Alan Modra wrote:
>> On Thu, Jun 06, 2013 at 11:31:34AM +0930, Alan Modra wrote:
>>> This adds support for little-endian powerpc linux, and tidies the
>>> existing host match for powerpc.  config.sub won't return ppc*-*linux*
>>> so there isn't much point in matching that.
>> 
>>> - ppc*-*linux*|powerpc*-*linux*)
>>> + powerpcle*)
>>> +   LD="${LD-ld} -m elf64lppc"
>>> +   ;;
>>> + powerpc*)
>>> LD="${LD-ld} -m elf64ppc"
>>> ;;
>> 
>> I didn't get that quite right.  'powerpc*' in the above matches too
>> much, for example when your host is powerpc64-linux and target
>> powerpc64le-linux you'll get -melf64ppc added to LD.  Since
>> powerpc64le-linux-ld wants -melf64lppc (or nothing) that will fail.
>> Revised as follows.
>> 
>>  * m4/libtool.m4 (ld -m flags): Remove non-canonical ppc host match.
> 
> The macro/function you are changing is _LT_ENABLE_LOCK, so that should be
> 
>   * m4/libtool.m4 (_LT_ENABLE_LOCK): …

Agreed.  I should have checked and changed that on commit, my bad.

>>  Support little-endian powerpc linux host.
>> 
>> diff --git a/m4/libtool.m4 b/m4/libtool.m4
>> index d7013c5..501246d 100644
>> --- a/m4/libtool.m4
>> +++ b/m4/libtool.m4
>> @@ -1307,7 +1307,7 @@ ia64-*-hpux*)
>>   rm -rf conftest*
>>   ;;
>> 
>> -x86_64-*kfreebsd*-gnu|x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*| \
>> +x86_64-*kfreebsd*-gnu|x86_64-*linux*|powerpc*-*linux*| \
>> s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
>>   # Find out which ABI we are using.
>>   echo 'int i;' > conftest.$ac_ext
>> @@ -1328,7 +1328,10 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
>>  ;;
>>  esac
>>  ;;
>> -  ppc64-*linux*|powerpc64-*linux*)
>> +  powerpc64le-*)
>> +LD="${LD-ld} -m elf32lppclinux"
>> +;;
>> +  powerpc64-*)
>>  LD="${LD-ld} -m elf32ppclinux"
>>  ;;
>>s390x-*linux*)
> 
> All other inner cases match one of the outer or-ed expressions (i.e.
> from the first hunk) quite closely, but the outer match is still
> powerpc*-*linux* while the inner match has dropped the trailing
> -*linux* part. I would have kept them in sync.

The other branches are inconsistent here too, so either is fine IMHO.

> This also made me think
> about the 32-bit case; is there no le variant for 32-bit powerpc?
> Compare with the x86_64 case just above this hunk. To me, it seems as
> if -m elf32lppclinux should be added to $LD at least in some case?

That's only because I fumbled the initial commit.  The original patch
catches ppcle on 32 and 64 bit legs of that case statement.

> When you build 32-bit output and $host is 64-bit, you need to specify
> endianess (elf32lppclinux or elf32ppclinux). When you build 64-bit
> output and $host is 64-bit, you need to specify endianess (elf64lppc
> or elf64ppc). I miss the case when you build 32-bit output and $host
> is 32-bit, i.e. something like the below (assuming $host is
> powerpcle-* and powerpc-* for 32-bit) at the end of the second hunk:
> 
> +   powerpcle-*linux*)
> + LD="${LD-ld} -m elf32lppclinux"
> + ;;
> +   powerpc-*linux*)
> + LD="${LD-ld} -m elf32ppclinux"
> + ;;
> 
> If there is no 32-bit le powerpc variant (why wouldn't there be?), then
> the subject is somewhat misleading when le is only handled for 64-bit
> hosts.
> 
>> @@ -1347,7 +1350,10 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
>>x86_64-*linux*)
>>  LD="${LD-ld} -m elf_x86_64"
>>  ;;
>> -  ppc*-*linux*|powerpc*-*linux*)
>> +  powerpcle-*)
>> +LD="${LD-ld} -m elf64lppc"
>> +;;
>> +  powerpc-*)
>>  LD="${LD-ld} -m elf64ppc"
>>  ;;
>>s390*-*linux*|s390*-*tpf*)
>> 
>> 
> 
> Or what am I not getting? I'm probably just ignorant...ö

Without access to ppc linux compilers and cross compilers, I only ran
the test suite on 

Re: Two-month patch ping: Re: powerpc*le-linux support

2013-08-22 Thread Gary V. Vaughan
Hi Brooks, Alan,

On Aug 22, 2013, at 12:59 AM, Brooks Moses  wrote:

> Ping?
> 
> (And adding libtool@, in hopes of getting a little more attention, as pings 
> on libtool-patches@ seem to be going nowhere.)
> 
> On 06/05/2013 07:01 PM, Alan Modra wrote:
>> This adds support for little-endian powerpc linux, and tidies the
>> existing host match for powerpc.  config.sub won't return ppc*-*linux*
>> so there isn't much point in matching that.
>> 
>>  * m4/libtool.m4 (ld -m flags): Remove non-canonical ppc host match.
>>  Support little-endian powerpc linux host.
> 
> (http://lists.gnu.org/archive/html/libtool-patches/2013-06/msg1.html)
> 
> It's been two and a half months since this patch was posted, without any 
> review or response.

My sincere apologies.  Sadly, your patch is among a backlog of unapplied 
patches that
are growing faster than I can keep up alongside my current workload :(

> Can we please get this simple patch pushed?

Done.

> I understand maintainers becoming busy and/or moving on to other things and 
> being unable to keep up -- I've been there, too.  What can we do to help?

Thank you immensely for your extreme patience.

The problem has become triaging the unapplied patches from the mailing-list.

My involvement with libtool has almost always been new features and release
management, and extremely sporadic (I work on libtool a lot in bursts of a
month or two here and there, between long gaps of several months) - which has
been fine until recently, because there have always been sufficient maintainers
to keep up with the backlog.  That is obviously no longer the case :(

Would you, or anyone else you know be interested in helping with the somewhat 
dull,
but very important process of applying patches that obviously move libtool 
forward,
asking for revisions to patches that could be useful but are obviously lacking 
in
some way, and flagging the rest for further review by me (in the remaining non-
obvious cases)? That would help immensely in getting libtool over the current 
state
of stagnation…

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: bug#13414: Valid DLL def file mangled by libtool

2013-01-18 Thread Gary V. Vaughan
Hi Peter,

Thanks for working on this.

On 19 Jan 2013, at 05:55, Peter Rosin  wrote:
> On 2013-01-12 01:26, Peter Rosin wrote:
>> On 2013-01-11 12:34, Martin Doucha wrote:
>>> I'd like to report a bug in libtool 2.4 (including the latest git revision) 
>>> which mangles valid DLL def files under MinGW and makes the linker barf.
>> 
>> This issue has been reported before [1].
> 
> So, as hinted above, I'm following up with a pair of patches that
> appear to mend this.
> 
> Ok to push?

By inspection, these patches look good to me - presuming there are no 
regressions, please go ahead.

One nit: your new test has a Copyright notice starting at 2007 followed by 
"written in 2013". The new code doesn't look derivative of existing tests, so 
I'd suggest deleting the years prior to 2013 before pushing.

> Or are the white-space changes in the first patch too intrusive?

If you would like to separate those into a separate patch then please feel 
free; but I'd rather see functional progress in Libtool development than being 
overly anal about changeset minutiae for potential future git archaeology at 
the expense of using your Libtool hacking time more wisely :)

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


Re: [PATCH] Add Bitrig support

2013-01-02 Thread Gary V. Vaughan
Hi Brad,

On 2 Jan 2013, at 15:17, Brad Smith  wrote:
> On Wed, Jan 02, 2013 at 01:31:15AM +0700, Gary V. Vaughan wrote:
>> The patch content looks innocuous enough to me, and I'd like to commit
>> it to master... but first, would you mind regenerating agaist current
>> git master (ltmain.m4sh does not exist any more!), and also writing a
>> commit log entry suitable for inclusion in the generated ChangeLog
>> file at release time?
> 
> How about the following?
> [[patch content snipped]]

Thanks, yes that's much easier to apply.

I took the liberty of editing the patched code very lightly to maintain
alphabetical ordering where possible, and your tweaking your NEWS and
ChangeLog entries to match existing style.  The git commit hook will post
that version to libtool-com...@gnu.org presently so you can compare.

Please let me know if I broke anything during editing.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



Re: [PATCH] Add Bitrig support

2013-01-01 Thread Gary V. Vaughan
Hi Brad,

On 29 Dec 2012, at 08:50, Brad Smith  wrote:
> On Tue, Aug 21, 2012 at 11:50:21PM -0400, Brad Smith wrote:
>> The following diff adds support for Bitrig, which is a
>> fork of OpenBSD.
> 
> ping.

Thanks for the patch, and sorry for the delay in reviewing it.

The patch content looks innocuous enough to me, and I'd like to commit
it to master... but first, would you mind regenerating agaist current
git master (ltmain.m4sh does not exist any more!), and also writing a
commit log entry suitable for inclusion in the generated ChangeLog
file at release time?

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)





Re: [RFC] Fix libltdl preloader issues with MSVC

2012-10-19 Thread Gary V. Vaughan
Hi Peter,

On Oct 20, 2012, at 4:06 AM, Peter Rosin  wrote:
> With the latest dumpbin work in place, libtool starts to add
> symbols from import libraries to the generated fooS.c files
> in func_generate_dlsyms, as needed by the preloader. And then
> the next problem naturally rears its head. This time it is
> the age-old data exports problem responsible for code such
> as this (in demo.at):
> 
> else if (STREQ ("nothing", name))
> #ifndef _WIN32
>  /* In an ideal world we could do this... */
>  pnothing = (int*)s->address;
> #else /* !_WIN32 */
>  /* In an ideal world a shared lib would be able to export data */
>  pnothing = (int*)¬hing;
> #endif
> 
> I.e., demo.at isn't even trying to use the data symbol from the
> preloader, it just picks data up directly using the import
> library on Windows. Which is of course cheating and circumvents
> the API etc etc. However, MinGW has long supported pseudo-relocs
> and anto-import and the "Ideal world" case should work just fine
> with gcc even on _WIN32. But not with MSVC, which fails to link
> since data symbols from import libraries are not declared
> __declspec(dllimport).

That's because demo stems from the original test code that Gord
wrote over 15 years ago alongside the embryonic preloading
implementation, all before the current API was available! :)

Having said that, it's kinda nice to have this test of the low-level
structure of preloaded library data, although calling it demo might
seem like we're still encouraging folk to use preloaded libraries
this way :(  If you feel inclined to move the existing low-level tests
aside and rename them to something less inviting, and then rewrite
the demo tests to actually use the API that would be great for our
test coverage too!

> Example from demo.at:
> 
> helldl.exeS.obj : error LNK2001: unresolved external symbol _nothing
> 
> Fixing that, and making data symbols __declspec(dllimport) is
> however not the entire solution, as that yields:
> 
> helldl.exeS.c(47) : error C2099: initializer is not a constant
> 
> during compilation instead.
> 
> The underlying problem is that MSVC does not have pseudo-relocs.

More hoops to jump through at the Microsoft circus.  Hurray!

> So, this patch adds an @INIT@ entry to the preloader symbol
> table, with the address of a function that is intended to do the
> relocations of data items from user-provided code instead of
> relying on the tools. This function is then filled with
> relocation code for MSVC, but left empty everywhere else
> where it is not needed.
> 
> This is clearly not a finalized patch (it's actually pretty
> rough), it's just proof of concept. I have e.g. not optimized
> it, but it is clearly possibly to set the @INIT@ address to
> NULL and don't call @INIT@ at all in non-MSVC cases. It should
> also not be necessary to relocate data symbols from static
> libraries from user code, and it should be possible to add a
> "done" variable to the relocation function, so that it only
> does the work once.
> 
> What I'm looking for is feedback. Is it acceptable to add a
> new virtual @INIT@ entry like this?  I.e. is this approach
> workable or should I just drop it?

I have no objections, except perhaps that it would be good to check
that the ABI doesn't stop pre-patch libltdl from preloading libraries
built with post-patch libtool.  But that's likely overly pedantic of me,
since I don't think anyone is likely to preload libraries built from a
different package (potentially using different libtool versions)... but
if it's easy to be compatible, we might as well do that.

I can't think of any other use for @INIT@ than beating MSVC into
submission, but as long as you can do the final implementation
cleanly enough that it doesn't force all the well behaved platforms
to carry around dead weight for MSVC (eg not adding @INIT@ to
the symbol list when it's not going to be used), and that we can keep
everything nicely separated so that people who don't need to
understand it to contribute in other areas can easily skip past... then,
sure, go right ahead :)

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



Re: git-version-gen w/o git

2012-10-18 Thread Gary V. Vaughan
On Oct 18, 2012, at 7:50 PM, Peter Rosin  wrote:
> Hi!

Hi Peter,

> I used to use a libtool git checkout from a platform that lacks
> git [MSYS], but that broke at some point. I would like something
> like the below to unbreak my work flow.
> 
> Please?
> [[patches snipped]]

That looks like a reasonable request, useful to more folks than
just you.  You should propose your patches to bug-gnu...@gnu.org,
and when accepted, add the extra support on this side if necessary.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



Re: Windows Line Endings

2012-10-06 Thread Gary V. Vaughan

On 6 Oct 2012, at 14:05, "Gary V. Vaughan"  wrote:

> Hi Peter,
> 
> On 6 Oct 2012, at 06:20, Peter Rosin  wrote:
>> And lastly libtool.at. It is only \' that is a problem. If I take
>> that char out of the backslashified list, the test is ok.
>> Another data point is that if I replace the grep on line 110 like
>> this:
>> -LT_AT_CHECK([$EGREP 
>> "$mode:.*$match_preflag\"?$flag\\$mchar:test\\$mchar\"? " stdout], 
>> [0], [ignore])
>> +LT_AT_CHECK([$EGREP 
>> "$mode:.*$match_preflag\"?$flag$mchar:test$mchar\"? " stdout], [0], 
>> [ignore])
>> it is ok for \" and \', but not for \$ and \\.
> 
> Actually the \\$ is my mistake, since the point of using LT_AT_CHECK
> rather than straight AT_CHECK is to echo the expanded output to the
> testsuite.log before executing the test, and escaping the $ like that
> defeats the expansion.
> 
>> Looking at LT_ESCAPE in testsuite.at (which is expanded as part of
>> LT_AT_CHECK), it seems to handle \"` specially, but not $.
> 
> Interesting.  Then it looks like it is the echo expansion in LT_AT_CHECK
> that is tripping Windows $SHELL, so moving to straight AT_CHECK will
> remove that problem...
> 
>> My $EGREP is GNU grep 2.6.3 on Cygwin, and GNU grep 2.5.4 on MinGW.
>> 
>> I don't have enough quotefuu to fix this.
> 
> Changing all LT_AT_CHECK to AT_CHECK for the tests formerly in quote.test
> and removing the extra \\ before $ doesn't regress on Mac, where make
> distcheck still succeeds.

Scratch that, on closer inspection there are a couple of thinkos and
portable quoting errors in the original port of quote.test to Autotest.

> I'll push if you can confirm that it fixes the test on Windows for you,
> otherwise we'll have to wait until I have a Windows test environment to
> figure out what I'm missing.

I've pushed what I think is the correct fix.  Let me know if you still
have issues with the test.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


Re: Windows Line Endings

2012-10-06 Thread Gary V. Vaughan
Hi Peter,

On 6 Oct 2012, at 06:20, Peter Rosin  wrote:
> And lastly libtool.at. It is only \' that is a problem. If I take
> that char out of the backslashified list, the test is ok.
> Another data point is that if I replace the grep on line 110 like
> this:
> -LT_AT_CHECK([$EGREP 
> "$mode:.*$match_preflag\"?$flag\\$mchar:test\\$mchar\"? " stdout], 
> [0], [ignore])
> +LT_AT_CHECK([$EGREP 
> "$mode:.*$match_preflag\"?$flag$mchar:test$mchar\"? " stdout], [0], 
> [ignore])
> it is ok for \" and \', but not for \$ and \\.

Actually the \\$ is my mistake, since the point of using LT_AT_CHECK
rather than straight AT_CHECK is to echo the expanded output to the
testsuite.log before executing the test, and escaping the $ like that
defeats the expansion.

> Looking at LT_ESCAPE in testsuite.at (which is expanded as part of
> LT_AT_CHECK), it seems to handle \"` specially, but not $.

Interesting.  Then it looks like it is the echo expansion in LT_AT_CHECK
that is tripping Windows $SHELL, so moving to straight AT_CHECK will
remove that problem...

> My $EGREP is GNU grep 2.6.3 on Cygwin, and GNU grep 2.5.4 on MinGW.
> 
> I don't have enough quotefuu to fix this.

Changing all LT_AT_CHECK to AT_CHECK for the tests formerly in quote.test
and removing the extra \\ before $ doesn't regress on Mac, where make
distcheck still succeeds.

I'll push if you can confirm that it fixes the test on Windows for you,
otherwise we'll have to wait until I have a Windows test environment to
figure out what I'm missing.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


Re: Windows Line Endings

2012-10-05 Thread Gary V. Vaughan
Hi Peter,

On 6 Oct 2012, at 06:20, Peter Rosin  wrote:
> Over to mdemo.at. It fails on MinGW because I do not have
> any installed libltdl in MinGW. Temporarily moving the
> installed Cygwin libltdl out of the lib search path makes
> the test fail on Cygwin as well. So, I believe this is
> a generic failure.

Nice catch!  And thanks for the analysis, that allowed me to get to the root
of the problem pretty quickly:

Legacy mdemo{,2} tests tricked their respective builds into reusing the main
project's libltdlc.la, where I tried to retool the replacement Autotest to
do what a user would do and use the project's own ltdl subproject.  Only I
didn't remove all of the trickery while rewriting the test  :-(

> Without an installed libltdl, I get this
> during configure:
> 
> checking where to find libltdl headers... -I$(top_srcdir)/libltdl
> checking where to find libltdl library... 
> $(top_build_prefix)libltdl/libltdlc.la
> 
> and this when making:
> 
> ../../libtool-msvc/tests/mdemo.at:646: $unset LIBTOOL LIBTOOLIZE; $MAKE 
> $target 
> stderr:
> Makefile:1090: warning: overriding commands for target `libltdl/libltdlc.la'
> Makefile:573: warning: ignoring old commands for target `libltdl/libltdlc.la'
> Makefile:1090: warning: overriding commands for target `libltdl/libltdlc.la'
> Makefile:573: warning: ignoring old commands for target `libltdl/libltdlc.la'
> libtool: link: cannot find the library `libltdl/libltdlc.la' or unhandled 
> argument `libltdl/libltdlc.la'
> make[1]: *** [libmlib.la] Error 1

This means LTDL_INIT is finding the ltdl subtree, but I forgot to remove the
Makefile.am trickery to point $(LIBLTDL) back to $(top_srcdir)/libltdl.

> On Cygwin, with the installed libltdl intact, I get this during
> configure:
> 
> checking where to find libltdl headers... 
> checking where to find libltdl library... -lltdl
> 
> (and the test is ok, in so far one can consider using the
> installed libltdl ok...)

And I also forgot to pass --with-included-ltdl to configure :(

> I'm also noting that some time ago, mdemo had this in it's
> Makefile.am:
> 
> ## use @LIBLTDL@ because some broken makes do not accept macros in targets
> ## we can only do this because our LIBLTDL does not contain ${top_builddir}
> top_distdir = ../..
> @LIBLTDL@: $(top_distdir)/libtool \
>$(top_distdir)/config.h $(srcdir)/$(top_distdir)/libltdl/ltdl.c \
>$(srcdir)/$(top_distdir)/libltdl/ltdl.h
>   (cd $(top_distdir); $(MAKE) `echo $(LIBLTDL) | sed 
> 's,.*\.\./libltdl/,libltdl/,g'`)
> 
> but somewhere along the way, that comment was removed, probably at
> the same time @LIBLTDL@ was converted into $(LIBLTDL). Anyway,
> mdemo.at has this:
> 
> \$(LIBLTDL): ${top_build_prefix}libtool \
>${top_build_prefix}config.h $top_srcdir/libltdl/ltdl.c \
>$top_srcdir/libltdl/ltdl.h
>   cd $top_build_prefix; \$(MAKE) \`echo \$(LIBLTDL) | sed 
> 's|.*\.\./\.\./libltdl/|libltdl/|g'\`
> 
> But the second line of the removed comment seems crucial and
> as our $(LIBLTDL) is not the expected "libltdl/libltdlc.la",
> Automake is fooled into creating two targets for the same
> file. Or something.

Something.  This is the trickery I'm talking about, which needs removing
to let mdemo.at use it's own libltdl.

> Also, the old mdemo had LTDL_CONVENIENCE([../../libltdl]), and the
> new mdemo.at have LT_CONFIG_LTDL_DIR([libltdl]) and
> LTDL_INIT([nonrecursive]), which does not seem entirely equivalent?

Right, because I tried to convert from reusing top-level libltdlc.la to
actually building our own subproject libltdl per-test.

> I don't have enough autofuu to fix this.

I've pushed a patch that fixes all of the above.  Pending as-yet-undiscovered
Windows madness, I think that should allow the test to work on your test
environments too.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


Re: Windows Line Endings

2012-10-05 Thread Gary V. Vaughan
Hi Peter,

Thanks for the other fixes.

On 6 Oct 2012, at 06:20, Peter Rosin  wrote:
> My guess is that f77demo.at and fcdemo.at fails because of
> different stdio streams in their mixed mode programs.
> 
> Tests 159 and 162 (static library) fails because different
> parts of the output has different style line endings with
> \n from the C code and \r\n from the Fortran code. With
> LT_AT_HOST_DATA all line endings are supposed to by \r\n
> and it blows up.
> 
> That's strange I guess, but normalizing stdout with
> LT_AT_UNIFY_NL instead of using LT_AT_HOST_DATA reveals
> another stdio difference in tests 160, 161, 163 and 164.
> In these tests the output from the Fortran code appears
> at the end of the output, not in the middle as expected.
> 
> I thin[k] the cause of this is different usages of the
> stdio libraries. I believe the MinGW gcc is using some
> wrappers around printf to make up for broken stuff in
> the MSVCRT.dll printf and my guess is that MinGW fortran
> is hammering directly on the MSVCRT.dll printf.
> 
> It is perhaps possible to fix this by adding fflush calls
> (and equivalent for Fortran) before switching to the other
> language.
> 
> I don't have enough mingwfuu to fix this. I also don't
> understand why the tests used to work in the old setting?

The legacy testsuite didn't examine the output of the
programs (in any of the *demo series), and simply assumed
that if they linked and executed without error... then
everything was fine.

I had hoped that it would be safe to take advantage of the
better facilities in Autotest, but even on Unix there are
some weird things going on with output ordering in the
fortran demos.  I'm not a fortran programmer, so rather
than try to futz with the (previously working) test cases
themselves, I've weakened the Autotest pass criteria to
grep for something sensible in the output rather than
making assumptions about the entire output stream.

I'm about to push these changes.  Please let me know
whether it fixes your fortran test failures -- It'll take
me a few more days to find the time to build a Windows test
environment.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



Re: Windows Line Endings

2012-10-05 Thread Gary V. Vaughan
Hi Bob,

On 6 ต.ค. 2012, at 1:28, Bob Friesenhahn  wrote:
> On Sat, 6 Oct 2012, Gary V. Vaughan wrote:
>> 
>> I actually run a lot of virtual machines on my Mac, including a couple
>> of versions of Mac OS and Linux, and I certainly wouldn't want to
>> squander perfectly good hardware on an OS that I don't use, and wasn't
>> aware of the 180 days trials, so I'll take a look into that next time I
>> have half a day spare.
> 
> I just forked out $350 for Windows 7 to support free software development.  
> There just did not seem any way around it.  The pain is severe.

Ouch! I can't think of anything I'd like to waste $350 on less
than a piece of paper from Microsoft authorizing me to
depress myself by using their software! My Dell Mini came with Windows 
preinstalled, and cost only $255 from the Dell refurbished online store... of 
course the very first thing I did after taking delivery was reformat the disk 
and install a nicer OS. :-(

>> Do they also have similar trials for MSVC?
> 
> There is "free" MSVC ("Visual Studio Express" in Google) available. It is 
> really intended for .net/C# developers, but by following instructions on the 
> net and adding downloadable "free" SDKs (requires manually editing some 
> configuration files), one can create a Visual Studio capable of building C 
> and C++ code without spending any money.

Thanks for the tip, I'll look into that :-)

>> Any idea what the least painful version of Windows for a VM is these days
>> (I'm guessing XP is still the best)?
> 
> Windows 7 runs very well in VirtualBox.  My wife has been running Windows 7 
> in VirtualBox running on Ubuntu for almost a year now.  I wouldn't recommend 
> that anyone start with XP these days since it is 12 years old, patched beyond 
> all repair, and quickly becoming defunct.

Apart from the number of years you quoted, isn't that true of every version of 
Windows? I think I might go with XP despite your advice though, as I notice 
that one of the stickers glued to my Dell Mini is an XP license number, 
although curiously I didn't get any reinstall media with the netbook - not that 
it contains a CD drive to reinstall from. I can probably find an XP disc at one 
of the street vendor stalls in the center of town for a couple of dollars 
though.

I will try to install it directly in Parallels, rather than in Virtual Box on 
GNU/Linux in Parallels on Mac OS, and then type in the number from the sticker 
on my netbook... and then I'll have to learn how to install mingw and MSYS.

> It is good that you are willing to suffer for the cause.  The cmake build 
> system is quickly becoming popular since it works well for Windows and it is 
> a threat to the GNU build system (as we know it).


We might have better staying power if the Autotools shipped together as a 
single project, and the integration was tight enough not to need a bootstrap 
script just to get things going...

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


Re: Windows Line Endings

2012-10-05 Thread Gary V. Vaughan
Hi Eric,

On 5 Oct 2012, at 23:42, Eric Blake  wrote:
> On 10/05/2012 10:03 AM, Gary V. Vaughan wrote:
>> Is there a legal way to get access
>> to Windows and the various flavours of gcc and MSVC that libtool users
>> care about, without spending hundreds of dollars on software I would
>> never use for anything else?  It pretty much sucks that everytime I
>> push a well tested (on various Unix varieties) patch, that Windows likes
>> to blow up gratuitously.  I don't mind wasting a bit of time checking
>> things on Windows, but I really don't want to also waste money on
>> Microsoft.
> 
> If you are a fan of virtual machines, it is possible to set up qemu-kvm
> under Linux to run a default-60-trial of various Windows versions
> without having to pay for a license.  Microsoft also has a documented
> means of expanding that 60 days into 180 days, which means you can test
> Microsoft products at no monetary cost at the expense of reinstalling
> your virtual machine twice per year.

Thanks for the tip.  That's no different to a working Windows install
anyway... when I worked for a company that forced me to use Windows 95
to connect to their exchange server, it needed to be reinstalled at least
once a year even though all it did was run Out Look all day!

I actually run a lot of virtual machines on my Mac, including a couple
of versions of Mac OS and Linux, and I certainly wouldn't want to
squander perfectly good hardware on an OS that I don't use, and wasn't
aware of the 180 days trials, so I'll take a look into that next time I
have half a day spare.

Do they also have similar trials for MSVC?

Any idea what the least painful version of Windows for a VM is these days
(I'm guessing XP is still the best)?

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



Windows Line Endings [WAS Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-273-ge24f183]

2012-10-05 Thread Gary V. Vaughan
Hi Peter,

Apologies for having entirely forgotten about the old thread reviewing
those patches first time around.

And thanks for looking into it.  Is there a legal way to get access
to Windows and the various flavours of gcc and MSVC that libtool users
care about, without spending hundreds of dollars on software I would
never use for anything else?  It pretty much sucks that everytime I
push a well tested (on various Unix varieties) patch, that Windows likes
to blow up gratuitously.  I don't mind wasting a bit of time checking
things on Windows, but I really don't want to also waste money on
Microsoft.

On 5 Oct 2012, at 22:21, Peter Rosin  wrote:

>> The above looks just like a classic Windows failure. I.e. a line
>> ending mismatch between the expout file created by the posixy
>> shell (\n) and the Win32 program (\r\n) and I would guess that
>> this is a problem that caused failures for Chuck last year as
>> well.
>> 
>> I think you need to use LT_AT_HOST_DATA instead of AT_DATA, where
>> appropriate.
> 
> Unfortunately, the below is not enough since LT_AT_HOST_DATA
> eats whitespace ("  foo" -> "foo") which affects depdemo.at,
> f77demo.at and fcdemo.at. mdemo.at also seems to have
> more trouble that I need to look into...

[[Patch snipped]]

I appear to have arrived at the same patch, and it still passes
make distcheck on Mac OS X.  So LT_AT_HOST_DATA must only eat
whitespace on Windows?  So the fix must be in the windows loop to
rewrite lines with \r\n.  What's wrong with using awk or sed to
inject the additional character rather than shell?  That would seem
to be the obvious solution to me:

  awk '{printf ("%s\r\n", $0);}' < $1 > $1.t && mv -f $1.t $1

(untested on Windows, but doesn't mess with whitespace on Mac or Linux)

Please do push patches that improve the situation for Windows rather
than holding out for a fix-all mega-patch.  This will allow us to
keep each other informed of breakages on platforms the other doesn't
have access to.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)




Re: [PATCH] tests: feed -no-undefined when linking libtool libraries

2012-10-05 Thread Gary V. Vaughan
Hi Peter,

On Oct 3, 2012, at 4:53 PM, Peter Rosin  wrote:
> On 2012-10-03 05:45, Gary V. Vaughan wrote:
>> On Oct 3, 2012, at 12:32 AM, Peter Rosin  wrote:
>>> I just fired up a test suite run...
> 
> Good news! Clean runs on Cygwin, MSYS/MinGW and MSYS/MSVC.

Awesome.

I'll push the merge now, along with some other resurrected patches that
got stuck in the review queue last year.

> Now into nitpicking and other useless ramblings...
> 
> The patch "libtool: unroll nested if into a single case statement" has
> whitespace issues (leading spaces instead of tabs on a few lines), and it
> should perhaps use a simple catch-all "*" (retaining the "fast_install is
> set to needless" comment) as the last case instead of "*,needless" that
> you have put there. But I guess it's harmless as $fast_install is not any
> random string, sans hacks, so no rereredo request from me, just a
> nitpick that I saw when reviewing the "libtool: ..." changes at the
> tip of gary/reredo-test-operand-order. Can always be cleaned up later,
> if someone has the energy.

Agreed on all counts.  Having now split out all the unrelated patches has me
wondering how on earth all that extra crud got in there... especially since 
every
review used to be like a few weeks on the rack.

> I also wonder about the relationship between "libtool: fold if into a
> compound OR statement when more readable" and the next commit "libtool:
> simplify multiple string tests". What I mean is that about half the
> tests from the later commit fit the pattern of the first, why did you
> for example not change
> 
>if test yes,no = "$avoid_version,$need_version"; then
>  major=
>  versuffix=
>  verstring=
>fi
> 
> into
> 
>test yes,no = "$avoid_version,$need_version" && {
>  major=
>  versuffix=
>  verstring=
>}
> 
> (or some such) when you where at it? (but to me it looks like churn)

Yep :(  But, remember these changes are all to match the conflated original
changeset so that we end up with a useful diff showing errors in the original
that can be applied easily to the current tip of master.  That said, your
comments are more than valid, and a lot of that stuff shouldn't really have
gotten in and/or should have been done consistently.

With my newly self appointed benevolent dictator hat on, and the commit
process being infinitely less arduous as a result, I hope to come back and
undo some of this damage prior to freezing for the next release.

> Anyway, to sum up, I'm ok with merging reredo branch into master.
> Lets put this to rest now, thanks!

And thanks to you too :)

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


Re: [PATCH] tests: feed -no-undefined when linking libtool libraries

2012-10-02 Thread Gary V. Vaughan
Hi Peter,

On Oct 3, 2012, at 12:32 AM, Peter Rosin  wrote:
> [snipped loads of stuff]

[snipped a bit more stuff]

> You're saying that you are about to:
> 
> $ git checkout master
> $ git merge --strategy=recursive -X theirs gary/reredo-test-operand-order \
> -m 'bla bla bla'
> 
> right?

Pretty much.  But that's just to show the merge in git history, the end
effect will be identical to having committed the diff back to master.

> Is that better than committing the diff between reredo-... and master
> as a revert-light? Why else would you have gone through all the trouble
> of making all the smaller commits in the first place?

It's better to show the branch merged in for future archaeology; the less
time anyone else has to waste staring at 962aa91, the better a place the
world will be.  And I'm all about making the world a better place! :-)

> I just fired up a test suite run...


Thanks!  I'm crossing my fingers -- I'll sleep a lot better when we've put
this one behind us.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



Re: [PATCH] tests: feed -no-undefined when linking libtool libraries

2012-10-02 Thread Gary V. Vaughan
Hi Peter,

Sorry for the delay, it was more complicated than I had imagined :-o

On 28 Sep 2012, at 11:08, "Gary V. Vaughan"  wrote:
> On 27 ก.ย. 2012, at 5:03, Peter Rosin  wrote:
>> On 2012-09-26 14:57, Peter Rosin wrote:
>>> On 2012-09-22 05:31, Gary V. Vaughan wrote:
>> 
>> [Heavily snipped]
>> 
>>> Why not commit the sc_prohibit_test_const_follows_var improvement
>>> last, after fixing all violations?
>> 
>> That doesn't make sense, sorry. But the idea would have worked
>> initially, before the check first existed. I.e., write the check,
>> fixup violations and commit in smaller digestible chunks, then
>> finally commit the actual check preventing any new violations from
>> creeping in.
> 
> Even then, I'm on the fence, since that doesn't leave a revision to
> demonstrate that the syntax-check is finding the violations... on the
> other hand, we also don't want to push "broken" commits since that
> obviously screws up git bisection.

On reflection, I think I prefer to continue to commit a new syntax check
rule along with all the fixes necessary to make it pass.  Although, I'm
horrified by how much unrelated crap crept into 962aa91, and will not be
tackling any patches even close to this size by hand in future :(

>>>> If not, I will branch before 962aa91, run the script, and then apply
>>>> the rest of master to that branch one patch at a time until I arrive
>>>> at a diff that I can apply to master itself, rather than using revert
>>>> as I did on the current temporary branch.
>>> 
>>> I have to say, given all these difficulties, is it really worth it?
>>> Besides, I think
>> 
>> Hmmm, I said that in the wrong context. Your plan above seems like the
>> best path forward. I guess I was too "excited" about the bugs and didn't
>> read properly, sorry again about my poor communication skills.
> 
> No apologies necessary.  I'm working on the revised redo, which will
> result in a much smaller patch for master later today or tomorrow.

It took me longer than anticipated due to being a lot more work after
untangling all those unrelated parts that I've split out on the branch.

The new branch gary/reredo-test-operand-order (notice the double re) has
everything broken down into digestible chunks.  All the differences between
that and master now look like improvements upon the original hand rolled
version made by my recent scripted revisions, or else outright errors in
the original corrected by the script.  All the errors you flagged on the
list are corrected, as well as several others.

Assuming my running 'make dist' doesn't have any regressions compared to
master, and unless you have additional problems with Windows using the
gary/reredo-test-operand-order branch, I plan to merge the differences
back into master in a day or two.

>> Some of the noise between master and redo-test-operand-order are a bunch
>> of hunks with this pattern:
>> -   if test bar $op $foo; then
>> +   if test bar $op $foo ; then
> 
> Nice catch.  I already tweaked the script regexs to fix that once, but must
> have missed one of the ways for that to happen :(

The script was correctly keeping semi-colons with the same spacing as
was present prior to running the script.  The differences are because
I fixed the errant spacing manually in the original patch.

I'll write another syntax-check, and fix any remaining offenders after
master is fully up to date again.

>> BTW, here is another strange-looking hunk from
>> "git diff master redo-test-operand-order"
>> 
>> diff --git a/m4/libtool.m4 b/m4/libtool.m4
>> index 4413a6d..8ec9beb 100644
>> --- a/m4/libtool.m4
>> +++ b/m4/libtool.m4
>> @@ -5563,7 +5563,7 @@ _LT_EOF
>>  ;;
>>esac
>> 
>> -if test sni = "$host_vendor"; then
>> +if test x$host_vendor = xsni; then
>>  case $host in
>>  sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
>>   _LT_TAGVAR(export_dynamic_flag_spec, $1)='$wl-Blargedynsym'
>> 
>> What has caused the difference in this hunk? Why hasn't the script
>> caught this instance? And why isn't the syntax-check triggered?
>> Are the "missing" quotes the key here?
> 
> Not sure... investigating now.

The lack of quotes on both sides was not picked up by my script
nor by the syntax check, although I made the manual changes in the
original patch.  Once the branches are back in sync, I'll beef
up the syntax check and fix any new violations it finds.

Thanks again for keeping me honest with this one.  Please let me
know if you'd like me to wait more than a day or two to give you
time to review.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)




Re: [PATCH] tests: feed -no-undefined when linking libtool libraries

2012-09-27 Thread Gary V. Vaughan
Hi Peter,

On 27 ก.ย. 2012, at 5:03, Peter Rosin  wrote:
> On 2012-09-26 14:57, Peter Rosin wrote:
>> On 2012-09-22 05:31, Gary V. Vaughan wrote:
> 
> [Heavily snipped]
> 
>> Why not commit the sc_prohibit_test_const_follows_var improvement
>> last, after fixing all violations?
> 
> That doesn't make sense, sorry. But the idea would have worked
> initially, before the check first existed. I.e., write the check,
> fixup violations and commit in smaller digestible chunks, then
> finally commit the actual check preventing any new violations from
> creeping in.

Even then, I'm on the fence, since that doesn't leave a revision to
demonstrate that the syntax-check is finding the violations... on the
other hand, we also don't want to push "broken" commits since that
obviously screws up git bisection.

>>> If not, I will branch before 962aa91, run the script, and then apply
>>> the rest of master to that branch one patch at a time until I arrive
>>> at a diff that I can apply to master itself, rather than using revert
>>> as I did on the current temporary branch.
>> 
>> I have to say, given all these difficulties, is it really worth it?
>> Besides, I think
> 
> Hmmm, I said that in the wrong context. Your plan above seems like the
> best path forward. I guess I was too "excited" about the bugs and didn't
> read properly, sorry again about my poor communication skills.

No apologies necessary.  I'm working on the revised redo, which will
result in a much smaller patch for master later today or tomorrow.

> Some of the noise between master and redo-test-operand-order are a bunch
> of hunks with this pattern:
> -   if test bar $op $foo; then
> +   if test bar $op $foo ; then

Nice catch.  I already tweaked the script regexs to fix that once, but must
have missed one of the ways for that to happen :(

> You should perhaps add a commit to redo-test-operand-order which silences
> that and makes other more substantial changes stand out more before you
> proceed with the above plan? There are perhaps other harmless changes
> that can be excluded from the "light" revert? Because who needs the
> oscillation?

Agreed.  It was all these edge cases that made me abandon the scripted
solution last year.  I'm working on improving the script first to catch this and
the other glitches you found.

> BTW, here is another strange-looking hunk from
> "git diff master redo-test-operand-order"
> 
> diff --git a/m4/libtool.m4 b/m4/libtool.m4
> index 4413a6d..8ec9beb 100644
> --- a/m4/libtool.m4
> +++ b/m4/libtool.m4
> @@ -5563,7 +5563,7 @@ _LT_EOF
>   ;;
> esac
> 
> -if test sni = "$host_vendor"; then
> +if test x$host_vendor = xsni; then
>   case $host in
>   sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
>_LT_TAGVAR(export_dynamic_flag_spec, $1)='$wl-Blargedynsym'
> 
> What has caused the difference in this hunk? Why hasn't the script
> caught this instance? And why isn't the syntax-check triggered?
> Are the "missing" quotes the key here?

Not sure... investigating now.

> The check is named sc_prohibit_test_const_follows_var, so one
> would guess that it should prohibit "test x$foo = xbar", no? Or are
> you supposed to be able to dodge the check by needlessly adding x
> in front of LHS $variables?

Not at all.  But the long list of substitutions must be interacting
unexpectedly.  The idea is for the syntax-check rule to flag any of:

  test x"$foo" = "xbar"
  test x"$foo" = xbar
  test "x$foo" = "xbar"
  test "x$foo" = xbar
  test x$foo = xbar

where 'x' is one of '.', 'x', or 'X'.

I think we're getting much closer to a working solution though.  Many
thanks for taking the time to review.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


Re: [PATCH] tests: feed -no-undefined when linking libtool libraries

2012-09-26 Thread Gary V. Vaughan
> Hi Peter,

Ping?

> On 19 Sep 2012, at 21:50, Peter Rosin  wrote:
> 
>> On 2012-09-19 16:20, Gary V. Vaughan wrote:
>>> Hi Peter,
>>> 
>>> My bad, I'm embarrassed to say. I started to write a script to make the
>>> appropriate changes, but ended up doing it manually rather than adding
>>> more and more corner cases to the throwaway script... a poor choice in
>>> hindsight :-(
>> 
>> It's easy to be wise after the fact... If you do redo it, may I suggest
>> breaking up the patch in smaller pieces for bisectability?
> 
> I've pushed a temporary branch called gary/redo-test-operand-order to
> savannah with seven changesets that reverts the manual version of the
> buggy original and redoes it with a painstaking awk script (also checked
> in, for the morbidly curious).
> 
> I'm on the fence about committing in smaller pieces... the policy for
> libtool has always been to make sure the testsuite passes (at least
> on the committer's machine) for every changeset, so that bisecting
> using one of the test cases doesn't fail unexpectedly on another
> commit that was intentionally pushed with know failures.  On the other
> hand, the original was a monster, so I can see the benefits of splitting
> it up a bit too.
> 
> 
>>> I think it will be safer to revert the broken patch, and then
>>> write a script to reapply those changes automatically as I
>>> should have done originally, and only then to merge the result
>>> back to head. If you hold off for a few days, I'll do that as
>>> penance for my sins when I get back to my computer.
>> 
>> I'm not sure a revert of such a big patch is possible after
>> 50-odd more patches? But I was thinking revert too after
>> reading it for a while... Who knows what else hides in
>> there?
> 
> Well, I wrote and applied the script, diffed the results, and
> the testsuite has no regressions for me.  I get a weird failure
> in distcheck which tries to run distclean in _build/tests/cdemo
> aftec removing _build/tests/cdemo/Makefile, that I haven't had
> time to check against current master to see if it is a new regression
> caused by my patch.
> 
>>> But please hold on to your test case to verify that I've made
>>> a better job of things on the do over.
>> 
>> That's easy, on Cygwin:
>>make check-local TESTSUITEFLAGS="-k Runpath"
>> is supposed to PASS (not FAIL) and
>>make check-local TESTSUITEFLAGS="-k relpaths"
>> is supposed to XFAIL (not XPASS)
>> 
>> (mentioning it here so that I don't forget myself)
> 
> Cool.  When you have time, please let me know whether the temporary
> branch I made works properly for you.  I'll do some more regression
> testing, and if all goes well, I'll transplant the branch onto
> master.
> 
>> Commit v2.4.2-120-g962aa91
>> syntax-check: fix violations and implement sc_prohibit_test_const_follows_var
>> inadvertenty stomped some comparisons.
>> 
>> * build-aux/ltmain.m4sh (func_mode_compile): Reverse test when checking
>> if non-PIC is attempted in shared libraries.
>> (func_mode_link): Check for dlprefiles, not dlfiles.
>> (func_mode_link): Reverse test so that dependencies are checked when
>> pass_all is not in effect.
>> ---
>> build-aux/ltmain.m4sh |6 +++---
>> 1 files changed, 3 insertions(+), 3 deletions(-)
>> 
>> diff --git a/build-aux/ltmain.m4sh b/build-aux/ltmain.m4sh
>> index 14f3c37..0b8defa 100644
>> --- a/build-aux/ltmain.m4sh
>> +++ b/build-aux/ltmain.m4sh
>> @@ -1350,7 +1350,7 @@ func_mode_compile ()
>>  pic_mode=default
>>  ;;
>>esac
>> -if test yes = "$pic_mode" && test pass_all != "$deplibs_check_method"; 
>> then
>> +if test no = "$pic_mode" && test pass_all != "$deplibs_check_method"; 
>> then
>>  # non-PIC code in shared libraries is not supported
>>  pic_mode=default
>>fi
>> @@ -5151,7 +5151,7 @@ func_mode_link ()
>>   fi
>> 
>>   # CHECK ME:  I think I busted this.  -Ossama
>> -   if test dlfiles = "$prev"; then
>> +   if test dlprefiles = "$prev"; then
>> # Preload the old-style object.
>> func_append dlprefiles " $pic_object"
>> prev=
>> @@ -6191,7 +6191,7 @@ func_mode_link ()
>> fi
>>   elif test yes = "$build_libtool_libs"; then
>> # Not a shared library
>> - if test pass_all = "$deplibs_check_method"; then
>> + if test pass_all != "$deplibs_check_method"; then
>>   # We're trying link a shared library against a static one
>>   # but the system doesn't support it.
> 
> 
> My awk script also matches your changes in these hunks, so I'm
> moderately confident that it will have caught any other lurkers too.
> 
> If not, I will branch before 962aa91, run the script, and then apply
> the rest of master to that branch one patch at a time until I arrive
> at a diff that I can apply to master itself, rather than using revert
> as I did on the current temporary branch.
> 
> Cheers,
> -- 
> Gary V. Vaughan (gary AT gnu DOT org)
> 



Re: [PATCH] tests: feed -no-undefined when linking libtool libraries

2012-09-21 Thread Gary V. Vaughan
Hi Peter,

On 19 Sep 2012, at 21:50, Peter Rosin  wrote:

> On 2012-09-19 16:20, Gary V. Vaughan wrote:
>> Hi Peter,
>> 
>> My bad, I'm embarrassed to say. I started to write a script to make the
>> appropriate changes, but ended up doing it manually rather than adding
>> more and more corner cases to the throwaway script... a poor choice in
>> hindsight :-(
> 
> It's easy to be wise after the fact... If you do redo it, may I suggest
> breaking up the patch in smaller pieces for bisectability?

I've pushed a temporary branch called gary/redo-test-operand-order to
savannah with seven changesets that reverts the manual version of the
buggy original and redoes it with a painstaking awk script (also checked
in, for the morbidly curious).

I'm on the fence about committing in smaller pieces... the policy for
libtool has always been to make sure the testsuite passes (at least
on the committer's machine) for every changeset, so that bisecting
using one of the test cases doesn't fail unexpectedly on another
commit that was intentionally pushed with know failures.  On the other
hand, the original was a monster, so I can see the benefits of splitting
it up a bit too.


>> I think it will be safer to revert the broken patch, and then
>> write a script to reapply those changes automatically as I
>> should have done originally, and only then to merge the result
>> back to head. If you hold off for a few days, I'll do that as
>> penance for my sins when I get back to my computer.
> 
> I'm not sure a revert of such a big patch is possible after
> 50-odd more patches? But I was thinking revert too after
> reading it for a while... Who knows what else hides in
> there?

Well, I wrote and applied the script, diffed the results, and
the testsuite has no regressions for me.  I get a weird failure
in distcheck which tries to run distclean in _build/tests/cdemo
aftec removing _build/tests/cdemo/Makefile, that I haven't had
time to check against current master to see if it is a new regression
caused by my patch.

>> But please hold on to your test case to verify that I've made
>> a better job of things on the do over.
> 
> That's easy, on Cygwin:
>   make check-local TESTSUITEFLAGS="-k Runpath"
> is supposed to PASS (not FAIL) and
>   make check-local TESTSUITEFLAGS="-k relpaths"
> is supposed to XFAIL (not XPASS)
> 
> (mentioning it here so that I don't forget myself)

Cool.  When you have time, please let me know whether the temporary
branch I made works properly for you.  I'll do some more regression
testing, and if all goes well, I'll transplant the branch onto
master.

> Commit v2.4.2-120-g962aa91
> syntax-check: fix violations and implement sc_prohibit_test_const_follows_var
> inadvertenty stomped some comparisons.
> 
> * build-aux/ltmain.m4sh (func_mode_compile): Reverse test when checking
> if non-PIC is attempted in shared libraries.
> (func_mode_link): Check for dlprefiles, not dlfiles.
> (func_mode_link): Reverse test so that dependencies are checked when
> pass_all is not in effect.
> ---
> build-aux/ltmain.m4sh |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/build-aux/ltmain.m4sh b/build-aux/ltmain.m4sh
> index 14f3c37..0b8defa 100644
> --- a/build-aux/ltmain.m4sh
> +++ b/build-aux/ltmain.m4sh
> @@ -1350,7 +1350,7 @@ func_mode_compile ()
>   pic_mode=default
>   ;;
> esac
> -if test yes = "$pic_mode" && test pass_all != "$deplibs_check_method"; 
> then
> +if test no = "$pic_mode" && test pass_all != "$deplibs_check_method"; 
> then
>   # non-PIC code in shared libraries is not supported
>   pic_mode=default
> fi
> @@ -5151,7 +5151,7 @@ func_mode_link ()
>fi
> 
># CHECK ME:  I think I busted this.  -Ossama
> -   if test dlfiles = "$prev"; then
> +   if test dlprefiles = "$prev"; then
>  # Preload the old-style object.
>  func_append dlprefiles " $pic_object"
>  prev=
> @@ -6191,7 +6191,7 @@ func_mode_link ()
>  fi
>elif test yes = "$build_libtool_libs"; then
>  # Not a shared library
> - if test pass_all = "$deplibs_check_method"; then
> + if test pass_all != "$deplibs_check_method"; then
># We're trying link a shared library against a static one
># but the system doesn't support it.


My awk script also matches your changes in these hunks, so I'm
moderately confident that it will have caught any other lurkers too.

If not, I will branch before 962aa91, run the script, and then apply
the rest of master to that branch one patch at a time until I arrive
at a diff that I can apply to master itself, rather than using revert
as I did on the current temporary branch.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)




Re: [PATCH] tests: feed -no-undefined when linking libtool libraries

2012-09-19 Thread Gary V. Vaughan
Hi Peter,

My bad, I'm embarrassed to say. I started to write a script to make the 
appropriate changes, but ended up doing it manually rather than adding more and 
more corner cases to the throwaway script... a poor choice in hindsight :-(

On 19 ก.ย. 2012, at 19:27, Peter Rosin  wrote:
> On 2012-09-19 11:26, Peter Rosin wrote:
>> On 2012-09-19 09:31, Peter Rosin wrote:
>>> * tests/runpath-in-lalib.at: Make sure shared libraries are created
>>> on Windows by passing -no-undefined. Otherwise libb.la fails to record
>>> a dependency on liba.la, and the final link of the program then fails
>>> with undefined symbols.
>>> 
>>> Signed-off-by: Peter Rosin 
>>> ---
>>> tests/runpath-in-lalib.at |1 +
>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>> 
>>> Ok to push?
>>> Or maybe the failure is deeper than this? Should libb.la record a
>>> dependency on liba.la even if libb.la is static only?
>> 
>> I likely is deeper, it seems this is a regression since 2.4.2.
> 
> I have bisected this regression to 962aa919f51cdf8e2cee4fb2d1d9bafa34d50887
> syntax-check: fix violations and implement sc_prohibit_test_const_follows_var.
> 
> I looked through that insanely huge patch and it was not fun. I did
> manage to find a couple of problems:
> 
> -if test "$pic_mode" = no && test "$deplibs_check_method" != pass_all; 
> then
> +if test yes = "$pic_mode" && test pass_all != "$deplibs_check_method"; 
> then
> 
> -if test "$prev" = dlprefiles; then
> +if test dlfiles = "$prev"; then
> 
> -if test "x`$SED 1q $export_symbols`" != xEXPORTS; then
> +if test EXPORTS = "`$SED 1q $export_symbols`"; then
> 
> -if test "x[$]$2" = xyes; then
> +if test yes != "[$]$2"; then
> 
> However, my eyes must have glazed over because it is not enough to fix those
> bugs.

I guess my whole brain glazed over while I was checking and rechecking before 
pushing, so I'm not surprised.

> Comparing to master, I notice that:
> 
> * The export_symbols change has a fixup in
> b804ffabee2ce373d9bac6ae2b235ec68e0b55e8
> fixup: restore EXPORTS test
> * The "x[$]$2" change has a fixup in
> 11869b9c9eb8bcc8cb6a615141f522a447377324
> m4: fix logic error leading to -fno-rtti being added wrongly.
> 
> I have removed a long rant on my opinion of the offending patch, it
> would do no good anyway...

Thanks for finding it, and sparing me from the additional shame.

> Bottom line: More eyes needed on that patch!
> 
> Ok to push the below?

I think it will be safer to revert the broken patch, and then write a script to 
reapply those changes automatically as I should have done originally, and only 
then to merge the result back to head. If you hold off for a few days, I'll do 
that as penance for my sins when I get back to my computer.

But please hold on to your test case to verify that I've made a better job of 
things on the do over.

> Cheers,
> Peter

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


Re: [PATCH] tests: skip with-pic test when no "real" pic flag is used.

2012-09-19 Thread Gary V. Vaughan
Hi Peter,

On 19 ก.ย. 2012, at 15:56, Peter Rosin  wrote:

> * tests/with-pic.at: Windows uses "-DDLL_EXPORT -DPIC" as the pic
> "flag", but never applies it to static libraries. Cater for this
> and skip if no "real" pic flag is in use.
> [[...]]
> 
> Ok to push?

Yes, with nit below addressed. Thanks!

> I tried to eliminate the loop using variants of this:
> 
> real_pic=false
> case " $pic_flag " in
> *" "[^-]* | *" "-[^D]*) real_pic=: ;;
> esac
> AT_CHECK([$real_pic || exit 77])
> 
> ...but I never got that to work in the test. It worked in an
> interactive bash though. Strange.

M4 will strip one level of square brackets as it generates the testsuite 
script. Normally we just put an extra level of quoting around regexps/globs to 
account for that:

 [*" "[^-]* | *" "-[^D]*]) real_pic=: ;; 

(untested -- still on vacation ;-)

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


FYI: [PATCH] gnulib: update gnulib submodule.

2011-12-23 Thread Gary V. Vaughan
Belay that, on my final pre-push `./bootstrap&&./configure&&make all check`
it turns out that upstream README-release changed a colon into a period,
so our local gnulib-tool patch needed updating accordingly.  This is the
version of the patch I'm pushing.

Among others, this fixes the reference to a local commit.
* gnulib: Updated to todays master HEAD revision.
* gl/top/README-release.diff: Update to account for changes to
gnulib/top/README-release since the last gnulib update.

Signed-off-by: Gary V. Vaughan 
---
 gl/top/README-release.diff |8 
 gnulib |2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/gl/top/README-release.diff b/gl/top/README-release.diff
index 9f89724..4cc43f3 100644
--- a/gl/top/README-release.diff
+++ b/gl/top/README-release.diff
@@ -1,5 +1,5 @@
 gnulib/top/README-release  2011-10-23 14:32:58.0 +0700
-+++ gl/top/README-release  2011-10-23 14:38:40.0 +0700
+--- gnulib/top/README-release  2011-12-24 08:28:59.0 +0700
 gl/top/README-release  2011-12-24 09:01:01.0 +0700
 @@ -1,5 +1,9 @@
  Here are most of the steps we (maintainers) follow when making a release.
  
@@ -10,11 +10,11 @@
  * start from a clean, up-to-date git directory.
  
  make -k maintainer-clean || { ./configure && make maintainer-clean; }
-@@ -18,12 +24,24 @@
+@@ -18,12 +22,24 @@
  
  http://hydra.nixos.org/jobset/gnu/@PACKAGE@-master
  
--* Run "./bootstrap && ./configure".  This downloads any new translations:
+-* Run "./bootstrap && ./configure".  This downloads any new translations.
 +* Double check that serial number updates in public m4 files weren't
 +  forgotten since last release (they should be updated in git along with
 +  commits that require it so that users can work with git snapshots).
diff --git a/gnulib b/gnulib
index f51babf..576e46c 16
--- a/gnulib
+++ b/gnulib
@@ -1 +1 @@
-Subproject commit f51babfaf400eb509f854cad509f5e649b9182b1
+Subproject commit 576e46cb89ee781ec9f8352723b5dc96d3c7fd1f
-- 
1.7.8

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



FYI: [PATCH] bootstrap: fix Autoconf version typo.

2011-12-23 Thread Gary V. Vaughan
Pushed as obvious.

I must have forgotten to rerun `git add build-aux/options-parser` in
my local tree between fixing this very short-lived typo and pushing
the patch that came after it.  Sorry about that.

* build-aux/options-parses: s/2\.62/2.68/

Signed-off-by: Gary V. Vaughan 
---
 build-aux/options-parser |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/build-aux/options-parser b/build-aux/options-parser
index 07a9731..9d42418 100644
--- a/build-aux/options-parser
+++ b/build-aux/options-parser
@@ -176,7 +176,7 @@ nl='
 # There are still modern systems that have problems with `echo' mis-
 # handling backslashes, among others, so make sure $bs_echo is set to a
 # command that correctly interprets backslashes.
-# (this code from Autoconf 2.62)
+# (this code from Autoconf 2.68)
 
 # Printing a long string crashes Solaris 7 /usr/bin/printf.
 
bs_echo='\\\'
-- 
1.7.8

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



FYI: [PATCH] gnulib: update gnulib submodule.

2011-12-23 Thread Gary V. Vaughan
Pushed as obvious.

I have no idea how I ended up with a gnulib subproject that
looks for all the world like f51babfaf is a public commit, but
which at least 2 other folks cannot see, so updating to the
latest master.

Among others, this fixes the reference to a local commit.
* gnulib: Updated to todays master HEAD revision.

Signed-off-by: Gary V. Vaughan 
---
 gnulib |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/gnulib b/gnulib
index f51babf..576e46c 16
--- a/gnulib
+++ b/gnulib
@@ -1 +1 @@
-Subproject commit f51babfaf400eb509f854cad509f5e649b9182b1
+Subproject commit 576e46cb89ee781ec9f8352723b5dc96d3c7fd1f
-- 
1.7.8

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



Re: FYI: [PATCH] bootstrap: adopt autoconf echo normalization code.

2011-12-23 Thread Gary V. Vaughan
Hi Eric,

On 19 Dec 2011, at 20:48, Eric Blake wrote:
> On 12/18/2011 12:46 AM, Gary V. Vaughan wrote:
>> Pushed as obvious.
>> 
>> Dash shipped with Ubutu-11.10 as /bin/sh, among others, still
>> has a crippled echo builtin that mis-handles backslashes.
> 
> That's an unfair characterization.  Rather, dash ships an echo builtin
> that complies with POSIX by default (which mandates backslash
> interpretation), while bash ships an echo builtin that ignores backslash
> by default, but can be made to comply with POSIX via 'shopt -s xpg_echo'.

I wasn't aware of the POSIX distinction, although while dash my be strictly
correct, it does mean that POSIX compliant echo is essentially useless for
bootstrap (and autoconf, and libtool etc etc)... entailing an ugly blob of
code to detect and circumvent any echo implementation that behaves that way.

>> +++ b/build-aux/options-parser
>> @@ -173,6 +173,46 @@ basename='s|^.*/||'
>> nl='
>> '
>> 
>> +# There are still modern systems that have problems with `echo' mis-
>> +# handling backslashes, among others, so make sure $bs_echo is set to a
>> +# command that correctly interprets backslashes.
> 
> Again, a mis-characterization of the problem.

No offense implied or intended by that comment, and I'll be happy to apply
a followup patch if you submit something preferable.

>> +# (this code from Autoconf 2.68)
>> +
>> +# Printing a long string crashes Solaris 7 /usr/bin/printf.
>> +bs_echo='\\\'
>> +bs_echo=$bs_echo$bs_echo$bs_echo$bs_echo$bs_echo
>> +bs_echo=$bs_echo$bs_echo$bs_echo$bs_echo$bs_echo$bs_echo
>> +# Prefer a ksh shell builtin over an external printf program on Solaris,
>> +# but without wasting forks for bash or zsh.
>> +if test -z "$BASH_VERSION$ZSH_VERSION" \
>> +&& (test "X`print -r -- $bs_echo`" = "X$bs_echo") 2>/dev/null; then
>> +  bs_echo='print -r --'
>> +  bs_echo_n='print -rn --'
> 
> Also, I'm not sure that I like the name $bs_echo - it's not namespace
> clean.  I would have expected something more like $lt_echo.

lt_ is the libtool namespace, and options-parser is a module of bootstrap,
so I used bs_.

After the initial encouragement on the gnulib list, I wrote bootstrap for
gnulib, but it looks like it won't ever make it upstream in its previous
form, so I split it into a reusable options-parser script that provides the
hooks and requires framework and uses it to implement a pluggable shell
script options parser that can be extended by writing a few functions...
and then on top of that my much improved extract-trace script which is a
standalone proof of concept that m4 can be used more easily and profitably
for parsing configure.{ac,in} than ad-hoc sed scripts, and finally with the
saner bootstrap implemented on top of both of those.

When I next have some time to hand-hold the process, I'll make another attempt
at getting gnulib to accept this version of bootstrap, which I hope will prove
a bit easier with the separation into smaller chunks, each useful in its own
right, and then try and get autoreconf and others to adopt the extract-trace
script and/or approach over brittle ad-hoc sed scripts.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


FYI: [PATCH] libtool: make fork minimisation compatible with dash and zsh.

2011-12-18 Thread Gary V. Vaughan
* build-aub/general.m4sh (lt_HAVE_PLUSEQ_OP): Instead of using
$((..)) arithmetic, which causes an error on dash, use a case
based bash version check.
(lt_HAVE_ARITH_OP, lt_HAVE_XSI_OPS): Also short circuit the
feature probing forks and set these automatically when zsh is
detected.
Reported by Stefano Lattarini.

Signed-off-by: Gary V. Vaughan 
---
 build-aux/general.m4sh |   12 +++-
 1 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/build-aux/general.m4sh b/build-aux/general.m4sh
index e96c0e4..3cfecee 100644
--- a/build-aux/general.m4sh
+++ b/build-aux/general.m4sh
@@ -75,14 +75,16 @@ basename='s|^.*/||'
 
 
 # We should try to minimise forks, especially on Windows where they are
-# unreasonably slow, so skip the feature probes when bash is being used:
-if test set = "${BASH_VERSION+set}"; then
+# unreasonably slow, so skip the feature probes when bash or zsh are
+# being used:
+if test set = "${BASH_VERSION+set}${ZSH_VERSION}"; then
 : ${lt_HAVE_ARITH_OP="yes"}
 : ${lt_HAVE_XSI_OPS="yes"}
 # The += operator was introduced in bash 3.1
-test -z "$lt_HAVE_PLUSEQ_OP" \
-  && test 3000 -lt "$((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]}))" \
-  && lt_HAVE_PLUSEQ_OP=yes
+case $BASH_VERSION in
+  [12].* | 3.0 | 3.0.*) ;;
+  *)        lt_HAVE_PLUSEQ_OP=yes ;;
+esac
 fi
 
 
-- 
1.7.8

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



Re: FYI [PATCH] libtool: minimise forks per invocation under bash.

2011-12-18 Thread Gary V. Vaughan
Hi Stefano,

On 18 Dec 2011, at 17:19, Stefano Lattarini wrote:
> On 12/18/2011 11:07 AM, Gary V. Vaughan wrote:
>> On 18 Dec 2011, at 17:02, Stefano Lattarini wrote:
>>> On 12/18/2011 10:52 AM, Stefano Lattarini wrote:
>>>> On 12/18/2011 06:15 AM, Gary V. Vaughan wrote:
>>>>> +# We should try to minimise forks, especially on Windows where they are
>>>>> +# unreasonably slow, so skip the feature probes when bash is being used:
>>>>> +if test set = "${BASH_VERSION+set}"; then
>>>>> +: ${lt_HAVE_ARITH_OP="yes"}
>>>>> +: ${lt_HAVE_XSI_OPS="yes"}
>>>>> +# The += operator was introduced in bash 3.1
>>>>> +test -z "$lt_HAVE_PLUSEQ_OP" \
>>>>> +&&   test 3000 -lt "$((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]}))" 
>>>>> \
>>>>> +&&   lt_HAVE_PLUSEQ_OP=yes
>>>>> +fi
>>>> This will likely break with dash 0.5.2:
>>>> 
>>>>  $ cat foo.sh
>>>>  #!/bin/sh
>>>>  if test set = "${BASH_VERSION+set}"; then
>>>>: ${lt_HAVE_ARITH_OP="yes"}
>>>>: ${lt_HAVE_XSI_OPS="yes"}
>>>># The += operator was introduced in bash 3.1
>>>>test -z "$lt_HAVE_PLUSEQ_OP" \
>>>> &&  test 3000 -lt "$((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]}))" \
>>>> &&  lt_HAVE_PLUSEQ_OP=yes
>>>>  fi
>>>>  $ dash foo.sh
>>>>  foo.sh: 7: Syntax error: Bad substitution
>>> Update: the same happens with NetBSD 5.1 /bin/sh (which is probably
>>> an ash-derivative).
>> Thanks for the report.
>> 
>> Unfortunately, I'm out of ideas on how to portably detect the bash version 
>> without
>> spending a fork, in which case it seems easiest to spend that fork actually 
>> testing
>> for += support rather than poking at the bash version.
>> 
>> Can anyone think of something better than just removing the whole 
>> lt_HAVE_PLUSEQ_OP
>> clause from the patch quoted above, and letting the shell figure it by 
>> itself later
>> on?
> Adding an extra eval seems to do the trick:
> 
>  eval 'test 3000 -lt "$((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]}))"'
> 
> Of course, a comment about why this eval is needed would be definitely
> warranted.

Not that I've looked at the implementation, but isn't eval as bad as a fork on
Windows? (which is the only reason to avoid forks, since they are extremely 
cheap on
Unix.)

> Or, to be even safer, you could directly poke at $BASH_VERSION instead:
> 
>  case $BASH_VERSION in
>[12].*|3.0.*) ;;
>*) lt_HAVE_PLUSEQ_OP=yes;;
>  esac

Ah, true... I guess I was too focussed on a straight forward one liner, and 
missed
the obvious one.  D'oh!  I'll switch to that and push presently.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


Re: FYI [PATCH] libtool: minimise forks per invocation under bash.

2011-12-18 Thread Gary V. Vaughan
Hi Stefano,

On 18 Dec 2011, at 17:02, Stefano Lattarini wrote:

> On 12/18/2011 10:52 AM, Stefano Lattarini wrote:
>> On 12/18/2011 06:15 AM, Gary V. Vaughan wrote:
>>> +# We should try to minimise forks, especially on Windows where they are
>>> +# unreasonably slow, so skip the feature probes when bash is being used:
>>> +if test set = "${BASH_VERSION+set}"; then
>>> +: ${lt_HAVE_ARITH_OP="yes"}
>>> +: ${lt_HAVE_XSI_OPS="yes"}
>>> +# The += operator was introduced in bash 3.1
>>> +test -z "$lt_HAVE_PLUSEQ_OP" \
>>> +&&  test 3000 -lt "$((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]}))" \
>>> +&&  lt_HAVE_PLUSEQ_OP=yes
>>> +fi
>> This will likely break with dash 0.5.2:
>> 
>>  $ cat foo.sh
>>  #!/bin/sh
>>  if test set = "${BASH_VERSION+set}"; then
>>: ${lt_HAVE_ARITH_OP="yes"}
>>: ${lt_HAVE_XSI_OPS="yes"}
>># The += operator was introduced in bash 3.1
>>test -z "$lt_HAVE_PLUSEQ_OP" \
>> && test 3000 -lt "$((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]}))" \
>> && lt_HAVE_PLUSEQ_OP=yes
>>  fi
>>  $ dash foo.sh
>>  foo.sh: 7: Syntax error: Bad substitution
>> 
> Update: the same happens with NetBSD 5.1 /bin/sh (which is probably
> an ash-derivative).

Thanks for the report.

Unfortunately, I'm out of ideas on how to portably detect the bash version 
without
spending a fork, in which case it seems easiest to spend that fork actually 
testing
for += support rather than poking at the bash version.

Can anyone think of something better than just removing the whole 
lt_HAVE_PLUSEQ_OP
clause from the patch quoted above, and letting the shell figure it by itself 
later
on?

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


FYI: [PATCH] bootstrap: adopt autoconf echo normalization code.

2011-12-17 Thread Gary V. Vaughan
Pushed as obvious.

Dash shipped with Ubutu-11.10 as /bin/sh, among others, still
has a crippled echo builtin that mis-handles backslashes.
* build-aux/options-parser (bs_echo): Adopt the autoconf echo
normalization code to find a suitable replacement for buggy echo
commands.
Adjust all uses of echo to $bs_echo.
* build-aux/extract-trace (func_extract_trace, func_main):
Likewise.
* bootstrap: To retain some execution speed on platforms with
buggy builtin echo, replace most occurrences of `echo' with
`$bs_echo' - except where its arguments will obviously never
contain backslashes or be overly long.
Reported by Reuben Thomas.

Signed-off-by: Gary V. Vaughan 
---
 bootstrap|   20 +++---
 build-aux/extract-trace  |8 +++---
 build-aux/options-parser |   60 ++---
 3 files changed, 64 insertions(+), 24 deletions(-)

diff --git a/bootstrap b/bootstrap
index 147ac08..7b26d00 100755
--- a/bootstrap
+++ b/bootstrap
@@ -1051,7 +1051,7 @@ func_require_buildreq_automake ()
 
   # ...and AM_INIT_AUTOMAKE is declared...
   test -n "$func_extract_trace_result" && {
-automake_version=`echo "$func_extract_trace_result" \
+automake_version=`$bs_echo "$func_extract_trace_result" \
|$SED 's|[^0-9]*||; s| .*$||'`
 test -n "$automake_version" || automake_version=-
 
@@ -1798,8 +1798,8 @@ func_ifcontains ()
 {
 $debug_cmd
 
-# The embedded echo is to squase whitespace before globbing.
-_G_wslist=`echo " "$1" "`
+# The embedded echo is to squash whitespace before globbing.
+_G_wslist=`$bs_echo " "$1" "`
 _G_member=$2
 _G_yes_cmd=$3
 _G_no_cmd=${4-":"}
@@ -1833,7 +1833,7 @@ func_append_u ()
 {
 $debug_cmd
 
-eval _G_current_value='`echo $'$1'`'
+eval _G_current_value='`$bs_echo $'$1'`'
 _G_delim=`expr "$2" : '\(.\)'`
 
 case $_G_delim$_G_current_value$_G_delim in
@@ -1851,7 +1851,7 @@ func_strpad ()
 $debug_cmd
 
 _G_width=`expr "$2" - 1`
-func_strpad_result=`echo "$1" |$SED '
+func_strpad_result=`$bs_echo "$1" |$SED '
 :a
 s|^.\{0,'"$_G_width"'\}$|&'"$3"'|
 ta
@@ -1868,7 +1868,7 @@ func_strrpad ()
 $debug_cmd
 
 _G_width=`expr "$2" - 1`
-func_strrpad_result=`echo "$1" |$SED '
+func_strrpad_result=`$bs_echo "$1" |$SED '
 :a
 s|^.\{0,'"$_G_width"'\}$|'"$3"'&|
 ta
@@ -1953,7 +1953,7 @@ func_strtable ()
 
 # Strip off the indent, and make a divider with `-' chars, then
 # reindent.
-_G_divider=`echo "$func_strrow_result" \
+_G_divider=`$bs_echo "$func_strrow_result" \
 |$SED 's|[^ ]|-|g
 :a
 s|- |--|g
@@ -2111,8 +2111,8 @@ func_insert_sorted_if_absent ()
   func_grep_q "$str" "$file" \
   && func_verbose "inserting \`$str' into \`$file'"
 
-  echo "$str" |sort -u - "$file" |func_cmp_s - "$file" \
-|| echo "$str" |sort -u - "$file" -o "$file" \
+  $bs_echo "$str" |sort -u - "$file" |func_cmp_s - "$file" \
+|| $bs_echo "$str" |sort -u - "$file" -o "$file" \
 || func_permissions_error "$file"
 done
 }
@@ -2177,7 +2177,7 @@ func_get_version ()
 
 # Rather than uncomment the sed script in-situ, strip the comments
 # programatically before passing the result to $SED for evaluation.
-sed_get_version=`echo '# extract version within line
+sed_get_version=`$bs_echo '# extract version within line
   s|.*[v ]\{1,\}\([0-9]\{1,\}\.[.a-z0-9-]*\).*|\1|
   t done
 
diff --git a/build-aux/extract-trace b/build-aux/extract-trace
index b738257..ee3f284 100755
--- a/build-aux/extract-trace
+++ b/build-aux/extract-trace
@@ -254,8 +254,8 @@ func_extract_trace ()
 $require_configure_ac
 $require_gnu_m4
 
-_G_m4_traces=`echo "--trace=$1" |$SED 's%,% --trace=%g'`
-_G_re_macros=`echo "($1)" |$SED 's%,%|%g'`
+_G_m4_traces=`$bs_echo "--trace=$1" |$SED 's%,% --trace=%g'`
+_G_re_macros=`$bs_echo "($1)" |$SED 's%,%|%g'`
 _G_macros="$1"; shift
 test $# -gt 0 || {
   set dummy $configure_ac
@@ -357,7 +357,7 @@ func_extract_trace ()
 
 # Save the command pipeline results for further use by callers of
 # this function.
-func_extract_trace_result=`echo "$_G_mini" \
+func_extract_trace_result=`$bs_ec

FYI [PATCH] libtool: minimise forks per invocation under bash.

2011-12-17 Thread Gary V. Vaughan
Thanks to Eric Blake, Peter O'Gorman and Bob Friesenhahn for steering
me in this direction.

* build-aux/general.m4sh (lt_HAVE_PLUSEQ_OP, lt_HAVE_ARITH_OP)
(lt_HAVE_XSI_OPS): Set these without forking a test script when
running under bash, to avoid a few unnecessary forks.

Signed-off-by: Gary V. Vaughan 
---
 build-aux/general.m4sh |   21 -
 1 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/build-aux/general.m4sh b/build-aux/general.m4sh
index 252b2d2..e96c0e4 100644
--- a/build-aux/general.m4sh
+++ b/build-aux/general.m4sh
@@ -74,12 +74,21 @@ dirname='s|/[^/]*$||'
 basename='s|^.*/||'
 
 
+# We should try to minimise forks, especially on Windows where they are
+# unreasonably slow, so skip the feature probes when bash is being used:
+if test set = "${BASH_VERSION+set}"; then
+: ${lt_HAVE_ARITH_OP="yes"}
+: ${lt_HAVE_XSI_OPS="yes"}
+# The += operator was introduced in bash 3.1
+test -z "$lt_HAVE_PLUSEQ_OP" \
+  && test 3000 -lt "$((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]}))" \
+  && lt_HAVE_PLUSEQ_OP=yes
+fi
+
+
 # lt_HAVE_PLUSEQ_OP
 # Can be empty, in which case the shell is probed, "yes" if += is useable
 # or anything else if += does not work.
-# NOTE: You can short-circuit the fork and test on every invocation (e.g.
-# on Windows where fork emulations are unreasonably slow) by setting this
-# in the environment of this script.
 test -z "$lt_HAVE_PLUSEQ_OP" \
 && (eval 'x=a; x+=" b"; test "a b" = "$x"') 2>/dev/null \
 && lt_HAVE_PLUSEQ_OP=yes
@@ -117,9 +126,6 @@ fi
 # lt_HAVE_ARITH_OP
 # Can be empty, in which case the shell is probed, "yes" if $((...)) is
 # useable or anything else if it does not work.
-# NOTE: You can short-circuit the fork and test on every invocation (e.g.
-# on Windows where fork emulations are unreasonably slow) by setting this
-# in the environment of this script.
 test -z "$lt_HAVE_ARITH_OP" \
 && (eval 'test 2 = $(( 1 + 1 ))') 2>/dev/null \
 && lt_HAVE_ARITH_OP=yes
@@ -141,9 +147,6 @@ fi
 # lt_HAVE_XSI_OPS
 # Can be empty, in which case the shell is probed, "yes" if XSI length
 # and matching operators are useable or anything else if they do not work.
-# NOTE: You can short-circuit the fork and test on every invocation (e.g.
-# on Windows where fork emulations are unreasonably slow) by setting this
-# in the environment of this script.
 test -z "$lt_HAVE_XSI_OPS" \
 && (eval 'x=a/b/c;
   test 5aa/bb/cc = "${#x}${x%%/*}${x%/*}${x#*/}${x##*/}"') 2>/dev/null \
-- 
1.7.8

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



[PATCH 1/2] maint: disable prohibit_always-defined_macros syntax check.

2011-12-08 Thread Gary V. Vaughan
Applied as obvious.

Aside from Apple grep silently failing to run this test and
report violations, libtool still uses non-gnulib versions of
dirent.h and argz.h which use the same macros, but are not
always-defined.
* cfg.mk (local-checks-to-fix): Move
sc_prohibit_always-defined_macros from here...
(local-checks-to-skip): ...to here.
Reported by Peter O'Gorman.

Signed-off-by: Gary V. Vaughan 
---
 cfg.mk |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/cfg.mk b/cfg.mk
index dc89660..ef1637a 100644
--- a/cfg.mk
+++ b/cfg.mk
@@ -38,7 +38,6 @@ endif
 VC_LIST_ALWAYS_EXCLUDE_REGEX = ^mail/
 
 local-checks-to-fix =  \
-   sc_prohibit_always-defined_macros   \
sc_require_config_h \
sc_require_config_h_first
 
@@ -46,12 +45,16 @@ local-checks-to-skip =  \
$(local-checks-to-fix)  \
sc_GPL_version  \
sc_cast_of_x_alloc_return_value \
+   sc_prohibit_always-defined_macros   \
sc_trailing_blank   \
sc_unmarked_diagnostics
 
 # GPL_version: checks for GPLv3, which we don't use
 # cast_of_x_alloc_return_value:
 # We support C++ compilation which does require casting here.
+# prohibit_always-defined_macros:
+#  we have our own argz and dirent, which use the same macros but
+#  which are not always-defined in our case.
 # trailing_blank: flags valid rfc3676 separators
 # unmarked_diagnostics: libtool isn't internationalized
 
-- 
1.7.8

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.

2011-12-08 Thread Gary V. Vaughan
Hi Eric,

On 8 Dec 2011, at 19:56, Eric Blake wrote:
> On 12/08/2011 03:21 AM, Gary V. Vaughan wrote:
>> The recently pushed series of patches included the controversial
>> introduction of an additional 3 forks per invocation, which might
>> add a minute or two of wall-clock time to giant builds on windows.
>> By assuming that windows will run shell scripts on some shell with
>> all the modern optional features that libtool wants, this patch
>> eliminates even those 3 new forks.
>> 
>> Okay to push?
> 
> I'm a bit reluctant to do this via a host check;
> 
>> 
>> +# Forks are unreasonably slow under Windows, so we assume that, for at
>> +# least cygwin and mingw, /bin/sh is bash, and save at least 3 forks per
>> +# invocation:
>> +case $host in
>> +  *cygwin* | *mingw*)
> 
> Instead of doing it this way, I'd almost rather see:
> 
> if test "${BASH_VERSION+set}" = set; then

Face palm!  Absolutely, that is far more sensible.  Assuming we decide
to push this patch, I'll do it that way and ditch the host check.  Thanks!

> although if cygwin ever follows debian's lead of using dash for faster
> /bin/sh, I'm not sure if there is a reliable forkless way to detect dash.

I think we can worry about that later, if it ever happens.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.

2011-12-08 Thread Gary V. Vaughan
Hi Peter,

On 8 Dec 2011, at 20:40, Peter O'Gorman wrote:
> On 12/08/2011 04:21 AM, Gary V. Vaughan wrote:
>> The recently pushed series of patches included the controversial
>> introduction of an additional 3 forks per invocation, which might
>> add a minute or two of wall-clock time to giant builds on windows.
>> By assuming that windows will run shell scripts on some shell with
>> all the modern optional features that libtool wants, this patch
>> eliminates even those 3 new forks.
>> 
>> Okay to push?
> 
> The whole reason these checks were done in configure and not in libtool was 
> to avoid these forks, and the slow down involved. We did a lot of work at 
> speeding up libtool so that non-portable tools such as dolt would not be 
> necessary, including moving large chunks of compile mode script closer the 
> the top of libtool so that it would execute faster.

Ack.  However since I wrote all the hairy M4 code to do the configure time 
replacements, I've changed my mind about how well they work in the grand scheme 
of things... The usual mode of integrating libtool is to have your project's 
configure build a libtool script, which you then call as a compiler wrapper.  
With the exception of projects with a huge number of tiny files to compile, I 
seriously doubt that 3 additional forks per invocation would be noticable as it 
stands now, and after looking back through the replacement code I recently 
expunged, we probably save a few hundred forks from sed and perl invocations at 
configure time, which would mean you don't get any slow down overall in a 
'./configure; make; make install' sequence until you've invoked the libtool 
script at least several dozen times.

Also, I'm trying hard to make hacking on libtool much less infuriating to 
attract more outside patches and development.  Having configure switch out 
function definitions is an odd thing to do, and libtool is already hard enough 
to understand without having to worry about having configure rewriting some of 
libtools functions... hopefully it doesn't make any mistakes ;)

> Any additional forks will slow down the script and should be avoided on all 
> platforms.

Agreed.  And using a BASH_VERSION test will get us a good way there.  I'll also 
work on a follow up patch to set the new lt_HAVE_XSI_OPS and friends using the 
existing machinery for injecting configure time variables into libtool, so I 
can also throw out the last couple of M4 replacement macros.

> Simply removing $(SHELL) from the LIBTOOL variable should fix the bug that 
> this is attempting to fix, without slowing down libtool.

But then we go back to having bug reports about libtool not getting an execute 
bit.  I'm not in favour of making that change.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


FYI: [PATCH] tests: s/snippit/snippet/.

2011-12-08 Thread Gary V. Vaughan
Applied as obvious.

* tests/demo/foo.h, tests/pdemo/foo.h: Spell `snippet' correctly.
Reported by Stefano Lattarini.

Signed-off-by: Gary V. Vaughan 
---
 tests/demo/foo.h  |2 +-
 tests/pdemo/foo.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/demo/foo.h b/tests/demo/foo.h
index 5609d8d..9ee7f2e 100644
--- a/tests/demo/foo.h
+++ b/tests/demo/foo.h
@@ -27,7 +27,7 @@ or obtained by writing to the Free Software Foundation, Inc.,
 #define _FOO_H_ 1
 
 /* At some point, cygwin will stop defining __CYGWIN32__, but b19 and
- * earlier do not define __CYGWIN__.  This snippit allows us to check
+ * earlier do not define __CYGWIN__.  This snippet allows us to check
  * for __CYGWIN__ reliably for both current, old, and (probable) future
  * releases.
  */
diff --git a/tests/pdemo/foo.h b/tests/pdemo/foo.h
index 2f666f3..1843783 100644
--- a/tests/pdemo/foo.h
+++ b/tests/pdemo/foo.h
@@ -27,7 +27,7 @@ or obtained by writing to the Free Software Foundation, Inc.,
 #define _FOO_H_ 1
 
 /* At some point, cygwin will stop defining __CYGWIN32__, but b19 and
- * earlier do not define __CYGWIN__.  This snippit allows us to check
+ * earlier do not define __CYGWIN__.  This snippet allows us to check
  * for __CYGWIN32__ reliably for both old and (probable) future releases.
  */
 #ifdef __CYGWIN__
-- 
1.7.8

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



FYI: [PATCH] tests: make sure file restore traps are called correctly on AIX.

2011-12-08 Thread Gary V. Vaughan
Applied as obvious.

* tests/demo-noinst-link.test (func_save_files): set the restore
trap outside a function, otherwise AIX 5.3 /bin/sh will run the
trap at the end of the function, instead of when the script
exits.
* tests/demo-relink.test (func_save_files): Ditto.
* tests/depdemo-relink.test (func_save_files): Ditto.
Reported by Stefano Lattarini.

Signed-off-by: Gary V. Vaughan 
---
 tests/demo-noinst-link.test |5 -
 tests/demo-relink.test  |4 +++-
 tests/depdemo-relink.test   |4 +++-
 3 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/tests/demo-noinst-link.test b/tests/demo-noinst-link.test
index 5e658b0..5654ff9 100755
--- a/tests/demo-noinst-link.test
+++ b/tests/demo-noinst-link.test
@@ -38,13 +38,16 @@ func_save_files ()
 func_mkdir_p "$objdir/temp/libs"
 cp -f libhello.la "hell$EXEEXT" "$objdir/temp"
 cp -f "$objdir"/* "$objdir"/temp/libs
-trap "func_restore_files" 0 1 2 13 15
 }
 
 func_require "demo-inst" "$prefix/lib/libhello.la"
 
 func_mkprefixdir
 func_cd "tests/demo"
+
+# AIX 5.3 `/bin/sh' will invoke the trap for 0 at the end of a
+# function, so we set the trap outside of a function to be portable.
+trap func_restore_files 0 1 2 13 15
 func_save_files
 
 func_msg "removing \`libhello.la' and \`hell' from demo"
diff --git a/tests/demo-relink.test b/tests/demo-relink.test
index b463441..4b32fba 100755
--- a/tests/demo-relink.test
+++ b/tests/demo-relink.test
@@ -37,7 +37,6 @@ func_save_files ()
 func_mkdir_p "$objdir/temp/libs"
 cp -f libhello.la "$objdir/temp"
 cp -f "$objdir"/libhello.* "$objdir/lt-hell$EXEEXT" "$objdir/temp/libs"
-trap "func_restore_files" 0 1 2 13 15
 }
 
 func_require "demo-inst" "$prefix/lib/libhello.la"  "tests/demo/libhello.la"
@@ -50,7 +49,10 @@ func_get_config "library_names" "cat libhello.la"
 test -z "$library_names" \
   && func_skip "Exiting: demo/libhello.la is not a shared library"
 
+# AIX 5.3 `/bin/sh' will invoke the trap for 0 at the end of a
+# function, so we set the trap outside of a function to be portable.
 func_save_files
+trap func_restore_files 0 1 2 13 15
 
 func_get_config 'shlibpath_overrides_runpath
 hardcode_action
diff --git a/tests/depdemo-relink.test b/tests/depdemo-relink.test
index 382f36c..0d01279 100755
--- a/tests/depdemo-relink.test
+++ b/tests/depdemo-relink.test
@@ -47,7 +47,6 @@ func_save_files ()
   && cp -f "$objdir/depdemo$EXEEXT" "_fnord/temp"
 cp -f l3/libl3.la "_fnord/temp"
 cp -f l3/"$objdir"/* "_fnord/temp/libs"
-trap "func_restore_files" 0 1 2 13 15
 }
 
 func_require "depdemo-inst" "$prefix/lib/libl3.la"  "tests/depdemo/l3/libl3.la"
@@ -60,6 +59,9 @@ func_get_config "library_names" "cat l3/libl3.la"
 test -z "$library_names" \
   && func_skip "Exiting: depdemo/l3/libl3.la is not a shared library"
 
+# AIX 5.3 `/bin/sh' will invoke the trap for 0 at the end of a
+# function, so we set the trap outside of a function to be portable.
+trap func_restore_files 0 1 2 13 15
 func_save_files
 
 func_get_config 'shlibpath_overrides_runpath
-- 
1.7.8

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



[PATCH] libtool: minimise forks per invocation on cygwin and mingw.

2011-12-08 Thread Gary V. Vaughan
The recently pushed series of patches included the controversial
introduction of an additional 3 forks per invocation, which might
add a minute or two of wall-clock time to giant builds on windows.
By assuming that windows will run shell scripts on some shell with
all the modern optional features that libtool wants, this patch
eliminates even those 3 new forks.

Okay to push?

* build-aux/general.m4sh (lt_HAVE_PLUSEQ_OP, lt_HAVE_ARITH_OP)
(lt_HAVE_XSI_OPS) [cygwin, mingw]: Set these without a test on
the assumption that a modern shell (i.e. bash) will be used to
run libtool and libtoolize.

Signed-off-by: Gary V. Vaughan 
---
 build-aux/general.m4sh |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/build-aux/general.m4sh b/build-aux/general.m4sh
index 252b2d2..2ac6238 100644
--- a/build-aux/general.m4sh
+++ b/build-aux/general.m4sh
@@ -56,6 +56,7 @@ test "${ECHO+set}" = set || ECHO=${as_echo-'printf %s\n'}
 : ${SED="@SED@"}
 : ${SHELL="${CONFIG_SHELL-/bin/sh}"}
 : ${Xsed="$SED -e 1s/^X//"}
+: ${host="@host_triplet@"}
 
 # Global variables:
 EXIT_SUCCESS=0
@@ -74,6 +75,18 @@ dirname='s|/[^/]*$||'
 basename='s|^.*/||'
 
 
+# Forks are unreasonably slow under Windows, so we assume that, for at
+# least cygwin and mingw, /bin/sh is bash, and save at least 3 forks per
+# invocation:
+case $host in
+  *cygwin* | *mingw*)
+test -n "$lt_HAVE_PLUSEQ_OP" || lt_HAVE_PLUSEQ_OP=yes
+test -n "$lt_HAVE_ARITH_OP"  || lt_HAVE_ARITH_OP=yes
+test -n "$lt_HAVE_XSI_OPS"   || lt_HAVE_XSI_OPS=yes
+;;
+esac
+
+
 # lt_HAVE_PLUSEQ_OP
 # Can be empty, in which case the shell is probed, "yes" if += is useable
 # or anything else if += does not work.
-- 
1.7.8

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



FYI: [PATCH] maint: eliminate some more spurious leading Xs.

2011-12-08 Thread Gary V. Vaughan
Applied as obvious.

* m4/libtool.m4: Reverse argument order to eliminate spurious
leading X's.

Signed-off-by: Gary V. Vaughan 
---
 m4/libtool.m4 |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 0eef323..9c2574f 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -198,7 +198,7 @@ aix3*)
   # AIX sometimes has problems with the GCC collect2 program.  For some
   # reason, if we set the COLLECT_NAMES environment variable, the problems
   # vanish in a puff of smoke.
-  if test "X${COLLECT_NAMES+set}" != Xset; then
+  if test set != "${COLLECT_NAMES+set}"; then
 COLLECT_NAMES=
 export COLLECT_NAMES
   fi
@@ -739,7 +739,7 @@ _LT_EOF
 # AIX sometimes has problems with the GCC collect2 program.  For some
 # reason, if we set the COLLECT_NAMES environment variable, the problems
 # vanish in a puff of smoke.
-if test "X${COLLECT_NAMES+set}" != Xset; then
+if test set != "${COLLECT_NAMES+set}"; then
   COLLECT_NAMES=
   export COLLECT_NAMES
 fi
-- 
1.7.8

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



FYI: [PATCH] bootstrap: put back missing spaces before parens.

2011-12-08 Thread Gary V. Vaughan
Pushed as obvious.

* bootstrap (func_require_buildreq_autobuild)
(func_require_buildreq_automake): Vi's delete word command is
too greedy and also eats trailing whitespace before following
non-word-chars. Put back the spaces it ate so that
syntax-checks pass once again.

Signed-off-by: Gary V. Vaughan 
---
 bootstrap |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/bootstrap b/bootstrap
index 28f85b0..147ac08 100755
--- a/bootstrap
+++ b/bootstrap
@@ -972,7 +972,7 @@ func_require_build_aux ()
 # --
 # Try to find whether the bootstrap requires autobuild.
 require_buildreq_autobuild=func_require_buildreq_autobuild
-func_require_buildreq_autobuild()
+func_require_buildreq_autobuild ()
 {
 $debug_cmd
 
@@ -1041,7 +1041,7 @@ done
 # Try to find the minimum compatible version of automake required to
 # bootstrap successfully, and add it to `$buildreq'.
 require_buildreq_automake=func_require_buildreq_automake
-func_require_buildreq_automake()
+func_require_buildreq_automake ()
 {
 $debug_cmd
 
-- 
1.7.8

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



Re: [PATCH 3/4] maint: pick XSI funcs at runtime, not configure time.

2011-12-08 Thread Gary V. Vaughan
On 28 Nov 2011, at 21:44, Bob Friesenhahn wrote:
> On Mon, 28 Nov 2011, Peter Rosin wrote:
>> 
>> My typical use case is "mid-sized" at a magnitude or so larger, and
>> even there with a fork rate of approx 10-15 Hz as I'm seeing, it wouldn't
>> be too harsh with a couple of extra forks - a minutes or so on the
>> wall clock time. But it would really add to the pain on some
>> (hypothetical?) large project with thousands of libtool invocations.
>> That's all I'm saying, but *I* am not building any of those...
> 
> Is Windows "fork" performance observed to improve linearly as processor cores 
> are added, or does it maintain pretty much a fixed rate?  If it does not 
> improve linearly as processor cores are added, then the extra forks will 
> severely impact available performance of parallel builds.
> 
> I have become used to seeing substantial speedup with 'make -j 4' on a 
> Windows system with four cores.

I just pushed the series containing this patch, but refactored to add only 3
additional forks per invocation, and with a patch to follow which might be good
enough to eliminate even those 3 forks on windows machines.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


FYI: [PATCH 2/3] libtoolize: use _filter as a prefix for better ordering.

2011-12-08 Thread Gary V. Vaughan
* libtoolize.m4sh (require_Makefile_am_filter)
(require_ltdl_mk_filter, require_aclocal_m4_filter)
(require_configure_ac_filter): Rename these functions from this...
(require_filter_Makefile_am, require_filter_ltdl_mk)
(require_filter_aclocal_m4, require_filter_configure_ac): ...to
this, respectively.  Adjust all callers.
(Makefile_am_filter, ltdl_mk_filter, aclocal_m4_filter)
(configure_ac_filter): Rename these global variables from this...
(filter_Makefile_am, filter_ltdl_mk, filter_aclocal_m4)
(filter_configure_ac): ...to this, respectively.

Signed-off-by: Gary V. Vaughan 
---
 libtoolize.m4sh |   72 +++---
 1 files changed, 36 insertions(+), 36 deletions(-)

diff --git a/libtoolize.m4sh b/libtoolize.m4sh
index 65972e7..eeabb71 100644
--- a/libtoolize.m4sh
+++ b/libtoolize.m4sh
@@ -787,8 +787,8 @@ func_install_pkgltdl_files ()
   pkgltdl_header="putting libltdl files in \`$ltdl_dir'."
 fi
 
-$require_Makefile_am_filter
-$require_ltdl_mk_filter
+$require_filter_Makefile_am
+$require_filter_ltdl_mk
 
 # Copy ltdl sources appropriate to the requested ltdl_mode.
 for file in $pkgltdl_files; do
@@ -796,23 +796,23 @@ func_install_pkgltdl_files ()
   case $file in
 Makefile.am|Makefile.in)
   test nonrecursive = "$ltdl_mode" && continue
-  my_copy_filter=$Makefile_am_filter
+  my_copy_filter=$filter_Makefile_am
   ;;
 
 ltdl.mk)
   test nonrecursive = "$ltdl_mode" || continue
-  my_copy_filter=$ltdl_mk_filter
+  my_copy_filter=$filter_ltdl_mk
   ;;
 
 aclocal.m4)
   test subproject = "$ltdl_mode" && {
-$require_aclocal_m4_filter
+$require_filter_aclocal_m4
 
 # Always copy aclocal.m4, otherwise regenerating it can
 # overwrite the destination if it is symlinked.
 ( opt_copy=:
   func_copy "$file" "$pkgltdldir" "$ltdl_dir" \
-pkgltdl_header "$aclocal_m4_filter"
+pkgltdl_header "$filter_aclocal_m4"
 )
   }
   continue
@@ -824,13 +824,13 @@ func_install_pkgltdl_files ()
 
 configure)
   test subproject = "$ltdl_mode" && {
-$require_configure_ac_filter
+$require_filter_configure_ac
 
 # Always copy configure, otherwise regenerating it can
 # overwrite the destination if it is symlinked.
 ( opt_copy=:
   func_copy "$file" "$pkgltdldir" "$ltdl_dir" \
-pkgltdl_header "$configure_ac_filter"
+pkgltdl_header "$filter_configure_ac"
 )
   }
   continue
@@ -838,8 +838,8 @@ func_install_pkgltdl_files ()
 
 configure.ac)
   test subproject = "$ltdl_mode" || continue
-  $require_configure_ac_filter
-  my_copy_filter=$configure_ac_filter
+  $require_filter_configure_ac
+  my_copy_filter=$filter_configure_ac
   ;;
   esac
 
@@ -1245,13 +1245,13 @@ for base in '' ltdl_; do
 done
 
 
-# require_Makefile_am_filter
+# require_filter_Makefile_am
 # --
-# Set `Makefile_am_filter' ready for passing to func_copy when libltdl's
+# Set `filter_Makefile_am' ready for passing to func_copy when libltdl's
 # stock Makefile.am contents need to be filtered to work in recursive
 # mode.
-require_Makefile_am_filter=func_require_Makefile_am_filter
-func_require_Makefile_am_filter ()
+require_filter_Makefile_am=func_require_filter_Makefile_am
+func_require_filter_Makefile_am ()
 {
 $debug_cmd
 
@@ -1259,7 +1259,7 @@ func_require_Makefile_am_filter ()
 
 case $ltdl_mode in
   recursive)
-Makefile_am_filter='
+filter_Makefile_am='
 /^[^#]/{
   s|(LIBOBJS)|(ltdl_LIBOBJS)|g
   s|(LTLIBOBJS)|(ltdl_LTLIBOBJS)|g
@@ -1276,7 +1276,7 @@ func_require_Makefile_am_filter ()
   my_am_macro_dir_regex=`$ECHO "\
 $ltdl_am_macro_dir" |$SED "$sed_make_literal_regex"`
 
-  Makefile_am_filter="
+  filter_Makefile_am="
 /^ACLOCAL_AMFLAGS = /{
   s| -I $my_am_macro_dir_regex\$| -I $ltdl_relative_macro_dir|
 }
@@ -1287,7 +1287,7 @@ $ltdl_am_macro_dir" |$SED "$sed_make_literal_regex"`
   my_aux_dir_regex=`$ECHO "\
 $ltdl_ac_aux_dir" |$SED "$sed_make_literal_regex"`
 
-  Makefile_am_filter="$Makefile_am_filter
+  filter_Makefile_am="$filter_Makefile_am
 s|$my_aux_dir_regex|$ltdl_relative_aux_dir|g
 s|/\./|/|g
   "
@@ -1295,17 +1295,17 @@ $ltdl_ac_aux_dir&quo

FYI: [PATCH 3/3] libtoolize: reorder function definitions to keep func_filter_* together.

2011-12-08 Thread Gary V. Vaughan
* libtoolize: Restore asciibetical order, so that all the
filter function definitions are together.

Signed-off-by: Gary V. Vaughan 
---
 libtoolize.m4sh |  242 +++---
 1 files changed, 121 insertions(+), 121 deletions(-)

diff --git a/libtoolize.m4sh b/libtoolize.m4sh
index eeabb71..7e73098 100644
--- a/libtoolize.m4sh
+++ b/libtoolize.m4sh
@@ -1245,98 +1245,6 @@ for base in '' ltdl_; do
 done
 
 
-# require_filter_Makefile_am
-# --
-# Set `filter_Makefile_am' ready for passing to func_copy when libltdl's
-# stock Makefile.am contents need to be filtered to work in recursive
-# mode.
-require_filter_Makefile_am=func_require_filter_Makefile_am
-func_require_filter_Makefile_am ()
-{
-$debug_cmd
-
-$require_ltdl_mode
-
-case $ltdl_mode in
-  recursive)
-filter_Makefile_am='
-/^[^#]/{
-  s|(LIBOBJS)|(ltdl_LIBOBJS)|g
-  s|(LTLIBOBJS)|(ltdl_LTLIBOBJS)|g
-}'
-;;
-
-  subproject)
-$require_ltdl_ac_aux_dir
-$require_ltdl_am_macro_dir
-$require_ltdl_relative_aux_dir
-$require_ltdl_relative_macro_dir
-
-test "$ltdl_am_macro_dir" = "$ltdl_relative_macro_dir" || {
-  my_am_macro_dir_regex=`$ECHO "\
-$ltdl_am_macro_dir" |$SED "$sed_make_literal_regex"`
-
-  filter_Makefile_am="
-/^ACLOCAL_AMFLAGS = /{
-  s| -I $my_am_macro_dir_regex\$| -I $ltdl_relative_macro_dir|
-}
-s|dir)/$my_am_macro_dir_regex|dir)/$ltdl_relative_macro_dir|g"
-}
-
-test "$ltdl_ac_aux_dir" = "$ltdl_relative_aux_dir" || {
-  my_aux_dir_regex=`$ECHO "\
-$ltdl_ac_aux_dir" |$SED "$sed_make_literal_regex"`
-
-  filter_Makefile_am="$filter_Makefile_am
-s|$my_aux_dir_regex|$ltdl_relative_aux_dir|g
-s|/\./|/|g
-  "
-}
-;;
-esac
-
-require_filter_Makefile_am=:
-}
-
-
-# require_filter_ltdl_mk
-# --
-# Set `filter_ltdl_mk' ready for passing to func_copy in order for the
-# contents of ltdl.mk to match the nonrecursive libltdl directory into
-# which it is copied.
-require_filter_ltdl_mk=func_require_filter_ltdl_mk
-func_require_filter_ltdl_mk ()
-{
-$debug_cmd
-
-$require_ltdl_dir
-
-# Note that we strip comments right here, rather than rely on
-# using a $SED that allows comments.
-my_uscore=`$ECHO "$ltdl_dir" | $SED 's|[/.+-]|_|g'`
-filter_ltdl_mk=`$ECHO '
-  /^[^#]/{
-
-# Use only libltdl conditional objects.
-s|(LIBOBJS)|(ltdl_LIBOBJS)|g
-s|(LTLIBOBJS)|(ltdl_LTLIBOBJS)|g
-
-# Convert libltdl path and variable sections to $ltdl_dir.
-s|libltdl_|@my_uscore@_|
-s|libltdl/|@ltdl_dir@/|
-s|: libltdl/|: @ltdl_dir@/|
-s| -Ilibltdl | -I@ltdl_dir@ |
-s|\$(libltdl_|\$(@my_uscore@_|
-s|)/libltdl |)/@ltdl_dir@ |
-s|@my_uscore@|'"$my_uscore"'|g
-s|@ltdl_dir@|'"$ltdl_dir"'|g
-
-  }' | $SED '/^[]*#/d;/^$/d'`
-
-require_filter_ltdl_mk=:
-}
-
-
 # require_ac_aux_dir
 # --
 # Extract ac_aux_dir from AC_CONFIG_AUX_DIR.
@@ -1459,35 +1367,6 @@ func_require_ac_macro_dir ()
 }
 
 
-# require_filter_aclocal_m4
-# -
-# Set `filter_aclocal_m4' ready for passing to func_copy when libltdl's
-# stock aclocal.m4 contents need to be filtered to work in recursive
-# mode.
-require_filter_aclocal_m4=func_require_filter_aclocal_m4
-func_require_filter_aclocal_m4 ()
-{
-$debug_cmd
-
-$require_ltdl_am_macro_dir
-$require_ltdl_relative_macro_dir
-
-test "$ltdl_am_macro_dir" = "$ltdl_relative_macro_dir" || {
-  my_am_macro_dir_regex=`$ECHO "\
-$ltdl_am_macro_dir" |$SED "$sed_make_literal_regex"`
-
-  # Tricky [m] quoting to stop m4sh processing from flagging an
-  # undefined macro.
-  filter_aclocal_m4="
-/^[m]4_include(/{
-  s|$my_am_macro_dir_regex|$ltdl_relative_macro_dir|g
-}"
-}
-
-require_filter_aclocal_m4=:
-}
-
-
 # require_aux_dir
 # ---
 # Set aux_dir according to AC_CONFIG_AUX_DIR or else use the same
@@ -1552,6 +1431,89 @@ func_require_configure_ac ()
 }
 
 
+# require_filter_Makefile_am
+# --
+# Set `filter_Makefile_am' ready for passing to func_copy when libltdl's
+# stock Makefile.am contents need to be filtered to work in recursive
+# mode.
+require_filter_Makefile_am=func_require_filter_Makefile_am
+func_require_filter_Makefile_am ()
+{
+$debug_cmd
+
+$require_ltdl_mode
+
+case $ltdl_mode in
+  recursive)
+filter_M

FYI: [PATCH 1/3] libtoolize: rename ltdl.mk filter function.

2011-12-08 Thread Gary V. Vaughan
This series is just a split-up version of the following patch, for
better readability:

  http://lists.gnu.org/archive/html/libtool-patches/2011-11/msg00156.html

Pushed already, since the original was posted for review almost 2
weeks ago.

* libtoolize.m4sh (require_Makefile_inc_filter): Rename from
this...
(require_ltdl_mk_filter): ...to this. Adjust all callers.

Signed-off-by: Gary V. Vaughan 
---
 libtoolize.m4sh |   22 +++---
 1 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/libtoolize.m4sh b/libtoolize.m4sh
index 31bbf3e..65972e7 100644
--- a/libtoolize.m4sh
+++ b/libtoolize.m4sh
@@ -788,7 +788,7 @@ func_install_pkgltdl_files ()
 fi
 
 $require_Makefile_am_filter
-$require_Makefile_inc_filter
+$require_ltdl_mk_filter
 
 # Copy ltdl sources appropriate to the requested ltdl_mode.
 for file in $pkgltdl_files; do
@@ -801,7 +801,7 @@ func_install_pkgltdl_files ()
 
 ltdl.mk)
   test nonrecursive = "$ltdl_mode" || continue
-  my_copy_filter=$Makefile_inc_filter
+  my_copy_filter=$ltdl_mk_filter
   ;;
 
 aclocal.m4)
@@ -1299,13 +1299,13 @@ $ltdl_ac_aux_dir" |$SED "$sed_make_literal_regex"`
 }
 
 
-# require_Makefile_inc_filter
-# ---
-# Set `Makefile_inc_filter' ready for passing to func_copy in order for
-# the contents of Makefile.inc to match the nonrecursive libltdl
-# directory into which it is copied.
-require_Makefile_inc_filter=func_require_Makefile_inc_filter
-func_require_Makefile_inc_filter ()
+# require_ltdl_mk_filter
+# --
+# Set `ltdl_mk_filter' ready for passing to func_copy in order for the
+# contents of ltdl.mk to match the nonrecursive libltdl directory into
+# which it is copied.
+require_ltdl_mk_filter=func_require_ltdl_mk_filter
+func_require_ltdl_mk_filter ()
 {
 $debug_cmd
 
@@ -1314,7 +1314,7 @@ func_require_Makefile_inc_filter ()
 # Note that we strip comments right here, rather than rely on
 # using a $SED that allows comments.
 my_uscore=`$ECHO "$ltdl_dir" | $SED 's|[/.+-]|_|g'`
-Makefile_inc_filter=`$ECHO '
+ltdl_mk_filter=`$ECHO '
   /^[^#]/{
 
 # Use only libltdl conditional objects.
@@ -1333,7 +1333,7 @@ func_require_Makefile_inc_filter ()
 
   }' | $SED '/^[]*#/d;/^$/d'`
 
-require_Makefile_inc_filter=:
+require_ltdl_mk_filter=:
 }
 
 
-- 
1.7.7.4

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



FYI: [PATCH 5/5] bootstrap: escape quotes properly in generated functions.

2011-12-07 Thread Gary V. Vaughan
* bootstrap: Although not a real bug, for consistency, be sure
to correctly escape single quotes inside a single quoted
function generator.

Signed-off-by: Gary V. Vaughan 
---
 bootstrap |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/bootstrap b/bootstrap
index 5cd9cb0..d0567be 100755
--- a/bootstrap
+++ b/bootstrap
@@ -1018,7 +1018,7 @@ for tool in autoconf libtoolize autopoint; do
 # in order for `func_find_tool` to run.
 ${require_'$tool'-:}
 
-printf '%s\n' "$buildreq" |func_grep_q '\''^[   ]*'$tool\'' || {
+printf '\''%s\n'\'' "$buildreq" |func_grep_q '\''^[ ]*'$tool\'' || 
{
   func_extract_trace '$m'
   _G_version=$func_extract_trace_result
   test -n "$_G_version" && {
-- 
1.7.7.4

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



FYI: [PATCH 4/5] bootstrap: reorder function definitions to keep func_buildreq_* together.

2011-12-07 Thread Gary V. Vaughan
From: "Gary V. Vaughan" 

* bootstrap: Restore asciibetical order, so that all the
buildreq function definitions are together.

Signed-off-by: Gary V. Vaughan 
---
 bootstrap |  252 ++--
 1 files changed, 126 insertions(+), 126 deletions(-)

diff --git a/bootstrap b/bootstrap
index 0c2bbc2..5cd9cb0 100755
--- a/bootstrap
+++ b/bootstrap
@@ -862,6 +862,112 @@ func_require_aclocal_amflags ()
 }
 
 
+# require_autoheader
+# --
+# Skip autoheader if it's not needed.
+require_autoheader=func_require_autoheader
+func_require_autoheader ()
+{
+$debug_cmd
+
+test true = "$AUTOHEADER" || {
+  func_extract_trace AC_CONFIG_HEADERS
+  test -n "$func_extract_trace_result" \
+ || func_extract_trace AC_CONFIG_HEADER
+
+  test -n "$func_extract_trace_result" || {
+AUTOHEADER=true
+
+func_verbose "export AUTOHEADER='$AUTOHEADER'"
+
+# Make sure the search result is visible to subshells
+export AUTOHEADER
+  }
+}
+
+require_autoheader=:
+}
+
+
+# require_autopoint
+# -
+# Skip autopoint if it's not needed.
+require_autopoint=func_require_autopoint
+func_require_autopoint ()
+{
+$debug_cmd
+
+test true = "$AUTOPOINT" || {
+  func_extract_trace AM_GNU_GETTEXT_VERSION
+
+  test -n "$func_extract_trace_result" || {
+AUTOPOINT=true
+
+func_verbose "export AUTOPOINT='$AUTOPOINT'"
+
+# Make sure the search result is visible to subshells
+export AUTOPOINT
+  }
+}
+
+require_autopoint=:
+}
+
+
+# require_bootstrap_uptodate
+# --
+# Complain if the version of bootstrap in the gnulib directory differs
+# from the one we are running.
+require_bootstrap_uptodate=func_require_bootstrap_uptodate
+func_require_bootstrap_uptodate ()
+{
+$debug_cmd
+
+$require_gnulib_path
+
+test x = x"$gnulib_path" \
+|| func_cmp_s $progpath $gnulib_path/build-aux/bootstrap \
+|| func_warning upgrade "\
+\`$progpath' differs from \`./$gnulib_path/build-aux/bootstrap',
+please consider adopting the canonical version from gnulib."
+
+require_bootstrap_uptodate=:
+}
+
+
+# require_build_aux
+# -
+# Ensure that `$build_aux' is set, and if it doesn't already point to an
+# existing directory, create one.
+require_build_aux=func_require_build_aux
+func_require_build_aux ()
+{
+$debug_cmd
+
+test -n "$build_aux" || {
+  func_extract_trace AC_CONFIG_AUX_DIR
+  build_aux=$func_extract_trace_result
+  func_check_configuration build_aux \
+  "AC_CONFIG_AUX_DIR([name of a directory for build scripts])"
+
+  func_verbose "build_aux='$build_aux'"
+}
+
+$require_vc_ignore_files
+
+# If the build_aux directory doesn't exist, create it now, and mark it
+# as ignored for the VCS.
+if test ! -d "$build_aux"; then
+  func_show_eval "mkdir '$build_aux'"
+
+  test -n "$vc_ignore_files" \
+  || func_insert_sorted_if_absent "$build_aux" $vc_ignore_files
+fi
+
+require_build_aux=:
+}
+
+
 # require_buildreq_autobuild
 # --
 # Try to find whether the bootstrap requires autobuild.
@@ -930,33 +1036,6 @@ for tool in autoconf libtoolize autopoint; do
 done
 
 
-# require_autoheader
-# --
-# Skip autoheader if it's not needed.
-require_autoheader=func_require_autoheader
-func_require_autoheader ()
-{
-$debug_cmd
-
-test true = "$AUTOHEADER" || {
-  func_extract_trace AC_CONFIG_HEADERS
-  test -n "$func_extract_trace_result" \
- || func_extract_trace AC_CONFIG_HEADER
-
-  test -n "$func_extract_trace_result" || {
-AUTOHEADER=true
-
-func_verbose "export AUTOHEADER='$AUTOHEADER'"
-
-# Make sure the search result is visible to subshells
-export AUTOHEADER
-  }
-}
-
-require_autoheader=:
-}
-
-
 # require_buildreq_automake
 # -
 # Try to find the minimum compatible version of automake required to
@@ -988,82 +1067,32 @@ func_require_buildreq_automake()
 }
 
 
-# require_autopoint
-# -
-# Skip autopoint if it's not needed.
-require_autopoint=func_require_autopoint
-func_require_autopoint ()
-{
-$debug_cmd
-
-test true = "$AUTOPOINT" || {
-  func_extract_trace AM_GNU_GETTEXT_VERSION
-
-  test -n "$func_extract_trace_result" || {
-AUTOPOINT=true
-
-func_verbose "export AUTOPOINT='$AUTOPOINT'"
-
-# Make sure the search result is visible to subshells
-export AUTOPOINT
-  }
-}
-
-requir

FYI:[PATCH 3/5] bootstrap: use _buildreq as a prefix for better ordering.

2011-12-07 Thread Gary V. Vaughan
* bootstrap (require_autobuild_buildreq)
(require_autoconf_buildreq, require_automake_buildreq)
(require_autopoint_buildreq, require_libtoolize_buildreq)
(require_patch_buildreq): Rename from these...
(require_buildreq_autobuild, require_buildreq_autoconf)
(require_buildreq_automake, require_buildreq_autopoint)
(require_buildreq_libtoolize, require_buildreq_patch): ...to
these, respectively.  Adjust all callers.

Signed-off-by: Gary V. Vaughan 
---
 bootstrap |   44 ++--
 1 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/bootstrap b/bootstrap
index 8aba09b..0c2bbc2 100755
--- a/bootstrap
+++ b/bootstrap
@@ -862,11 +862,11 @@ func_require_aclocal_amflags ()
 }
 
 
-# require_autobuild_buildreq
+# require_buildreq_autobuild
 # --
 # Try to find whether the bootstrap requires autobuild.
-require_autobuild_buildreq=func_require_autobuild_buildreq
-func_require_autobuild_buildreq ()
+require_buildreq_autobuild=func_require_buildreq_autobuild
+func_require_buildreq_autobuild()
 {
 $debug_cmd
 
@@ -883,19 +883,19 @@ func_require_autobuild_buildreq ()
   }
 }
 
-require_autobuild_buildreq=:
+require_buildreq_autobuild=:
 }
 
 
-# require_autoconf_buildreq
-# require_autopoint_buildreq
-# require_libtoolize_buildreq
+# require_buildreq_autoconf
+# require_buildreq_autopoint
+# require_buildreq_libtoolize
 # ---
 # Try to find the minimum compatible version of autoconf/libtool
 # required to bootstrap successfully, and add it to `$buildreq'.
 for tool in autoconf libtoolize autopoint; do
   b=$tool
-  v=require_${tool}_buildreq
+  v=require_buildreq_${tool}
   f=func_$v
   case $tool in
 autoconf) m=AC_PREREQ ;;
@@ -957,12 +957,12 @@ func_require_autoheader ()
 }
 
 
-# require_automake_buildreq
+# require_buildreq_automake
 # -
 # Try to find the minimum compatible version of automake required to
 # bootstrap successfully, and add it to `$buildreq'.
-require_automake_buildreq=func_require_automake_buildreq
-func_require_automake_buildreq ()
+require_buildreq_automake=func_require_buildreq_automake
+func_require_buildreq_automake()
 {
 $debug_cmd
 
@@ -984,7 +984,7 @@ func_require_automake_buildreq ()
   }
 }
 
-require_automake_buildreq=:
+require_buildreq_automake=:
 }
 
 
@@ -1076,12 +1076,12 @@ func_require_buildtools_uptodate ()
 {
 $debug_cmd
 
-$require_autobuild_buildreq
-$require_autoconf_buildreq
-$require_automake_buildreq
-$require_libtoolize_buildreq
-$require_autopoint_buildreq
-$require_patch_buildreq
+$require_buildreq_autobuild
+$require_buildreq_autoconf
+$require_buildreq_automake
+$require_buildreq_libtoolize
+$require_buildreq_autopoint
+$require_buildreq_patch
 
 test -n "$buildreq" && {
   _G_error_hdr=
@@ -1639,12 +1639,12 @@ func_require_patch ()
 }
 
 
-# require_patch_buildreq
+# require_buildreq_patch
 # --
 # Automatically add a patch build-requirement if there are diff files
 # in $local_gl_dir.
-require_patch_buildreq=func_require_patch_buildreq
-func_require_patch_buildreq ()
+require_buildreq_patch=func_require_buildreq_patch
+func_require_buildreq_patch ()
 {
 $debug_cmd
 
@@ -1664,7 +1664,7 @@ func_require_patch_buildreq ()
   fi
 }
 
-require_patch_buildreq=:
+require_buildreq_patch=:
 }
 
 
-- 
1.7.7.4

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



FYI: [PATCH 1/5] bootstrap: make sure patch is available to bootstrap if necessary.

2011-12-07 Thread Gary V. Vaughan
A short series of improvements to bootstrap, inspired by the recent
enhancement to gnulib bootstrap to diagnose a missing patch binary
in the cases where that is required for bootstrap to operate.

All applied as obvious.


Make sure we're not lacking any functionality provided by the
incumbent gnulib bootstrap script, and where it's easy to do so
(like it is here), provide better functionality!
* bootstrap (require_patch): Make sure that PATCH expands to the
best `patch' command available on the system, honouring
overrides in the users environment.
(require_patch_buildreq): Automatically add a requirement for a
patch command to buildreq when there are diff files in
$local_gl_dir.
(func_require_buildtools_uptodate): Call require_patch_buildreq
before testing build tool versions.
(func_gnulib_tool_copy_file): Make sure PATCH is set before using
gnulib-tool to copy files.

Signed-off-by: Gary V. Vaughan 
---
 bootstrap |   55 +++
 1 files changed, 55 insertions(+), 0 deletions(-)

diff --git a/bootstrap b/bootstrap
index ae65e37..81a4a0d 100755
--- a/bootstrap
+++ b/bootstrap
@@ -556,6 +556,7 @@ func_gnulib_tool_copy_file ()
 
 $require_gnulib_path
 $require_gnulib_tool
+$require_patch
 
 gnulib_copy_cmd="$gnulib_tool --copy-file"
 $opt_copy || func_append gnulib_copy_cmd " --symlink"
@@ -1080,6 +1081,7 @@ func_require_buildtools_uptodate ()
 $require_automake_buildreq
 $require_libtoolize_buildreq
 $require_autopoint_buildreq
+$require_patch_buildreq
 
 test -n "$buildreq" && {
   _G_error_hdr=
@@ -1613,6 +1615,59 @@ func_gnulib_tool has installed the \`git-version-gen' 
script."
 }
 
 
+# require_patch
+# -
+# Find patch, according to the PATCH environment variable, or else
+# searching the user's PATH.
+require_patch=func_require_patch
+func_require_patch ()
+{
+$debug_cmd
+
+test -n "$PATCH" || {
+  # Find a patch program, preferring gpatch which is usually better
+  # than the vendor patch.
+  func_find_tool PATCH gpatch patch
+}
+
+func_verbose "export PATCH='$PATCH'"
+
+# Make sure the search result is visible to subshells
+export PATCH
+
+require_patch=:
+}
+
+
+# require_patch_buildreq
+# --
+# Automatically add a patch build-requirement if there are diff files
+# in $local_gl_dir.
+require_patch_buildreq=func_require_patch_buildreq
+func_require_patch_buildreq ()
+{
+$debug_cmd
+
+# This ensures PATCH is set appropriately by the time
+# func_check_versions enforces $buildreq.
+$require_patch
+
+# If patch is not already listed in $buildreq...
+printf '%s\n' "$buildreq" |func_grep_q '^[  ]*patch' || {
+  # The ugly find invocation is necessary to exit with non-zero
+  # status for old find binaries that don't support -exec fully.
+  if test ! -d "$local_gl_dir" \
+  || find "$local_gl_dir" -name *.diff -exec false {} +; then :
+  else
+  func_append buildreq 'patch - http://www.gnu.org/s/patch/
+'
+  fi
+}
+
+require_patch_buildreq=:
+}
+
+
 # require_source_base
 # ---
 # Ensure that source_base has a sensible value, extracted from
-- 
1.7.7.4

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



FYI: [PATCH 2/5] bootstrap: ensure consistent function header comments.

2011-12-07 Thread Gary V. Vaughan
* bootstrap (require_bootstrap_uptodate)
(require_buildtools_uptodate): Use `require_...' in header
comment for these functions to be consistent with the rest,
rather than `func_require_...'.

Signed-off-by: Gary V. Vaughan 
---
 bootstrap |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/bootstrap b/bootstrap
index 81a4a0d..8aba09b 100755
--- a/bootstrap
+++ b/bootstrap
@@ -1013,8 +1013,8 @@ func_require_autopoint ()
 }
 
 
-# func_require_bootstrap_uptodate
-# ---
+# require_bootstrap_uptodate
+# --
 # Complain if the version of bootstrap in the gnulib directory differs
 # from the one we are running.
 require_bootstrap_uptodate=func_require_bootstrap_uptodate
@@ -1067,8 +1067,8 @@ func_require_build_aux ()
 }
 
 
-# func_require_buildtools_uptodate
-# 
+# require_buildtools_uptodate
+# ---
 # Ensure all the packages listed in BUILDREQS are available on the build
 # machine at the minimum versions or better.
 require_buildtools_uptodate=func_require_buildtools_uptodate
-- 
1.7.7.4

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



Re: [PATCH 3/4] maint: pick XSI funcs at runtime, not configure time.

2011-11-28 Thread Gary V. Vaughan
Hi Peter,

On 28 Nov 2011, at 18:05, Peter Rosin wrote:
> Gary V. Vaughan skrev 2011-11-28 10:20:
>> On 28 Nov 2011, at 15:48, Peter Rosin wrote:
>>> Gary V. Vaughan skrev 2011-11-25 09:57:
>>>> Determine, on a function by function basis, what XSI features
>>>> are available in the shell that is actually running the script,
>>>> rather than the one that was picked at configure time by the
>>>> re-execution engine.
>>> 
>>> Doesn't this mean that the libtool script will do a number of
>>> extra forks each time it is run?
>> 
>> Well, yes and no.  There will be an extra 4 or 8 evals (depending
>> on whether the XSI function is chosen) as libtool starts up when
> 
> That's the evals in sub-shells, right? Those with this pattern:
> 
>   if $_use_fast_funcs && (eval ...) 2>/dev/null
>   then
> eval '...
> 
> or this:
> 
>   if (eval ...) 2>/dev/null
>   then
> eval '...

Yes, that's them.

>> [[snip]]
>>> If that's the case, I would like
>>> to know how that impacts the execution time on Cygwin/MinGW...
>> 
>> I don't have access to Windows so I can't actually measure it, but
>> I doubt that the difference will be noticeable for even a large
>> project, and quite possibly a small project like libltdl that only
>> runs libtool a hand full of times will actually be (imperceptibly)
>> faster.
> 
> I think you are underestimating the Cygwin fork pain.
> 
> BTW, libltdl runs libtool more like 20 times, but I agree it's very
> small and the number of forks will not matter much.
> 
> My typical use case is "mid-sized" at a magnitude or so larger, and
> even there with a fork rate of approx 10-15 Hz as I'm seeing, it wouldn't
> be too harsh with a couple of extra forks - a minutes or so on the
> wall clock time. But it would really add to the pain on some
> (hypothetical?) large project with thousands of libtool invocations.
> That's all I'm saying, but *I* am not building any of those...

Maybe I should switch the sense of the _use_fast_funcs, so that the
pattern becomes:

  if $libtool_force_fast_funcs || (eval ...) 2>/dev/null
  then
 eval '...

And then recommend that cygwin users always use an XSI and += capable
shell, with libtool_force_fast_funcs=: in the environment to cut out the
forks?

> Hmm, looking closer, shouldn't _use_fast_funcs have some kind of lt
> prefix?

Good point.  I'll add a prefix before pushing.  Thanks.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



Re: [PATCH 3/4] maint: pick XSI funcs at runtime, not configure time.

2011-11-28 Thread Gary V. Vaughan
Hi Peter,

On 28 Nov 2011, at 15:48, Peter Rosin wrote:
> Gary V. Vaughan skrev 2011-11-25 09:57:
>> Determine, on a function by function basis, what XSI features
>> are available in the shell that is actually running the script,
>> rather than the one that was picked at configure time by the
>> re-execution engine.
> 
> Doesn't this mean that the libtool script will do a number of
> extra forks each time it is run?

Well, yes and no.  There will be an extra 4 or 8 evals (depending
on whether the XSI function is chosen) as libtool starts up when
compared to 2.4.2, but the fast_funcs will each save a fork or
two on every invocation compared to if libtool configure found a non-
XSI shell when libtool was installed.  However, don't forget that
almost always, libtool is generated by the configure script of the
project that uses it, and the loss of seds, evals, and file renames
at configure time to splice in the fast_funcs most likely means
you'll be at a net win on total execution time for at least a couple
of dozen libtool invocations.

And let's not forget this actually fixes a bug... we've had reports
of configure re-execing with a good shell (say /opt/bin/bash) and
substituting in the XSI fast_funcs, but the libtool script doesn't
have all the slow re-exec machinery and runs with /bin/sh which then
chokes on the XSI extensions spliced in to libtool, unless the
caller manually sets SHELL and CONFIG_SHELL in their environment
before calling make (which is a bad idea for other reasons).

>  If that's the case, I would like
> to know how that impacts the execution time on Cygwin/MinGW...

I don't have access to Windows so I can't actually measure it, but
I doubt that the difference will be noticeable for even a large
project, and quite possibly a small project like libltdl that only
runs libtool a hand full of times will actually be (imperceptibly)
faster.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



Re: [PATCH 01/10] tests: migrate legacy tests/cdemo tests to Autotest.

2011-11-25 Thread Gary V. Vaughan
Hi Chuck,

On 26 Nov 2011, at 11:39, Charles Wilson wrote:
> On 11/25/2011 4:10 AM, Gary V. Vaughan wrote:
>> As usual, subject to feedback, I'll push this whole series in
>> 72 hours or so.  Make distcheck passes for me on my Mac 10.7 and
>> my Arch Linux x86_64 machines, but it would be great if folks with
> 
> a) This is a big holiday weekend in the US, so...a bit more than 72 hours is 
> indicated.  Most of us will still be catching up on post-holiday $realjob 
> stuff by the time 72 hours expires.

Ah, didn't think of that.  Sure, I will be busy myself for a week or two, so I 
won't push for at least a week, probably more.

> b) cygwin? mingw? msvc? All of the "old tests" have seen a LARGE number of 
> tweaks to ensure their proper operation on the various w32 platforms. Have 
> you done ANY testing there, at all, or are you relying on the rest of us to 
> do that work for you?

I'm afraid I don't have (or want) access to any Windows machines, so I'm afraid 
that I am relying on you guys to tell me if I screwed up.  Of course I'm not 
expecting you to debug or fix my mistakes for me, and I'm not anticipating any 
new problems, since everything is merely migrated from legacy testsuite to 
Autotest testsuite, with minimal changes required to keep everything working on 
my main machines.

Although I do normally have access to more machines, the flooding in Bangkok 
has made any use of my Internet connection other than email intolerably slow... 
hence the recent flurry of work on libtool (which I can do offline, queueing 
emails for when my connection is next up) to fill my time while I wait for 
things to get back to normal.  The reason I'll be too busy to do much more of 
that over the next week or two, is that last night I actually had a full-speed 
connection to the US again, so I'm anticipating playing catchup at $realjob 
myself.

> Sorry if I seem a bit short, but I'm rather annoyed to see my queue get 
> filled with hours upon hours of work in the middle of a holiday.

Please don't feel that it's your responsibility to painstakingly pick through 
every patch I post... I'd be more than happy just to get the test logs from 
anything I put on alpha.gnu.org for the architectures I don't use to help me 
restabilize the code closer to a release.

Enjoy the rest of your holiday, and sorry for working so much on libtool 
recently: although my objective with the recent modernisations has been to try 
to decruft libtool a little, and to make the barrier to contribution much lower 
than it is currently if at all possible.  I rarely have the chance to put a lot 
of time into libtool, and things will slow down considerably again now if my 
Internet connection really is back to (something like) normal again.  I have 
another 20 or so patches left incubating in my unpublished queue, and I will be 
done for now after those are polished and pushed over the next month or two.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


[PATCH] m4: fix logic error leading to -fno-rtti being added wrongly.

2011-11-25 Thread Gary V. Vaughan
Applied as the obvious fix for an error in translation in commit 962aa919.

* m4/libtool.m4 (_LT_COMPILER_OPTION): Negate comparison so that
compiler flags are added correctly.

Signed-off-by: Gary V. Vaughan 
---
 m4/libtool.m4 |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 007492c..4be85a5 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1532,7 +1532,7 @@ AC_CACHE_CHECK([$1], [$2],
$RM conftest*
 ])
 
-if test yes != "[$]$2"; then
+if test yes = "[$]$2"; then
 m4_if([$5], , :, [$5])
 else
 m4_if([$6], , :, [$6])
-- 
1.7.7.4

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



[PATCH] maint: Fix generated ChangeLog typos.

2011-11-25 Thread Gary V. Vaughan
Applied as obvious.

* build-aux/git-log-fix: Spell Stefano Lattarini's name
correctly.
Don't use my home email address for GNU commits.

Signed-off-by: Gary V. Vaughan 
---
 build-aux/git-log-fix |   19 +++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/build-aux/git-log-fix b/build-aux/git-log-fix
index 9ac3ced..810c021 100644
--- a/build-aux/git-log-fix
+++ b/build-aux/git-log-fix
@@ -2,6 +2,11 @@
 # option.  It specifies what changes to make to each given SHA1's commit
 # log and metadata, using Perl-eval'able expressions.
 
+11d16ab06c36948c053c507f5f9e06ff3de221c7
+# Date:   Fri Nov 25 14:39:57 2011 +0700
+# Spell Stefano's name correctly.
+s|Steffano|Stefano|
+
 a5ef08182ce0fb80b8adcff5872f190afd915908
 # Date:   Wed Nov 16 12:13:55 2011 +0700
 # Fix a typo.
@@ -17,8 +22,20 @@ e8db92c345b99acd9c6984a321fc241ed1d01d23
 # Email address of Reporters is in THANKS.
 s|(Reported by .*?) *<.*>|$1.|
 
+c188507816c4b43f3411677116ce4ab4b926958e
+# Date:   Mon Nov 7 23:43:56 2011 +0700
+# Use canonical gnu email address.
+s|vaughan\.pe|gnu.org|g
+
+fdb4c546784aebacaf697ebd5f96e0d91c566597
+# Date:   Tue Oct 18 13:20:53 2011 +0700
+# Use canonical gnu email address.
+s|vaughan\.pe|gnu.org|g
+
 0fe4d0740effaec9d08ee9683fb493d8ad0bd8b5
 # Date:   Mon Oct 17 16:43:18 2011 +0700
+# Use canonical gnu email address.
+s|vaughan\.pe|gnu.org|g;
 # No empty lines in a single commit.
 s|\n\n|\n|g;
 # Fix a typo.
@@ -26,6 +43,8 @@ s|soure|source|
 
 789817d512111d063981446efc7493ce87696bb3
 # Date:   Mon Oct 17 12:40:55 2011 +0700
+# Use canonical gnu email address.
+s|vaughan\.pe|gnu.org|g;
 # No empty lines in a single commit.
 s|\n\n|\n|g
 
-- 
1.7.7.4

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



Re: [PATCH 01/10] tests: migrate legacy tests/cdemo tests to Autotest.

2011-11-25 Thread Gary V. Vaughan
On 25 Nov 2011, at 18:59, Stefano Lattarini wrote:
> Hi Gary.

Hi Stefano,

> On Friday 25 November 2011, Gary V wrote:
>> The best reason I can find for keeping the various demo directories
>> around (despite the fact we already make use of the much better test
>> harness of Autotest for all our new test cases) from the last time
>> I wanted to migrate everything out of the legacy testsuite, was that
>> it exercises the distribution manager's autotools combination on the
>> testers machine, where the Autotests always use the users autotools.
>> That's no argument as far as I can see: we want tests to fail as
>> early as possible on a users machine to help him know things are not
>> going to work properly if he keeps going - and having the legacy
>> suite pass is only encouraging users to fight with broken installs.
>> 
>> This series of patches migrates all 9 of the demo directory test
>> groups into Autotest, and allows us to remove most of the legacy
>> testsuite cruft at the end.
>> 
> Just my 2 cents: I'd like to see the test scripts converted one at
> the time, rather than one group at the time (and assuming that this
> is feasible), as I found your huge patches basically un-reviewable
> in their present state.

The legacy tests are in sets that can't be broken apart without leaving
the tree in an inconsistent state part way through that set.

I could break them up a little more tho', if you think that would help,
so instead of converting one demo directory all at once, then a final
patch to clean out the configury cruft... there'd be 9 sets of patches
each containing almost everything in the current patch, except the
deletion of the the files in the given test/demo directory, followed by
a series of tiny patches each adding a dozen lines like this:

+## --- ##
+## Mdemo conf. ##
+## --- ##
+
+AT_SETUP([ltdl load shared and static modules])
+
+_LT_SETUP
+
+_LT_CHECK_CONFIG([], [^build_old_libs=yes], [^build_libtool_libs=yes])
+_LT_CHECK_EXECUTE
+_LT_CHECK_INSTALL
+_LT_CHECK_UNINSTALL
+
+AT_CLEANUP

plus removing the equivalent legacy set of 3 *.test files, and then a
final patch to delete the given test/demo tree, and relevant lines from
Makefile.am.

It'll take me a while to go through and do that, and we'll end up with
10 large patches each setting up a new tests/demo.at file, about 25
tiny patches per the above, then 10 small patches each removing one of
the tests/demo trees, and then the final cruft cleanout patch unchanged.

If that will make a big difference, let me know and I'll retract these
patches and post 50 or so to replace them in a week or two when I've
gone through and broken out the tiny per-test-group sets per the above.

>> There's still a few legacy tests
>> left at the end, which I'll tackle later, but at least maintenance
>> is a whole lot easier now that we don't need to wait for 9 additional
>> directories to autoreconf every time we run bootstrap, or distcheck,
>> or roll up a distribution tarball to test on the local network.
>> 
>> This is all in keeping with the theme of most of the patches I've
>> posted this year, to make libtool easier and more fun to maintain
>> and contribute to, in the hope of getting more people involved.
>> 
>> As usual, subject to feedback, I'll push this whole series in
>> 72 hours or so.  Make distcheck passes for me on my Mac 10.7 and
>> my Arch Linux x86_64 machines, but it would be great if folks with
>> access to other machines could give it a spin to see whether I
>> broke any of the tests during migration... if you'd like a pre-
>> rolled distro with my pending patches applied to do that, then
>> please do ask.
>> 
> If you want to send me such a tarball, I might run the testsuite on
> Solaris 10, Cygwin 1.5.25, NetBSD 5.1 and OpenBSD 4.6 at least.

Much appreciated.  Tarballs here:

  http://vaughan.pe/libtool/libtool-2.4.2.135-aa59c.tar.gz
  http://vaughan.pe/libtool/libtool-2.4.2.135-aa59c.tar.xz

>  But
> then you should allow for more than three days for sending feedback
> -- at least a week.

That's fine, and running on those arches would be a great help in
giving me confidence the migration didn't break anything.

It'll take me at least a week to redo everything into smaller pieces
anyway... (unless you think the time spent here will not make much
difference to your review). But do let me know either way :)  And
thanks also for offering to make the time to look them over.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)




Re: [PATCH 1/7] syntax-check: fix violations and implement sc_useless_quotes_in_case.

2011-11-25 Thread Gary V. Vaughan
On 21 Nov 2011, at 21:47, Gary V. Vaughan wrote:
> I'll push the whole series in 72 hours or so as usual.

Pushed.

> [[snip]]
> 
> Contrary to popular belief, Bourne shell does not resplit case
> expressions after expansion, so if there are no shell unquoted
> shell metacharacters or whitespace, the quotes are useless.
> * cfg.mk (sc_useless_quotes_in_case): New syntax-check rule to
> ensure we don't reintroduce useless quoted case expressions.
> * build-aux/ltmain.m4sh, m4/libtool.m4, tests/bindir.at,
> tests/darwin.at, tests/defs.m4sh, tests/demo-hardcode.test,
> tests/demo-nopic.test, tests/link-2.test, tests/quote.test,
> tests/sysroot.at: Remove spurious quotes.
> 
> Signed-off-by: Gary V. Vaughan 
> ---
> build-aux/ltmain.m4sh|   12 ++--
> cfg.mk   |8 
> m4/libtool.m4|2 +-
> tests/bindir.at  |4 ++--
> tests/darwin.at  |2 +-
> tests/defs.m4sh  |2 +-
> tests/demo-hardcode.test |4 ++--
> tests/demo-nopic.test|6 +++---
> tests/link-2.test|2 +-
> tests/quote.test |8 
> tests/sysroot.at         |2 +-
> 11 files changed, 30 insertions(+), 22 deletions(-)


Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



[PATCH 09/10] tests: migrate legacy tests/fcdemo tests to Autotest.

2011-11-25 Thread Gary V. Vaughan
Along with the demise of the last demo directory, so all the
cruft for re-autotooling and distributing the additional
directories is no longer necessary.
* tests/fcdemo.at: New autotest groups, based on...
* tests/fcdemo-conf.test, tests/fcdemo-exec.test,
tests/fcdemo-make.test, tests/fcdemo-shared-exec.test,
tests/fcdemo-shared-make.test, tests/fcdemo-shared.test,
tests/fcdemo-static-exec.test, tests/fcdemo-static-make.test,
tests/fcdemo-static.test: ...these legacy tests, now removed.
* tests/fcdemo/Makefile.am, tests/fcdemo/README,
tests/fcdemo/configure.ac, tests/fcdemo/cprogram.c,
tests/fcdemo/foo.h, tests/fcdemo/fooc.c, tests/fcdemo/foof.f90,
tests/fcdemo/foof2.f90, tests/fcdemo/foof3.f90,
tests/fcdemo/fprogram.f90: Remove.
* configure.ac (CONF_SUBDIRS, DIST_MAKEFILE_LIST): Remove.
* Makefile.am (DIST_SUBDIRS, FC_TESTS, clean-local-legacy)
(configure-subdirs, distclean-recursive, distdir)
(fake-distclean-legacy, $(DIST_MAKEFILE_LIST)): Remove.
(COMMON_TESTS): Rename from this...
(TESTS): ...to this.

Signed-off-by: Gary V. Vaughan 
---
 .gitignore|1 -
 Makefile.am   |   64 +---
 configure.ac  |   11 --
 tests/fcdemo-conf.test|   42 -
 tests/fcdemo-exec.test|   35 
 tests/fcdemo-make.test|   36 -
 tests/fcdemo-shared-exec.test |3 -
 tests/fcdemo-shared-make.test |3 -
 tests/fcdemo-shared.test  |   42 -
 tests/fcdemo-static-exec.test |3 -
 tests/fcdemo-static-make.test |3 -
 tests/fcdemo-static.test  |   42 -
 tests/fcdemo.at   |  346 +
 tests/fcdemo/.gitignore   |2 -
 tests/fcdemo/Makefile.am  |   75 -
 tests/fcdemo/README   |   12 --
 tests/fcdemo/configure.ac |   78 -
 tests/fcdemo/cprogram.c   |   54 ---
 tests/fcdemo/foo.h|   54 ---
 tests/fcdemo/fooc.c   |   41 -
 tests/fcdemo/foof.f90 |   10 --
 tests/fcdemo/foof2.f90|   12 --
 tests/fcdemo/foof3.f90|   12 --
 tests/fcdemo/fprogram.f90 |   31 
 24 files changed, 350 insertions(+), 662 deletions(-)
 delete mode 100755 tests/fcdemo-conf.test
 delete mode 100755 tests/fcdemo-exec.test
 delete mode 100755 tests/fcdemo-make.test
 delete mode 100755 tests/fcdemo-shared-exec.test
 delete mode 100755 tests/fcdemo-shared-make.test
 delete mode 100755 tests/fcdemo-shared.test
 delete mode 100755 tests/fcdemo-static-exec.test
 delete mode 100755 tests/fcdemo-static-make.test
 delete mode 100755 tests/fcdemo-static.test
 create mode 100644 tests/fcdemo.at
 delete mode 100644 tests/fcdemo/.gitignore
 delete mode 100644 tests/fcdemo/Makefile.am
 delete mode 100644 tests/fcdemo/README
 delete mode 100644 tests/fcdemo/configure.ac
 delete mode 100644 tests/fcdemo/cprogram.c
 delete mode 100644 tests/fcdemo/foo.h
 delete mode 100644 tests/fcdemo/fooc.c
 delete mode 100644 tests/fcdemo/foof.f90
 delete mode 100644 tests/fcdemo/foof2.f90
 delete mode 100644 tests/fcdemo/foof3.f90
 delete mode 100644 tests/fcdemo/fprogram.f90

diff --git a/.gitignore b/.gitignore
index f337328..c8db98e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -48,7 +48,6 @@
 Makefile
 Makefile.in
 \#*#
-_inst-*demo
 _libs
 acinclude.m4
 aclocal.m4
diff --git a/Makefile.am b/Makefile.am
index 670bbd4..7f75f38 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -323,14 +323,6 @@ libtool: $(ltmain_sh) $(config_status) $(dotversion)
  cd '$(top_builddir)' && '$(SHELL)' ./config.status '$@'; \
fi
 
-.PHONY: configure-subdirs
-configure-subdirs distdir: $(DIST_MAKEFILE_LIST)
-$(DIST_MAKEFILE_LIST):
-   $(AM_V_at)dir=`echo '$@' |'$(SED)' 's|^[^/]*$$|.|;s|/[^/]*$$||'`; \
-   test -d "$$dir" || mkdir "$$dir" || exit 1; \
-   abs_srcdir=`$(lt__cd) '$(srcdir)' && pwd`; \
-   (cd "$$dir" && "$$abs_srcdir/$$dir/configure" --with-dist) || exit 1
-
 
 ##  ##
 ## Libltdl. ##
@@ -695,6 +687,7 @@ TESTSUITE_AT= tests/testsuite.at \
  tests/cmdline_wrap.at \
  tests/pic_flag.at \
  tests/f77demo.at \
+ tests/fcdemo.at \
  tests/darwin.at \
  tests/dumpbin-symbols.at \
  tests/deplibs-mingw.at \
@@ -790,7 +783,7 @@ check-interactive: $(testsuite_deps_uninstalled)
 check-noninteractive: check-noninteractive-old check-noninteractive-new
 
 # We need to remove any file droppings left behind by testsuite
-clean-local: clean-local-legacy
+clean-local:
-$(CD_TESTDIR); \
test -f "$$abs_srcdir/$(TESTSUITE)" && \
'$(SHELL)' "$$abs_srcdir/$(TESTSUITE)" --clean
@@ -805,27 +798,7 @@ clean-local: clean-local-legacy
 #   using the new framework above.  When the migration is
 #

[PATCH 10/10] bootstrap: remove support for `-r' and `reconf_dirs'.

2011-11-25 Thread Gary V. Vaughan
With all those extra demo directories out of the way, we can
revert to a more canonical bootstrap process, and jettison the
cruft that was only there to work around the pain of
needing to autoreconf 11 directories.  Bootstrap is now an order
of magnitude faster.
* bootstrap.conf (require_ltdl_dir): New function. Factored out
of `libtool_build_prerequisites'.
(libtool_build_prerequisites): Adjust.
(func_reconfigure): Use `require_ltdl_dir' to determine the name
of the other directory we need to autoreconf during bootstrap.
(libtool_options_prep, libtool_parse_options)
(libtool_validate_options): Remove.

Signed-off-by: Gary V. Vaughan 
---
 bootstrap.conf |  175 +---
 1 files changed, 41 insertions(+), 134 deletions(-)

diff --git a/bootstrap.conf b/bootstrap.conf
index f7bc1ac..8763a33 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -1,4 +1,4 @@
-# bootstrap.conf (GNU Libtool) version 2011-11-21
+# bootstrap.conf (GNU Libtool) version 2011-11-24
 #
 # Copyright (C) 2010, 2011 Free Software Foundation, Inc.
 # Written by Gary V. Vaughan, 2010
@@ -109,15 +109,16 @@ require_bootstrap_uptodate=:
 
 # func_reconfigure
 # --
-# In addition to needing to autoreconf several directories, Libtool
-# provides `libtoolize' and doesn't use `autopoint', so we can use a
-# somewhat simpler `func_reconfigure' implementation.
+# In addition to needing to autoreconf two directories, Libtool provides
+# `libtoolize' and doesn't use `autopoint', so we can use a somewhat
+# simpler `func_reconfigure' implementation than bootstrap's version.
 func_reconfigure ()
 {
 $debug_cmd
 
 $require_autoheader
 $require_build_aux
+$require_ltdl_dir
 $require_macro_dir
 
 # Only need this from the top level directory
@@ -126,127 +127,19 @@ func_reconfigure ()
 export LIBTOOLIZE
 func_verbose "export LIBTOOLIZE='$LIBTOOLIZE'"
 
-# Also bootstrap any additional directories that were specified with
-# `reconfdirs' in the environment.
-save_IFS=$IFS
-IFS=,
-for sub in $opt_reconf_dirs; do
-  IFS=$save_IFS
-  my_autoreconf_options=
-  $opt_copy || func_append my_autoreconf_options " --symlink"
-  $opt_force && func_append my_autoreconf_options " --force"
-  $opt_verbose && func_append my_autoreconf_options " --verbose"
-  func_show_eval "$AUTORECONF$my_autoreconf_options --install $sub" \
-'exit $?'
-done
-IFS=$save_IFS
-}
-
-
-
-## --- ##
-## Hook functions. ##
-## --- ##
-
-# `bootstrap' itself takes care of the arguments it recognises, so we only
-# have to handle additional options here.  Setting exit_cmd to anything
-# other than `:', will tell `bootstrap' to exit after printing it's own
-# option loop parser errors.  Best not to use any time-consuming $require_
-# functions here, otherwise they will be run even if we only need to
-# process `--version'.
-
-# libtool_options_prep [ARG...]
-# -
-# Preparation for supporting additional options in Libtool bootstrap,
-# before the option parsing loop.
-libtool_options_prep ()
-{
-$debug_cmd
-
-# Extend the existing usage message
-usage_message=$usage_message'
-Libtool Specific Options:
-  -r, --reconf-dirs=DIR1,DIR2,...
-  limit the directories to be bootstrapped to
-  the comma-delimited list of DIR1,DIR2,...
-'
-
-# autoreconf all directories by default
-test -n "$reconfdirs" \
-  || reconfdirs=". libltdl `ls -1d tests/*demo tests/*demo[0-9]`"
-
-# pass back the list of options we consumed
-func_quote_for_eval ${1+"$@"}
-libtool_options_prep_result=$func_quote_for_eval_result
-}
-func_add_hook func_options_prep libtool_options_prep
+my_autoreconf_options=
+$opt_copy || func_append my_autoreconf_options " --symlink"
+$opt_force && func_append my_autoreconf_options " --force"
+$opt_verbose && func_append my_autoreconf_options " --verbose"
 
+func_show_eval "$AUTORECONF$my_autoreconf_options --install ." \
+  'exit $?'
 
-# libtool_parse_options [ARG...]
-# --
-# Provide handling for additional Libtool options inside the main option
-# parsing loop.
-libtool_parse_options ()
-{
-$debug_cmd
-
-# this inner loop lets us handle `-r.' in a single iteration
-while test $# -gt 0; do
-  opt=$1
-  shift
-
-  case $opt in
---reconf-dirs|--reconfdirs|-r)
-  test $# = 0 && func_missing_arg $opt && break
-  # squash spaces so that delimiter is just `,' and nothing else
-   

[PATCH 08/10] tests: migrate legacy tests/f77demo tests to Autotest.

2011-11-25 Thread Gary V. Vaughan
* tests/f77demo.at: New autotest groups, based on...
* tests/f77demo-conf.test, tests/f77demo-exec.test,
tests/f77demo-make.test, tests/f77demo-shared-exec.test,
tests/f77demo-shared-make.test, tests/f77demo-shared.test,
tests/f77demo-static-exec.test, tests/f77demo-static-make.test,
tests/f77demo-static.test: ...these legacy tests, now removed.
* tests/f77demo/Makefile.am, tests/f77demo/README,
tests/f77demo/configure.ac, tests/f77demo/cprogram.c,
tests/f77demo/foo.h, tests/f77demo/fooc.c, tests/f77demo/foof.f,
tests/f77demo/foof2.f, tests/f77demo/foof3.f,
tests/f77demo/fprogram.f: Remove.
* configure.ac (CONF_SUBDIRS): Remove tests/f77demo.

Signed-off-by: Gary V. Vaughan 
---
 Makefile.am|   41 +-
 configure.ac   |2 +-
 tests/f77demo-conf.test|   34 
 tests/f77demo-exec.test|   35 -
 tests/f77demo-make.test|   36 -
 tests/f77demo-shared-exec.test |3 -
 tests/f77demo-shared-make.test |3 -
 tests/f77demo-shared.test  |   34 
 tests/f77demo-static-exec.test |3 -
 tests/f77demo-static-make.test |3 -
 tests/f77demo-static.test  |   34 
 tests/f77demo.at   |  332 
 tests/f77demo/.gitignore   |2 -
 tests/f77demo/Makefile.am  |   65 
 tests/f77demo/README   |   12 --
 tests/f77demo/configure.ac |   71 -
 tests/f77demo/cprogram.c   |   53 ---
 tests/f77demo/foo.h|   53 ---
 tests/f77demo/fooc.c   |   41 -
 tests/f77demo/foof.f   |   10 --
 tests/f77demo/foof2.f  |   12 --
 tests/f77demo/foof3.f  |   12 --
 tests/f77demo/fprogram.f   |   31 
 23 files changed, 339 insertions(+), 583 deletions(-)
 delete mode 100755 tests/f77demo-conf.test
 delete mode 100755 tests/f77demo-exec.test
 delete mode 100755 tests/f77demo-make.test
 delete mode 100755 tests/f77demo-shared-exec.test
 delete mode 100755 tests/f77demo-shared-make.test
 delete mode 100755 tests/f77demo-shared.test
 delete mode 100755 tests/f77demo-static-exec.test
 delete mode 100755 tests/f77demo-static-make.test
 delete mode 100755 tests/f77demo-static.test
 create mode 100644 tests/f77demo.at
 delete mode 100644 tests/f77demo/.gitignore
 delete mode 100644 tests/f77demo/Makefile.am
 delete mode 100644 tests/f77demo/README
 delete mode 100644 tests/f77demo/configure.ac
 delete mode 100644 tests/f77demo/cprogram.c
 delete mode 100644 tests/f77demo/foo.h
 delete mode 100644 tests/f77demo/fooc.c
 delete mode 100644 tests/f77demo/foof.f
 delete mode 100644 tests/f77demo/foof2.f
 delete mode 100644 tests/f77demo/foof3.f
 delete mode 100644 tests/f77demo/fprogram.f

diff --git a/Makefile.am b/Makefile.am
index 2f9b90b..670bbd4 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -694,6 +694,7 @@ TESTSUITE_AT= tests/testsuite.at \
  tests/stresstest.at \
  tests/cmdline_wrap.at \
  tests/pic_flag.at \
+ tests/f77demo.at \
  tests/darwin.at \
  tests/dumpbin-symbols.at \
  tests/deplibs-mingw.at \
@@ -768,9 +769,7 @@ installcheck-local: $(testsuite_deps)
  AUTOTEST_PATH='$(exec_prefix)/bin'
 
 check-noninteractive-old:
-   $(AM_V_at)'$(MAKE)' $(AM_MAKEFLAGS) check-TESTS 
TESTS='$(NONINTERACTIVE_TESTS)'
-check-interactive-old:
-   $(AM_V_at)'$(MAKE)' $(AM_MAKEFLAGS) check-TESTS 
TESTS='$(INTERACTIVE_TESTS)'
+   $(AM_V_at)'$(MAKE)' $(AM_MAKEFLAGS) check-TESTS TESTS='$(TESTS)'
 
 # Run only noninteractive parts of the new testsuite.
 check-noninteractive-new: $(testsuite_deps_uninstalled)
@@ -781,14 +780,13 @@ check-noninteractive-new: $(testsuite_deps_uninstalled)
  $(TESTSUITEFLAGS)
 
 # Run only interactive parts of the new testsuite.
-check-interactive-new: $(testsuite_deps_uninstalled)
+check-interactive: $(testsuite_deps_uninstalled)
$(AM_V_at)$(CD_TESTDIR); \
CONFIG_SHELL='$(SHELL)' '$(SHELL)' "$$abs_srcdir/$(TESTSUITE)" \
  $(TESTS_ENVIRONMENT) $(BUILDCHECK_ENVIRONMENT) \
  -k interactive -k recursive INNER_TESTSUITEFLAGS=',interactive' \
  $(TESTSUITEFLAGS)
 
-check-interactive: check-interactive-old check-interactive-new
 check-noninteractive: check-noninteractive-old check-noninteractive-new
 
 # We need to remove any file droppings left behind by testsuite
@@ -807,26 +805,6 @@ clean-local: clean-local-legacy
 #   using the new framework above.  When the migration is
 #   complete this section should be removed.
 
-F77_TESTS = \
-   tests/f77demo-static.test \
-   tests/f77demo-static-make.test \
-   tests/f77demo-static-exec.test \
-   tests/f77demo-conf.test \
-   tests/f77demo-make.test \
-   tests/f77demo-exec.test \
-   tests/f77demo-shared.test \
- 

[PATCH 07/10] tests: migrate legacy tests/mdemo2 tests to Autotest.

2011-11-25 Thread Gary V. Vaughan
This test was just a small non-ltdl aware library to load a
library from the legacy mdemo test, which in turn used ltdl to
call functions from modules. No need to create a whole other
test group with copies of everything from mdemo setup - just
tack the additional test on the end of the mdemo group.
* tests/mdemo.at (link with library that loads ltdl modules):
New test, based on...
* tests/mdemo2-conf.test, tests/mdemo-exec.test,
tests/mdemo-make.test: ...these legacy tests, now removed.
* tests/mdemo2/Makefile.am, tests/mdemo2/README,
tests/mdemo2/configure.ac, tests/mdemo2/main.c: Remove.
* configure.ac (CONF_SUBDIRS): Remove tests/mdemo2.
* Makefile.am: Adjust.

Signed-off-by: Gary V. Vaughan 
---
 Makefile.am   |9 +
 configure.ac  |3 +-
 tests/mdemo.at|   83 +
 tests/mdemo2-conf.test|   34 --
 tests/mdemo2-exec.test|   35 ---
 tests/mdemo2-make.test|   35 ---
 tests/mdemo2/.gitignore   |2 -
 tests/mdemo2/Makefile.am  |   53 
 tests/mdemo2/README   |4 --
 tests/mdemo2/configure.ac |   62 -
 tests/mdemo2/main.c   |   46 -
 11 files changed, 85 insertions(+), 281 deletions(-)
 delete mode 100755 tests/mdemo2-conf.test
 delete mode 100755 tests/mdemo2-exec.test
 delete mode 100755 tests/mdemo2-make.test
 delete mode 100644 tests/mdemo2/.gitignore
 delete mode 100644 tests/mdemo2/Makefile.am
 delete mode 100644 tests/mdemo2/README
 delete mode 100644 tests/mdemo2/configure.ac
 delete mode 100644 tests/mdemo2/main.c

diff --git a/Makefile.am b/Makefile.am
index fe21b6e..2f9b90b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -854,14 +854,7 @@ COMMON_TESTS = \
tests/objectlist.test \
tests/quote.test \
tests/suffix.test \
-   tests/tagtrace.test \
-   tests/mdemo2-conf.test \
-   tests/mdemo2-make.test \
-   tests/mdemo2-exec.test
-
-tests/mdemo2-exec.log: tests/mdemo2-make.log
-tests/mdemo2-make.log: tests/mdemo2-conf.log \
-   tests/mdemo-dryrun.log
+   tests/tagtrace.test
 
 INTERACTIVE_TESTS =
 NONINTERACTIVE_TESTS = $(COMMON_TESTS)
diff --git a/configure.ac b/configure.ac
index f031fb6..fe76f2d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -126,8 +126,7 @@ AC_SUBST([pkgaux_scripts])
 
 # All subdirectories that are configured on demand, but that must be
 # included in the distribution.
-CONF_SUBDIRS="tests/f77demo tests/fcdemo \
-   tests/mdemo2"
+CONF_SUBDIRS="tests/f77demo tests/fcdemo"
 AC_SUBST([CONF_SUBDIRS])
 
 DIST_MAKEFILE_LIST=
diff --git a/tests/mdemo.at b/tests/mdemo.at
index d1ece9f..12c762d 100644
--- a/tests/mdemo.at
+++ b/tests/mdemo.at
@@ -103,6 +103,12 @@ mdemo_static_DEPENDENCIES = $(mdemo_DEPENDENCIES)
 
 libtool: $(LIBTOOL_DEPS)
$(SHELL) ./config.status --recheck
+
+include $(srcdir)/mdemo.mk
+]])
+
+AT_DATA([mdemo.mk],
+[[# Don't abort for lack of mdemo.mk
 ]])
 
 AT_DATA([foo.h],
@@ -780,3 +786,80 @@ force_dry_run=false
 _LT_CHECK_UNINSTALL
 
 AT_CLEANUP
+
+## --- ##
+## Mdemo2. ##
+## --- ##
+
+AT_SETUP([link with library that loads ltdl modules])
+
+_LT_SETUP
+
+AT_DATA([mdemo.mk],
+[[bin_PROGRAMS += mdemo2 mdemo2_static
+
+# Create a version of mdemo2 that links a library that does dlopen.
+mdemo2_LDFLAGS = -export-dynamic "-dlopen" force
+mdemo2_LDADD = libmlib.la
+
+# Create a statically linked version of mdemo.
+mdemo2_static_SOURCES = mdemo2.c
+mdemo2_static_LDFLAGS = $(STATIC) $(mdemo2_LDFLAGS)
+mdemo2_static_LDADD = $(mdemo2_LDADD)
+mdemo2_static_DEPENDENCIES = $(mdemo2_DEPENDENCIES)
+]])
+
+AT_DATA([mdemo2.c],
+[[#include 
+#include "ltdl.h"
+
+extern int mlib_func (int, char **);
+
+int main (int argc, char **argv)
+{
+  int ret = 0;
+
+  printf ("Welcome to GNU libtool mdemo2!\n");
+  if (argc < 2) {
+fprintf (stderr, "usage: %s module [module...]\n", argv[0]);
+  }
+
+  /* This must be called in the program to get the preloaded symbols */
+  LTDL_SET_PRELOADED_SYMBOLS();
+
+  ret = mlib_func(argc, argv);
+
+  return ret;
+}
+]])
+
+AT_DATA([expout],
+[[Welcome to GNU libtool mdemo2!
+module name: foo1
+module reference count: 1
+** This is foolib 1 **
+hello returned: 57616
+hello is ok!
+cos (0.0) = 1
+sub() called
+foo1 is ok!
+module name: libfoo2
+module reference count: 1
+** This is foolib 2 **
+hello returned: 57616
+hello is ok!
+sin (0.0) = 0
+sub() called
+foo2 is ok!
+]])
+
+_LT_CHECK_CONFIG
+
+LT_AT_MAKE
+
+LT_AT_EXEC_CHECK([./mdemo2_static], 0, [expout], [],
+[./foo1.la ./libfoo2.la | $EGREP -v '^module filename: '])
+LT_AT_EXEC_CHECK([./mdemo2], 0, [expout], [],
+[./foo1.la ./libfoo2.la | $EGREP -v '^module filename: '])
+
+AT_CLEANUP
diff --git a/tests/mdemo2-conf.test b/tests/mdemo2-conf.test
de

[PATCH 05/10] tests: migrate legacy tests/pdemo tests to Autotest.

2011-11-25 Thread Gary V. Vaughan
This test was a thinly veiled copy of the basic legacy
demo-conf.test series, with the addition of long file names that
are not unique in the first 17 characters of their name, mashed
up with the cmdline_wrap.at max_cmd_len limits.  Migrating to
Autotest means that this test will be automatically rerun with
max_cmd_len=24 as cmdline_wrap.at recurses through the whole
testsuite, so the migrated pdemo test is now simply another test
case in demo.at with longer file names.
* test/demo.at (linking with long file names): New test, based
on...
* tests/pdemo-conf.test, tests/pdemo-exec.test,
tests/pdemo-inst.test, tests/pdemo-make.test: ...these legacy
tests, now removed.
* tests/pdemo/Makefile.am, tests/pdemo/configure.ac,
tests/pdemo/foo.h, tests/pdemo/longer_file_name_dlmain.c,
tests/pdemo/longer_file_name_foo.c,
tests/pdemo/longer_file_name_foo2.c,
tests/pdemo/longer_file_name_hell1.c,
tests/pdemo/longer_file_name_hell2.c,
tests/pdemo/longer_file_name_hello.c,
tests/pdemo/longer_file_name_main.c: Remove.
* configure.ac (CONF_SUBDIRS): Remove tests/pdemo.
* Makefile.am: Adjust.

Signed-off-by: Gary V. Vaughan 
---
 Makefile.am   |9 --
 configure.ac  |2 +-
 tests/demo.at |  115 ++
 tests/pdemo-conf.test |   47 -
 tests/pdemo-exec.test |   36 ---
 tests/pdemo-inst.test |   38 ---
 tests/pdemo-make.test |   34 ---
 tests/pdemo/.gitignore|3 -
 tests/pdemo/Makefile.am   |  171 -
 tests/pdemo/configure.ac  |   73 --
 tests/pdemo/foo.h |  102 
 tests/pdemo/longer_file_name_dlmain.c |   97 ---
 tests/pdemo/longer_file_name_foo.c|   38 ---
 tests/pdemo/longer_file_name_foo2.c   |   35 ---
 tests/pdemo/longer_file_name_hell1.c  |   25 -
 tests/pdemo/longer_file_name_hell2.c  |   24 -
 tests/pdemo/longer_file_name_hello.c  |   36 ---
 tests/pdemo/longer_file_name_main.c   |   47 -
 18 files changed, 116 insertions(+), 816 deletions(-)
 delete mode 100755 tests/pdemo-conf.test
 delete mode 100755 tests/pdemo-exec.test
 delete mode 100755 tests/pdemo-inst.test
 delete mode 100755 tests/pdemo-make.test
 delete mode 100644 tests/pdemo/.gitignore
 delete mode 100644 tests/pdemo/Makefile.am
 delete mode 100644 tests/pdemo/configure.ac
 delete mode 100644 tests/pdemo/foo.h
 delete mode 100644 tests/pdemo/longer_file_name_dlmain.c
 delete mode 100644 tests/pdemo/longer_file_name_foo.c
 delete mode 100644 tests/pdemo/longer_file_name_foo2.c
 delete mode 100644 tests/pdemo/longer_file_name_hell1.c
 delete mode 100644 tests/pdemo/longer_file_name_hell2.c
 delete mode 100644 tests/pdemo/longer_file_name_hello.c
 delete mode 100644 tests/pdemo/longer_file_name_main.c

diff --git a/Makefile.am b/Makefile.am
index ac76788..4279389 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -868,10 +868,6 @@ COMMON_TESTS = \
tests/mdemo2-conf.test \
tests/mdemo2-make.test \
tests/mdemo2-exec.test \
-   tests/pdemo-conf.test \
-   tests/pdemo-make.test \
-   tests/pdemo-exec.test \
-   tests/pdemo-inst.test \
tests/mdemo-shared.test \
tests/mdemo-shared-make.test \
tests/mdemo-shared-exec.test \
@@ -900,11 +896,6 @@ tests/mdemo2-exec.log: tests/mdemo2-make.log
 tests/mdemo2-make.log: tests/mdemo2-conf.log \
tests/mdemo-dryrun.log
 
-tests/pdemo-inst.log:  tests/pdemo-exec.log
-tests/pdemo-exec.log:  tests/pdemo-make.log
-tests/pdemo-make.log:  tests/pdemo-conf.log
-
-
 INTERACTIVE_TESTS =
 NONINTERACTIVE_TESTS = $(COMMON_TESTS)
 if HAVE_F77
diff --git a/configure.ac b/configure.ac
index ab0fc04..d3908c8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -127,7 +127,7 @@ AC_SUBST([pkgaux_scripts])
 # All subdirectories that are configured on demand, but that must be
 # included in the distribution.
 CONF_SUBDIRS="tests/f77demo tests/fcdemo \
-   tests/mdemo tests/mdemo2 tests/pdemo"
+   tests/mdemo tests/mdemo2"
 AC_SUBST([CONF_SUBDIRS])
 
 DIST_MAKEFILE_LIST=
diff --git a/tests/demo.at b/tests/demo.at
index 347889d..751c9db 100644
--- a/tests/demo.at
+++ b/tests/demo.at
@@ -800,3 +800,118 @@ AT_CHECK([$unset LIBTOOL LIBTOOLIZE; $MAKE hell$EXEEXT 
libhello_la_OBJECTS=hello
  [1], [ignore], [ignore])
 
 AT_CLEANUP
+
+
+## --- ##
+## Pdemo conf. ##
+## --- ##
+
+AT_SETUP([linking with long file names])
+
+_LT_SETUP
+
+AT_DATA([Makefile.am],
+[[AUTOMAKE_OPTIONS = no-dependencies foreign
+ACLOCAL_AMFLAGS = -I m4
+
+# Build a libtool library, libhello.la for installation in libdir.
+lib_LTLIBRARIES = libhello.la
+libhello_la_SOURCES = longer_file_name_hello.c longer_file_name_foo.c 
longer_file_name_foo2.c
+libhello_la_

[PATCH 04/10] tests: migrate legacy tests/tagdemo tests to Autotest.

2011-11-25 Thread Gary V. Vaughan
* tests/tagdemo.at: New autotest groups, based on...
tests/tagdemo-conf.test, tests/tagdemo-exec.test,
tests/tagdemo-make.test, tests/tagdemo-shared-exec.test,
tests/tagdemo-shared-make.test, tests/tagdemo-shared.test,
tests/tagdemo-static-exec.test, tests/tagdemo-static-make.test,
tests/tagdemo-static.test, tests/tagdemo-undef-exec.test,
tests/tagdemo-undef-make.test, tests/tagdemo-undef.test:
...these legacy tests, now removed.
* tests/tagdemo/.gitignore, tests/tagdemo/Makefile.am,
tests/tagdemo/README, tests/tagdemo/baz.cpp,
tests/tagdemo/baz.h, tests/tagdemo/configure.ac,
tests/tagdemo/conv.cpp, tests/tagdemo/conv.h,
tests/tagdemo/foo.cpp, tests/tagdemo/foo.h,
tests/tagdemo/main.cpp: Remove.
* configure.ac (CONF_SUBDIRS): Remove tests/tagdemo.
* Makefile.am: Adjust.

Signed-off-by: Gary V. Vaughan 
---
 Makefile.am|   32 +---
 configure.ac   |2 +-
 tests/tagdemo-conf.test|   34 
 tests/tagdemo-exec.test|   34 
 tests/tagdemo-make.test|   34 
 tests/tagdemo-shared-exec.test |3 -
 tests/tagdemo-shared-make.test |3 -
 tests/tagdemo-shared.test  |   34 
 tests/tagdemo-static-exec.test |3 -
 tests/tagdemo-static-make.test |3 -
 tests/tagdemo-static.test  |   34 
 tests/tagdemo-undef-exec.test  |3 -
 tests/tagdemo-undef-make.test  |3 -
 tests/tagdemo-undef.test   |   50 -
 tests/tagdemo.at   |  408 
 tests/tagdemo/.gitignore   |1 -
 tests/tagdemo/Makefile.am  |   63 --
 tests/tagdemo/README   |6 -
 tests/tagdemo/baz.cpp  |   38 
 tests/tagdemo/baz.h|   46 -
 tests/tagdemo/configure.ac |   96 --
 tests/tagdemo/conv.cpp |   32 ---
 tests/tagdemo/conv.h   |   35 
 tests/tagdemo/foo.cpp  |   68 ---
 tests/tagdemo/foo.h|   59 --
 tests/tagdemo/main.cpp |   79 
 26 files changed, 411 insertions(+), 792 deletions(-)
 delete mode 100755 tests/tagdemo-conf.test
 delete mode 100755 tests/tagdemo-exec.test
 delete mode 100755 tests/tagdemo-make.test
 delete mode 100755 tests/tagdemo-shared-exec.test
 delete mode 100755 tests/tagdemo-shared-make.test
 delete mode 100755 tests/tagdemo-shared.test
 delete mode 100755 tests/tagdemo-static-exec.test
 delete mode 100755 tests/tagdemo-static-make.test
 delete mode 100755 tests/tagdemo-static.test
 delete mode 100755 tests/tagdemo-undef-exec.test
 delete mode 100755 tests/tagdemo-undef-make.test
 delete mode 100755 tests/tagdemo-undef.test
 create mode 100644 tests/tagdemo.at
 delete mode 100644 tests/tagdemo/.gitignore
 delete mode 100644 tests/tagdemo/Makefile.am
 delete mode 100644 tests/tagdemo/README
 delete mode 100644 tests/tagdemo/baz.cpp
 delete mode 100644 tests/tagdemo/baz.h
 delete mode 100644 tests/tagdemo/configure.ac
 delete mode 100644 tests/tagdemo/conv.cpp
 delete mode 100644 tests/tagdemo/conv.h
 delete mode 100644 tests/tagdemo/foo.cpp
 delete mode 100644 tests/tagdemo/foo.h
 delete mode 100644 tests/tagdemo/main.cpp

diff --git a/Makefile.am b/Makefile.am
index 28eee5c..ac76788 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -681,6 +681,7 @@ TESTSUITE_AT= tests/testsuite.at \
  tests/subproject.at \
  tests/nonrecursive.at \
  tests/recursive.at \
+ tests/tagdemo.at \
  tests/template.at \
  tests/ctor.at \
  tests/exceptions.at \
@@ -805,32 +806,6 @@ clean-local: clean-local-legacy
 #   using the new framework above.  When the migration is
 #   complete this section should be removed.
 
-CXX_TESTS = \
-   tests/tagdemo-static.test \
-   tests/tagdemo-static-make.test \
-   tests/tagdemo-static-exec.test \
-   tests/tagdemo-conf.test \
-   tests/tagdemo-make.test \
-   tests/tagdemo-exec.test \
-   tests/tagdemo-shared.test \
-   tests/tagdemo-shared-make.test \
-   tests/tagdemo-shared-exec.test \
-   tests/tagdemo-undef.test \
-   tests/tagdemo-undef-make.test \
-   tests/tagdemo-undef-exec.test
-
-tests/tagdemo-undef-exec.log:  tests/tagdemo-undef-make.log
-tests/tagdemo-undef-make.log:  tests/tagdemo-undef.log
-tests/tagdemo-undef.log:   tests/tagdemo-shared-exec.log
-tests/tagdemo-shared-exec.log: tests/tagdemo-shared-make.log
-tests/tagdemo-shared-make.log: tests/tagdemo-shared.log
-tests/tagdemo-shared.log:  tests/tagdemo-exec.log
-tests/tagdemo-exec.log:tests/tagdemo-make.log
-tests/tagdemo-make.log:tests/tagdemo-conf.log
-tests/tagdemo-conf.log:tests/tagdemo-static-exec.log
-tests/tagdemo-static-exec.log: tests/tagdemo-static-make.log
-tests/tagdemo-static-make.log: tests/tagdemo-static.log
-
 F77_TESTS = \
tests/f77demo-static.test \
tests/f77demo-static-make.test \
@@ -932,9 +907,6 @@ tests

[PATCH 01/10] tests: migrate legacy tests/cdemo tests to Autotest.

2011-11-25 Thread Gary V. Vaughan
The best reason I can find for keeping the various demo directories
around (despite the fact we already make use of the much better test
harness of Autotest for all our new test cases) from the last time
I wanted to migrate everything out of the legacy testsuite, was that
it exercises the distribution manager's autotools combination on the
testers machine, where the Autotests always use the users autotools.
That's no argument as far as I can see: we want tests to fail as
early as possible on a users machine to help him know things are not
going to work properly if he keeps going - and having the legacy
suite pass is only encouraging users to fight with broken installs.

This series of patches migrates all 9 of the demo directory test
groups into Autotest, and allows us to remove most of the legacy
testsuite cruft at the end.  There's still a few legacy tests
left at the end, which I'll tackle later, but at least maintenance
is a whole lot easier now that we don't need to wait for 9 additional
directories to autoreconf every time we run bootstrap, or distcheck,
or roll up a distribution tarball to test on the local network.

This is all in keeping with the theme of most of the patches I've
posted this year, to make libtool easier and more fun to maintain
and contribute to, in the hope of getting more people involved.

As usual, subject to feedback, I'll push this whole series in
72 hours or so.  Make distcheck passes for me on my Mac 10.7 and
my Arch Linux x86_64 machines, but it would be great if folks with
access to other machines could give it a spin to see whether I
broke any of the tests during migration... if you'd like a pre-
rolled distro with my pending patches applied to do that, then
please do ask.

* tests/cdemo.at: New Autotest groups, based on...
* tests/cdemo-conf.test, tests/cdemo-exec.test,
tests/cdemo-make.test, tests/cdemo-shared-exec.test,
tests/cdemo-shared-make.test, tests/cdemo-shared.test,
tests/cdemo-static-exec.test, tests/cdemo-static-make.test,
tests/cdemo-static.test, tests/cdemo-undef-exec.test,
tests/cdemo-undef-make.test, tests/cdemo-undef.test: ...these
legacy test cases, now removed.
tests/cdemo/Makefile.am, tests/cdemo/README,
tests/cdemo/configure.ac, tests/cdemo/foo.c, tests/cdemo/foo.h,
tests/cdemo/main.c: Remove.
* configure.ac (CONF_SUBDIRS): Remove tests/cdemo.
* Makefile.am: Adjust.

Signed-off-by: Gary V. Vaughan 
---
 Makefile.am  |   29 +--
 configure.ac |2 +-
 tests/cdemo-conf.test|   34 ---
 tests/cdemo-exec.test|   34 ---
 tests/cdemo-make.test|   34 ---
 tests/cdemo-shared-exec.test |3 -
 tests/cdemo-shared-make.test |3 -
 tests/cdemo-shared.test  |   34 ---
 tests/cdemo-static-exec.test |3 -
 tests/cdemo-static-make.test |3 -
 tests/cdemo-static.test  |   34 ---
 tests/cdemo-undef-exec.test  |3 -
 tests/cdemo-undef-make.test  |3 -
 tests/cdemo-undef.test   |   49 --
 tests/cdemo.at   |  201 ++
 tests/cdemo/.gitignore   |1 -
 tests/cdemo/Makefile.am  |   53 ---
 tests/cdemo/README   |4 -
 tests/cdemo/configure.ac |   63 -
 tests/cdemo/foo.c|   42 -
 tests/cdemo/foo.h|   37 
 tests/cdemo/main.c   |   45 --
 22 files changed, 205 insertions(+), 509 deletions(-)
 delete mode 100755 tests/cdemo-conf.test
 delete mode 100755 tests/cdemo-exec.test
 delete mode 100755 tests/cdemo-make.test
 delete mode 100755 tests/cdemo-shared-exec.test
 delete mode 100755 tests/cdemo-shared-make.test
 delete mode 100755 tests/cdemo-shared.test
 delete mode 100755 tests/cdemo-static-exec.test
 delete mode 100755 tests/cdemo-static-make.test
 delete mode 100755 tests/cdemo-static.test
 delete mode 100755 tests/cdemo-undef-exec.test
 delete mode 100755 tests/cdemo-undef-make.test
 delete mode 100755 tests/cdemo-undef.test
 create mode 100644 tests/cdemo.at
 delete mode 100644 tests/cdemo/.gitignore
 delete mode 100644 tests/cdemo/Makefile.am
 delete mode 100644 tests/cdemo/README
 delete mode 100644 tests/cdemo/configure.ac
 delete mode 100644 tests/cdemo/foo.c
 delete mode 100644 tests/cdemo/foo.h
 delete mode 100644 tests/cdemo/main.c

diff --git a/Makefile.am b/Makefile.am
index c55dfdd..77941ac 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -630,13 +630,14 @@ TESTSUITE = tests/testsuite
 TESTSUITE_AT   = tests/testsuite.at \
  tests/getopt-m4sh.at \
  tests/libtoolize.at \
+ tests/cdemo.at \
+ tests/convenience.at \
  tests/help.at \
  tests/duplicate_members.at \
  tests/duplicate_conv.at \
  tests/duplicate_deps.at \
  tests/flags.at \
  tests/inherited_flags.at \
- tests/convenience.at

[PATCH 4/4] libtoolize: refactor copying filter creation.

2011-11-25 Thread Gary V. Vaughan
Prevent the various require_filter functions from becoming too
long by factoring common code into new functions.
* libtoolize (func_make_relative_dir_filter)
(func_make_relative_ltdl_filter): New functions. Generalize and
consolidate the various similar snippets for concatenating
together the sed scripts for func_copy filtering.
(require_filter_Makefile_am, require_filter_aclocal_m4)
(require_filter_configure_ac): Simplify.
(require_ltdl_relative_aux_dir): Remove.
(require_ltdl_relative_macro_dir): Ditto.

Signed-off-by: Gary V. Vaughan 
---
 libtoolize.m4sh |  167 +--
 1 files changed, 89 insertions(+), 78 deletions(-)

diff --git a/libtoolize.m4sh b/libtoolize.m4sh
index bfa84f3..83b5001 100644
--- a/libtoolize.m4sh
+++ b/libtoolize.m4sh
@@ -1093,6 +1093,66 @@ func_autoconf_configure ()
 }
 
 
+# func_make_relative_dir_filter CURRDIR SRCDIR DESTDIR [PREFIX [SUFFIX]]
+# --
+# Make a sed script suitable for appending to a copy filter, which will
+# replace occurrences of CURRDIR with the relative path from SRCDIR to
+# DESTDIR if they are different, otherwise the result is the empty
+# string:
+#
+#func_make_relative_dir_filter ltdl config ../build-aux
+#  => 's|\.\./build-aux|../config|g'
+#func_make_relative_dir_filter ltdl ltdl/m4 ../m4
+#  => 's|\.\./m4|m4|g'
+#func_make_relative_dir_filter libltdl build-aux ../build-aux
+#  => ''
+#
+# If PREFIX (and SUFFIX) are passed they are prepended (and appended)
+# to the match and replacement expressions literally:
+#
+#func_make_relative_dir_filter ltdl ltdl/m4 ../m4 '-I ' ' '
+#  => 's|-I \.\./m4 |-I m4 |g'
+func_make_relative_dir_filter ()
+{
+$debug_cmd
+
+my_currdir=$1
+my_srcdir=$2
+my_destdir=$3
+
+func_relative_path "$my_srcdir" "$my_destdir"
+
+if test "$my_currdir" = "$func_relative_path_result"; then
+  func_make_relative_dir_filter_result=
+else
+  my_match_currdir=`$ECHO "$my_currdir" |$SED "$sed_make_literal_regex"`
+
+  # Avoid substituting with `dir/./file' when current dir is `.'.
+  if test . = "$my_currdir"; then
+func_make_relative_dir_filter_result="
+  s|$4$my_match_currdir/$5|$4$5|g"
+  else
+func_make_relative_dir_filter_result="
+  s|$4$my_match_currdir$5|$4$func_relative_path_result$5|g"
+  fi
+fi
+}
+
+# func_make_relative_ltdl_filter CURRDIR DESTDIR [PREFIX [SUFFIX]]
+# 
+# As `func_make_relative_dir_filter' optimised for the common case where
+# SRCDIR is `$ltdl_dir'.
+func_make_relative_ltdl_filter ()
+{
+$debug_cmd
+
+$require_ltdl_dir
+
+func_make_relative_dir_filter "$1" "$ltdl_dir" "$2" "$3" "$4"
+func_make_relative_ltdl_filter_result=$func_make_relative_dir_filter_result
+}
+
+
 ##  ##
 ## Resource management. ##
 ##  ##
@@ -1115,38 +1175,6 @@ func_autoconf_configure ()
 #
 # After that, the rest appear in asciibetical order.
 
-for base in aux_dir macro_dir; do
-
-  # require_ltdl_relative_aux_dir
-  # require_ltdl_relative_macro_dir
-  # ---
-  # Set ltdl_relative_aux_dir to the relative path from $ltdl_dir to
-  # the parent project auxiliary directory, and similarly for relative
-  # macro directory.
-  r=ltdl_relative_$base# _r_esource acquired by calling this function
-  v=require_$r # _v_ariable pointing to the function
-  f=func_$v# _f_unction name
-  eval $v'='$f'
-  '$f' ()
-  {
-$debug_cmd
-
-$require_ltdl_dir
-$require_'$base'
-
-func_relative_path "$ltdl_dir" "$'$base'"
-'$r'=$func_relative_path_result
-
-test -n "$'$r'" && func_verbose "'$r'='\'\$$r\''"
-
-'$v'=:
-  }'
-  # Some of these functions need to acquire the resource managed by the
-  # lexically preceding function; $o serves that purpose.
-  o=$r
-
-done
-
 for base in '' ltdl_; do
   if test ltdl_ = "$base"; then p='$pkgltdldir/'; else p=; fi
 
@@ -1453,31 +1481,23 @@ func_require_filter_Makefile_am ()
 ;;
 
   subproject)
-$require_ltdl_ac_aux_dir
+# Adjust default relative macro_dir paths.
 $require_ltdl_am_macro_dir
-$require_ltdl_relative_aux_dir
-$require_ltdl_relative_macro_dir
-
-test "$ltdl_am_macro_dir" = "$ltdl_relative_macro_dir" || {
-  my_am_macro_dir_regex=`$ECHO "\
-$ltdl_am_m

[PATCH 3/4] maint: pick XSI funcs at runtime, not configure time.

2011-11-25 Thread Gary V. Vaughan
Determine, on a function by function basis, what XSI features
are available in the shell that is actually running the script,
rather than the one that was picked at configure time by the
re-execution engine.
* m4/libtool.m4 (_LT_PROG_FUNCTION_REPLACE)
(_LT_PROG_REPLACE_SHELLFNS): Remove.
(_LT_CHECK_SHELL_FEATURES): Remove tests for XSI and += support.
* build-aux/general.m4sh (func_append, func_append_quoted)
(func_arith, func_len, func_basename, func_dirname)
(func_dirname_and_basename, func_stripname): List both enhanced
and fallback implementations, and choose one based on whether
the enhanced features required by the fastest version are
available.
* build-aux/getopt.m4sh (func_split_short_opt)
(func_split_long_opt): Ditto.
* build-aux/ltmain.m4sh (func_lo2o, func_xform): Ditto.
* tests/getopt-m4sh.at: Add tests for enhanced and fallback
implementations of func_arith, func_len, func_stripname and
func_dirname_and_basename.
* NEWS: Updated.

Signed-off-by: Gary V. Vaughan 
---
 NEWS   |4 +
 build-aux/general.m4sh |  162 ---
 build-aux/getopt.m4sh  |   38 ++--
 build-aux/ltmain.m4sh  |   33 --
 m4/libtool.m4  |  117 +--
 tests/getopt-m4sh.at   |  116 --
 6 files changed, 256 insertions(+), 214 deletions(-)

diff --git a/NEWS b/NEWS
index 0479a34..ecd4fa1 100644
--- a/NEWS
+++ b/NEWS
@@ -49,6 +49,10 @@ NEWS - list of user-visible changes between releases of GNU 
Libtool
 mode is selected; `--standalone' never worked, and is no longer
 accepted.
   - Libtool and libtoolize no longer choke on paths with a comma in them.
+  - In the case where $SHELL does not have the same enhanced features
+(e.g. the ability to parse `var+=append') as $CONFIG_SHELL, libtool
+will now correctly fallback to using only vanilla shell features
+instead of failing with a parse at startup.
 
 ** Important incompatible changes:
 
diff --git a/build-aux/general.m4sh b/build-aux/general.m4sh
index eeda222..648315d 100644
--- a/build-aux/general.m4sh
+++ b/build-aux/general.m4sh
@@ -73,63 +73,114 @@ IFS="   $lt_nl"
 dirname='s|/[^/]*$||'
 basename='s|^.*/||'
 
-
-# func_append var value
-# Append VALUE to the end of shell variable VAR.
-func_append ()
-{
+: ${_use_fast_funcs=":"}
+
+if $_use_fast_funcs && (eval 'x=a; x+=" b"; test "a b" = "$x"') 2>/dev/null
+then
+  # func_append var value
+  # Append VALUE to the end of shell variable VAR.
+  eval 'func_append ()
+  {
+eval "$1+=\$2"
+  }'
+
+  # func_append_quoted var value
+  # Quote VALUE and append to the end of shell variable VAR, separated
+  # by a space.
+  eval 'func_append_quoted ()
+  {
+func_quote_for_eval "$2"
+eval "$1+=\\ \$func_quote_for_eval_result"
+  }'
+else
+  func_append ()
+  {
 eval "$1=\$$1\$2"
-} # func_append may be replaced by extended shell implementation
+  }
 
-
-# func_append_quoted var value
-# Quote VALUE and append to the end of shell variable VAR, separated
-# by a space.
-func_append_quoted ()
-{
+  func_append_quoted ()
+  {
 func_quote_for_eval "$2"
 eval "$1=\$$1\\ \$func_quote_for_eval_result"
-} # func_append_quoted may be replaced by extended shell implementation
+  }
+fi
 
 
 # func_arith arithmetic-term...
-func_arith ()
-{
+if $_use_fast_funcs && (eval 'x=$(( 1 + 1 )); test 2 = "$x"') 2>/dev/null
+then
+  eval 'func_arith ()
+  {
+func_arith_result=$(( $* ))
+  }'
+else
+  func_arith ()
+  {
 func_arith_result=`expr "$@"`
-} # func_arith may be replaced by extended shell implementation
+  }
+fi
 
 
 # func_len string
 # STRING may not start with a hyphen.
-func_len ()
-{
+if $_use_fast_funcs && (eval 'x=12; test 2 = "${#x}"') 2>/dev/null
+then
+  eval 'func_len ()
+  {
+func_len_result=${#1}
+  }'
+else
+  func_len ()
+  {
 func_len_result=`expr "$1" : ".*" 2>/dev/null || echo $max_cmd_len`
-} # func_len may be replaced by extended shell implementation
+  }
+fi
 
 
-# func_dirname file append nondir_replacement
-# Compute the dirname of FILE.  If nonempty, add APPEND to the result,
-# otherwise set result to NONDIR_REPLACEMENT.
-func_dirname ()
-{
-func_dirname_result=`$ECHO "$1" | $SED "$dirname"`
-if test "X$func_dirname_result" = "X$1"; then
-  func_dirname_result=$3
-else
-  func_append func_dirname_result $2
-fi
-} # func_dirname may be replaced by extended shell implementation
+if $_use_fast_funcs \
+&& (eval 'x=a/x/b; a=${x%/*}; b=${x##*/}; test ba/x = "$a$b"') 2>/dev/null
+then
+  # If this shell supports suffix pattern removal, th

  1   2   3   4   5   6   7   8   9   10   >