bug#30126: Do not require “ltmain.sh” for out-of-tree libtool
Hello Paolo, Mathieu Lirzinwrites: >>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
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
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
I am opening a bug to keep track of this. Mathieu Lirzinwrites: > 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