bug#30126: Do not require “ltmain.sh” for out-of-tree libtool

2018-01-15 Thread Mathieu Lirzin
Hello Paolo,

Mathieu Lirzin  writes:

>>From a936b7d4cf8583ace0be6756b4b066a2c1aebe18 Mon Sep 17 00:00:00 2001
> From: Paolo Bonzini 
> Date: Mon, 31 Oct 2016 13:30:50 +0100
> Subject: [PATCH] automake: Do not require ltmain.sh for out-of-tree libtool
>
> If Automake does not see LT_SUPPORTED_TAG, it assumes an old libtool
> that does not know about AC_REQUIRE_AUX_FILE.  However, if the program
> does not use Libtool's configure.ac macros this check gets a
> false positive.  Do not require ltmain.sh if no Libtool macro is
> found in configure.ac.
>
> * bin/automake.in ($libtool_bundled): New variable.
> (handle_libtool): Do not require libtool files if libtool is not being
> bundled.
> (scan_autoconf_traces): Set $libtool_bundled.  Trace AC_PROG_LIBTOOL.
> ---

Would you have some time to allocate on a test for this patch in the
following days/weeks?  I would like to be able to merge it before
releasing Automake 1.16?

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37





bug#30127: ICC: 'entry point must be defined' error for shared builds on Windows

2018-01-15 Thread sav_ix
Hello everyone,

For libiconv builds using Windows ICC got error:
===
builddir="`pwd`"; cd libcharset && make all && make install-lib 
libdir="$builddir/lib" includedir="$builddir/lib"
make[1]: Entering directory '/c/libICONV-1.15/build/libcharset'
cd lib && make all
make[2]: Entering directory '/c/libICONV-1.15/build/libcharset/lib'
/bin/sh ../libtool --mode=link 
/c/libICONV-1.15/build/libcharset/../build-aux/compile icl  -Zc:wchar_t -nologo 
-DWIN32 -D_WIN32 -DWIN64 -D_WIN64  -D_CRT_SECURE_NO_DEPRECATE 
-D_SCL_SECURE_NO_DEPRECATE -Od -Zi -GS -DDEBUG -D_DEBUG -MDd  -o libcharset.la 
-rpath /c/libICONV-1.15/build/../ICC64DH/lib -version-info 1:0:0 -no-undefined 
localcharset.lo relocatable.lo
libtool: link: rm -fr  .libs/charset.exp
libtool: link: /usr/bin/nm -B  .libs/localcharset.obj .libs/relocatable.obj   | 
sed -n -e 's/^.*[    ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][   
]*\([_A-Za-z][_A-Za-z0-9]*\)\{0,1\}$/\1 \2 \2/p' | sed '/ __gnu_lto/d' | 
/usr/bin/sed -e '/^[BCDGRS][ ]/s/.*[ ]\([^ ]*\)/\1,DATA/' | /usr/bin/sed -e 
'/^[AITW][ ]/s/.*[ ]//' | sort | uniq > .libs/charset.exp
libtool: link: if test DEF = "`/usr/bin/sed -n -e 's/^[  ]*//' -e 
'/^\(;.*\)*$/d' -e 's/^\(EXPORTS\|LIBRARY\)\([ ].*\)*$/DEF/p' -e q 
.libs/charset.exp`" ; then cp ".libs/charset.exp" ".libs/charset-1.dll.def"; 
echo ".libs\\charset-1.dll.def" > ".libs/charset-1.dll.exp"; else /usr/bin/sed 
-e 's/^/-link -EXPORT:/' < .libs/charset.exp > .libs/charset-1.dll.exp; fi
libtool: link:  /c/libICONV-1.15/build/libcharset/../build-aux/compile icl -o 
.libs\\charset-1.dll  .libs/localcharset.obj .libs/relocatable.obj   -Od    
"@.libs\\charset-1.dll.exp" -Wl,-DLL,-IMPLIB:".libs\\charset.lib"
icl .libs\charset-1.dll .libs/localcharset.obj .libs/relocatable.obj -Od 
-Wl,-DLL,-IMPLIB:.libs\charset.lib

Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, 
Version 18.0.1.156 Build 20171018
Copyright (C) 1985-2017 Intel Corporation.  All rights reserved.
icl: command line warning #10157: ignoring option '/W'; argument is of wrong 
type

Microsoft (R) Incremental Linker Version 14.12.25830.2
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:.libs\charset-1.dll
-EXPORT:DllMain
-EXPORT:__local_stdio_printf_options
-EXPORT:_vsnprintf_l
-EXPORT:_vsprintf_l
-EXPORT:libcharset_relocate
-EXPORT:libcharset_set_relocation_prefix
-EXPORT:locale_charset
-EXPORT:sprintf
-EXPORT:DllMain
-EXPORT:__local_stdio_printf_options
-EXPORT:_vsnprintf_l
-EXPORT:_vsprintf_l
-EXPORT:libcharset_relocate
-EXPORT:libcharset_set_relocation_prefix
-EXPORT:locale_charset
-EXPORT:sprintf
.libs/localcharset.obj
.libs/relocatable.obj
   Creating library .libs\charset-1.lib and object .libs\charset-1.exp
LINK : fatal error LNK1561: entry point must be defined
make[2]: *** [Makefile:59: libcharset.la] Error 25
make[2]: Leaving directory '/c/libICONV-1.15/build/libcharset/lib'
make[1]: *** [Makefile:34: all] Error 2
make[1]: Leaving directory '/c/libICONV-1.15/build/libcharset'
make: *** [Makefile:42: lib/localcharset.h] Error 2
===

which relate to missing Windows ICC support in 'compile' 
(http://git.savannah.gnu.org/cgit/automake.git/tree/lib/compile) script.


Reproduced for:
- shared builds using Windows ICC,

not reproduced for:
- static builds using Windows ICC,
- shared builds using mingw-w64 and MSVC.


Environment:
  - Windows 10 x64,
  - ICC 2018 Update 1,
  - MSVC 2017 15.5.0,
  - Windows SDK 10.0.16299.15,
  - mingw-w64 x86_64 7.2.0,
  - MSYS2 x86_64 20170918,
  - libiconv 1.15.


The same error reproduced for shared builds of other OSS Projects with 
Autotools-based build systems.


MSYS2 (msys2.org) Project provide a fix for 'compile' script, which they 
distribute:
===
diff --git a/compile b/compile
index 531136b..2be28ec 100644
--- a/compile
+++ b/compile
@@ -255,7 +255,8 @@ EOF
 echo "compile $scriptversion"
 exit $?
 ;;
-  cl | *[/\\]cl | cl.exe | *[/\\]cl.exe )
+  cl | *[/\\]cl | cl.exe | *[/\\]cl.exe | \
+  icl | *[/\\]icl | icl.exe | *[/\\]icl.exe )
 func_cl_wrapper "$@"  # Doesn't return...
 ;;
 esac
===

but it's not convenient to update build system of OSS Projects before each 
build.
Can this fix be merged to Automake sources directly?


Best,

Alexander



bug#30128: MSVC: 'invalid numeric argument '/Wl, -DLL, -IMPLIB:.libs...' error for shared GMP builds on Windows

2018-01-15 Thread sav_ix
Hello everyone,

For GMP build using MSVC got error:
===
make[2]: Entering directory '/c/libGMP-6.1.99-dev/build'
/bin/sh ./libtool  --tag=CXX   --mode=link cl  -Zc:wchar_t -FS -nologo -DWIN32 
-D_WIN32 -DWIN64 -D_WIN64 -DUNICODE -D_UNICODE -D_CRT_SECURE_NO_DEPRECATE 
-D_SCL_SECURE_NO_DEPRECATE -GR -EHsc -O2 -DNDEBUG -D_NDEBUG -MD -no-undefined  
-version-info 9:0:5  -o libgmpxx.la -rpath 
/c/libGMP-6.1.99-dev/build/../MSVC64RH/lib cxx/dummy.lo cxx/isfuns.lo 
cxx/ismpf.lo cxx/ismpq.lo cxx/ismpz.lo cxx/ismpznw.lo cxx/limits.lo 
cxx/osdoprnti.lo cxx/osfuns.lo cxx/osmpf.lo cxx/osmpq.lo cxx/osmpz.lo libgmp.la
libtool: link: rm -fr  .libs/gmpxx.exp
libtool: link: /usr/bin/nm -B  cxx/.libs/dummy.obj cxx/.libs/isfuns.obj 
cxx/.libs/ismpf.obj cxx/.libs/ismpq.obj cxx/.libs/ismpz.obj 
cxx/.libs/ismpznw.obj cxx/.libs/limits.obj cxx/.libs/osdoprnti.obj 
cxx/.libs/osfuns.obj cxx/.libs/osmpf.obj cxx/.libs/osmpq.obj 
cxx/.libs/osmpz.obj   | sed -n -e 's/^.*[    
]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][  
]*\([_A-Za-z][_A-Za-z0-9]*\)\{0,1\}$/\1 \2 \2/p' | sed '/ __gnu_lto/d' | 
/usr/bin/sed 's/.* //' | sort | uniq > .libs/gmpxx.exp
libtool: link: if test DEF = "`/usr/bin/sed -n -e 's/^[  ]*//' -e 
'/^\(;.*\)*$/d' -e 's/^\(EXPORTS\|LIBRARY\)\([ ].*\)*$/DEF/p' -e q 
.libs/gmpxx.exp`" ; then cp ".libs/gmpxx.exp" ".libs/gmpxx-4.dll.def"; echo 
".libs\\gmpxx-4.dll.def" > ".libs/gmpxx-4.dll.exp"; else /usr/bin/sed -e 
's/^/-link -EXPORT:/' < .libs/gmpxx.exp > .libs/gmpxx-4.dll.exp; fi
libtool: link:  cl -o .libs\\gmpxx-4.dll  cxx/.libs/dummy.obj 
cxx/.libs/isfuns.obj cxx/.libs/ismpf.obj cxx/.libs/ismpq.obj 
cxx/.libs/ismpz.obj cxx/.libs/ismpznw.obj cxx/.libs/limits.obj 
cxx/.libs/osdoprnti.obj cxx/.libs/osfuns.obj cxx/.libs/osmpf.obj 
cxx/.libs/osmpq.obj cxx/.libs/osmpz.obj   -FS -O2    ./.libs/gmp.lib 
"@.libs\\gmpxx-4.dll.exp" -Wl,-DLL,-IMPLIB:".libs\\gmpxx.lib"
Microsoft (R) C/C++ Optimizing Compiler Version 19.12.25830.2 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

cl : Command line warning D9035 : option 'o' has been deprecated and will be 
removed in a future release
cl : Command line error D8021 : invalid numeric argument 
'/Wl,-DLL,-IMPLIB:.libs\gmpxx.lib'
make[2]: *** [Makefile:876: libgmpxx.la] Error 2
make[2]: Leaving directory '/c/libGMP-6.1.99-dev/build'
make[1]: *** [Makefile:963: all-recursive] Error 1
make[1]: Leaving directory '/c/libGMP-6.1.99-dev/build'
make: *** [Makefile:778: all] Error 2
===

which relate to improperC++ compiler use.


Reproduced for:
- shared builds using MSVC,

not reproduced for:
- static builds using MSVC,
- shared builds using mingw-w64.


Environment:
  - Windows 10 x64,
  - MSVC 2017 15.5.0,
  - Windows SDK 10.0.16299.15,
  - mingw-w64 x86_64 7.2.0,
  - MSYS2 x86_64 20170918,
  - libiconv 1.15.


The source of error is missing workaround for CXX compilers via 'compile' 
script, which enabled in '_AM_PROG_CC_C_O' 
(http://git.savannah.gnu.org/cgit/automake.git/tree/m4/prog-cc-c-o.m4) 
subroutine for C compilers only. This results to improper C++ compiler features 
check during configuration:
===
CC="cl" CXX="cl" ./configure && make



checking whether cl understands -c and -o together... no



checking if /c/libGMP-6.1.99-dev/build/compile cl supports -c -o file.obj... 
yes    <== C compiler features check



checking if cl supports -c -o file.obj... no    <== C++ compiler features check
===

and setting improper values to C++ compiler-related variables:
===
CC='/c/libGMP-6.1.99-dev/build/compile cl'
CPP='/c/libGMP-6.1.99-dev/build/compile cl -E'



CXX='cl'
CXXCPP='cl -E'
===

in 'configure.log' and makefiles.


A workaround is to apply patch:
===
    # A longer-term fix would be to have automake use am__CC in this case,
    # and then we could set am__CC="\$(top_srcdir)/compile \$(CC)"
    CC="$am_aux_dir/compile $CC"
+   CXX="$am_aux_dir/compile $CXX"
 fi
 ac_ext=c
 ac_cpp='$CPP $CPPFLAGS'
===

to file 'm4/prog-cc-c-o.m4' and update GMP build system. Then error not 
reproduced, and all build tasks finishes successfully.

Can this patch be merged to Automake sources? Or it it possible to add 
'_AM_PROG_CXX_C_O' or other subroutine for C++ compilers check, similar to 
'_AM_PROG_CC_C_O' for C compilers, which would provide this fix.


Best,

Alexander



bug#30126: Do not require “ltmain.sh” for out-of-tree libtool

2018-01-15 Thread Mathieu Lirzin
I am opening a bug to keep track of this.

Mathieu Lirzin  writes:

> Paolo Bonzini  writes:
>
>> On 31/10/2016 13:30, Paolo Bonzini wrote:
>>> If Automake does not see LT_SUPPORTED_TAG, it assumes an old libtool
>>> that does not know about AC_REQUIRE_AUX_FILE.  However, if the program
>>> does not use Libtool's configure.ac macros this check gets a
>>> false positive.  Do not require ltmain.sh if no Libtool macro is
>>> found in configure.ac.
>>> 
>>> Libtools that are not stone-age are already covered by LT_SUPPORTED_TAG
>>> and _LT_AC_TAGCONFIG, but add AC_PROG_LIBTOOL just in case for Libtool
>>> up to 1.4.
>>
>> This patch was never applied.
>>
>> Paolo
>>
>>> 2016-10-31  Paolo Bonzini  
>>> 
>>> * bin/automake.in ($libtool_bundled): New.
>>> (handle_libtool): Do not require libtool files if libtool is
>>> not being bundled.
>>> (scan_autoconf_traces): Set $libtool_bundled.  Trace
>>> AC_PROG_LIBTOOL too.
>>> 
>>> Signed-off-by: Paolo Bonzini 
>>> ---
>>> If the patch is accepted I will send an Autoconf patch to
>>> preselect AC_PROG_LIBTOOL.
>>> 
>>> Since this is a bug, it would be nice to add it at least to
>>> the 1.16 branch.
>>> 
>>>  bin/automake.in | 12 +++-
>>>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> I haven't tested this, and I am not a Libtool expert so I trust your
> analysis.
>
> What do you think of adding a test ensuring that ltmain.sh is not
> required when no Libtool macro is found?
>
> I have attached a updated patch with trivial formatting and comment
> changes.

Here is the current version of the patch which needs a test to be
merged.

>From a936b7d4cf8583ace0be6756b4b066a2c1aebe18 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini 
Date: Mon, 31 Oct 2016 13:30:50 +0100
Subject: [PATCH] automake: Do not require ltmain.sh for out-of-tree libtool

If Automake does not see LT_SUPPORTED_TAG, it assumes an old libtool
that does not know about AC_REQUIRE_AUX_FILE.  However, if the program
does not use Libtool's configure.ac macros this check gets a
false positive.  Do not require ltmain.sh if no Libtool macro is
found in configure.ac.

* bin/automake.in ($libtool_bundled): New variable.
(handle_libtool): Do not require libtool files if libtool is not being
bundled.
(scan_autoconf_traces): Set $libtool_bundled.  Trace AC_PROG_LIBTOOL.
---
 bin/automake.in | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/bin/automake.in b/bin/automake.in
index 5e36c0f..b7fbe96 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -344,6 +344,8 @@ my @extra_recursive_targets = ();
 
 # Lists of tags supported by Libtool.
 my %libtool_tags = ();
+# 1 if Libtool is being bundled, so ltmain.sh is required.
+my $libtool_bundled = 0;
 # 1 if Libtool uses LT_SUPPORTED_TAG.  If it does, then it also
 # uses AC_REQUIRE_AUX_FILE.
 my $libtool_new_api = 0;
@@ -2524,7 +2526,7 @@ sub handle_libtool ()
   # (Starting with Libtool 2.0 we do not have to bother.  These
   # requirements are done with AC_REQUIRE_AUX_FILE.)
   require_conf_file_with_macro (TRUE, 'LIBTOOL', FOREIGN, @libtool_files)
-if $relative_dir eq '.' && ! $libtool_new_api;
+if $relative_dir eq '.' && $libtool_bundled && ! $libtool_new_api;
 
   my @libtool_rms;
   foreach my $item (sort keys %libtool_clean_directories)
@@ -5239,6 +5241,7 @@ sub scan_autoconf_traces
 		_AM_COND_IF => 1,
 		_AM_COND_ELSE => 1,
 		_AM_COND_ENDIF => 1,
+		AC_PROG_LIBTOOL => 0,
 		LT_SUPPORTED_TAG => 1,
 		_LT_AC_TAGCONFIG => 0,
 		m4_include => 1,
@@ -5482,10 +5485,17 @@ EOF
 		if $mtime > $configure_deps_greatest_timestamp;
 	}
 	}
+  elsif ($macro eq 'AC_PROG_LIBTOOL')
+	{
+	  # Detect bundling of really old Libtool up to 1.4 that does not
+	  # support tags.
+	  $libtool_bundled = 1;
+	}
   elsif ($macro eq 'LT_SUPPORTED_TAG')
 	{
 	  $libtool_tags{$args[1]} = 1;
 	  $libtool_new_api = 1;
+	  $libtool_bundled = 1;
 	}
   elsif ($macro eq '_LT_AC_TAGCONFIG')
 	{
@@ -5498,6 +5508,7 @@ EOF
 	  # Hardcode the tags supported by Libtool 1.5.
 	  %libtool_tags = (CC => 1, CXX => 1, GCJ => 1, F77 => 1);
 	}
+	  $libtool_bundled = 1;
 	}
 }
 
-- 
2.9.5


-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37