Package: libtool;
Reported by: Theuns Heydenrych <theunsheydenrych <at> gmail.com>
Date: Tue, 4 Nov 2014 16:40:04 UTC
Severity: normal
To reply to this bug, email your comments to 18947 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-libtool <at> gnu.org:bug#18947; Package libtool.
(Tue, 04 Nov 2014 16:40:04 GMT) Full text and rfc822 format available.Theuns Heydenrych <theunsheydenrych <at> gmail.com>:bug-libtool <at> gnu.org.
(Tue, 04 Nov 2014 16:40:05 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Theuns Heydenrych <theunsheydenrych <at> gmail.com> To: bug-libtool <at> gnu.org Subject: unexpected EOF while looking for matching Date: Tue, 4 Nov 2014 15:27:17 +0200
[Message part 1 (text/plain, inline)]
HI When building Geos 3.4.2 with MinGW on Win7, the build fails at the last step when trying to link the dll, with the following. libtool: link: g++ -shared -nostdlib c:/Tools/MinGW/bin/../lib/gcc/i686-w64-mingw32/4.9.1/../../../../i686-w64-mingw32/lib/../lib/dllcrt2.o c:/Tools/MinGW/bin/../lib/gcc/i686-w64-mingw32/4.9.1/crtbegin.o .libs/inlines.o -Wl,--whole-archive algorithm/.libs/libalgorithm.a geom/.libs/libgeom.a geomgraph/.libs/libgeomgraph.a index/.libs/libindex.a io/.libs/libio.a linearref/.libs/liblinearref.a noding/.libs/libnoding.a operation/.libs/liboperation.a planargraph/.libs/libplanargraph.a precision/.libs/libprecision.a simplify/.libs/libsimplify.a triangulate/.libs/libtriangulate.a util/.libs/libutil.a -Wl,--no-whole-archive -L/c/mingw491/i686-491-posix-dwarf-rt_v3-rev0/mingw32/opt/lib -L/c/mingw491/prerequisites/i686-zlib-static/lib -L/c/mingw491/prerequisites/i686-w64-mingw32-static/lib' -Lc:/Tools/MinGW/bin/../lib/gcc/i686-w64-mingw32/4.9.1 -Lc:/Tools/MinGW/bin/../lib/gcc -Lc:/Tools/MinGW/bin/../lib/gcc/i686-w64-mingw32/4.9.1/../../../../i686-w64-mingw32/lib/../lib -Lc:/Tools/MinGW/bin/../lib/gcc/i686-w64-mingw32/4.9.1/../../../../lib -Lc:/Tools/MinGW/bin/../lib/gcc/i686-w64-mingw32/4.9.1/../../../../i686-w64-mingw32/lib -Lc:/Tools/MinGW/bin/../lib/gcc/i686-w64-mingw32/4.9.1/../../.. -lstdc++ -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32 -liconv -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt c:/Tools/MinGW/bin/../lib/gcc/i686-w64-mingw32/4.9.1/crtend.o -o .libs/libgeos-3-4-2.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libgeos.dll.a ../libtool: eval: line 7867: unexpected EOF while looking for matching `'' ../libtool: eval: line 7868: syntax error: unexpected end of file make[3]: *** [libgeos.la] Error 1 make[3]: Leaving directory `/c/cpp/dev/LibsExternal_/Gis/geos/geos-3.4.2/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/c/cpp/dev/LibsExternal_/Gis/geos/geos-3.4.2/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/c/cpp/dev/LibsExternal_/Gis/geos/geos-3.4.2' make: *** [all] Error 2 What i have figured out so far is to list the default search path for gcc in MinGW is to issue the command gcc -### -o foo foo.c This will produce the following: $ gcc -### -o foo foo.c > /c/dev/gcc.txt gcc.exe: error: foo.c: No such file or directory Using built-in specs. COLLECT_GCC=c:\Tools\MinGW\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/Tools/MinGW/bin/../libexec/gcc/i686-w64-mingw32/4.9.1/lto-wrapper.exe Target: i686-w64-mingw32 Configured with: ../../../src/gcc-4.9.1/configure --host=i686-w64-mingw32 --build=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/mingw32 --with-sysroot=/c/mingw491/i686-491-posix-dwarf-rt_v3-rev0/mingw32 --with-gxx-include-dir=/mingw32/i686-w64-mingw32/include/c++ --enable-shared --enable-static --disable-multilib --enable-languages=ada,c,c++,fortran,objc,obj-c++,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --disable-sjlj-exceptions --with-dwarf2 --disable-isl-version-check --disable-cloog-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=i686 --with-tune=generic --with-libiconv --with-system-zlib --with-gmp=/c/mingw491/prerequisites/i686-w64-mingw32-static --with-mpfr=/c/mingw491/prerequisites/i686-w64-mingw32-static --with-mpc=/c/mingw491/prerequisites/i686-w64-mingw32-static --with-isl=/c/mingw491/prerequisites/i686-w64-mingw32-static --with-cloog=/c/mingw491/prerequisites/i686-w64-mingw32-static --enable-cloog-backend=isl --with-pkgversion='i686-posix-dwarf-rev0, Built by MinGW-W64 project' --with-bugurl= http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/c/mingw491/i686-491-posix-dwarf-rt_v3-rev0/mingw32/opt/include -I/c/mingw491/prerequisites/i686-zlib-static/include -I/c/mingw491/prerequisites/i686-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/c/mingw491/i686-491-posix-dwarf-rt_v3-rev0/mingw32/opt/include -I/c/mingw491/prerequisites/i686-zlib-static/include -I/c/mingw491/prerequisites/i686-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/c/mingw491/i686-491-posix-dwarf-rt_v3-rev0/mingw32/opt/lib -L/c/mingw491/prerequisites/i686-zlib-static/lib -L/c/mingw491/prerequisites/i686-w64-mingw32-static/lib' Thread model: posix gcc version 4.9.1 (i686-posix-dwarf-rev0, Built by MinGW-W64 project) So there right at the end is the "offending" path, some script that should extract the -L paths, is bringing the ' character in, at the end of the line. I am not sure if it is the libtool's configure scripts, but somewhere in the configure scripts, the ' (single quote character) should not be part of the library path.
[Message part 2 (text/html, inline)]
bug-libtool <at> gnu.org:bug#18947; Package libtool.
(Wed, 05 Nov 2014 08:08:02 GMT) Full text and rfc822 format available.Message #8 received at 18947 <at> debbugs.gnu.org (full text, mbox):
From: Peter Rosin <peda <at> lysator.liu.se> To: Theuns Heydenrych <theunsheydenrych <at> gmail.com>, 18947 <at> debbugs.gnu.org Subject: Re: bug#18947: unexpected EOF while looking for matching Date: Wed, 05 Nov 2014 09:07:22 +0100
Hi! Thanks for the report! On 2014-11-04 14:27, Theuns Heydenrych wrote: > HI > When building Geos 3.4.2 with MinGW on Win7, the build fails at the last step when trying to link the dll, with the following. > > libtool: link: g++ -shared -nostdlib c:/Tools/MinGW/bin/../lib/gcc/i686-w64-mingw32/4.9.1/../../../../i686-w64-mingw32/lib/../lib/dllcrt2.o c:/Tools/MinGW/bin/../lib/gcc/i686-w64-mingw32/4.9.1/crtbegin.o .libs/inlines.o -Wl,--whole-archive algorithm/.libs/libalgorithm.a geom/.libs/libgeom.a geomgraph/.libs/libgeomgraph.a index/.libs/libindex.a io/.libs/libio.a linearref/.libs/liblinearref.a noding/.libs/libnoding.a operation/.libs/liboperation.a planargraph/.libs/libplanargraph.a precision/.libs/libprecision.a simplify/.libs/libsimplify.a triangulate/.libs/libtriangulate.a util/.libs/libutil.a -Wl,--no-whole-archive -L/c/mingw491/i686-491-posix-dwarf-rt_v3-rev0/mingw32/opt/lib -L/c/mingw491/prerequisites/i686-zlib-static/lib -L/c/mingw491/prerequisites/i686-w64-mingw32-static/lib' -Lc:/Tools/MinGW/bin/../lib/gcc/i686-w64-mingw32/4.9.1 -Lc:/Tools/MinGW/bin/../lib/gcc -Lc:/Tools/MinGW/bin/../lib/gcc/i686-w64-mingw32/4.9.1/../../../../i686-w64-mingw32/lib/../lib > -Lc:/Tools/MinGW/bin/../lib/gcc/i686-w64-mingw32/4.9.1/../../../../lib -Lc:/Tools/MinGW/bin/../lib/gcc/i686-w64-mingw32/4.9.1/../../../../i686-w64-mingw32/lib -Lc:/Tools/MinGW/bin/../lib/gcc/i686-w64-mingw32/4.9.1/../../.. -lstdc++ -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32 -liconv -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt c:/Tools/MinGW/bin/../lib/gcc/i686-w64-mingw32/4.9.1/crtend.o -o .libs/libgeos-3-4-2.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libgeos.dll.a > > ../libtool: eval: line 7867: unexpected EOF while looking for matching `'' > ../libtool: eval: line 7868: syntax error: unexpected end of file > make[3]: *** [libgeos.la <http://libgeos.la/>] Error 1 > make[3]: Leaving directory `/c/cpp/dev/LibsExternal_/Gis/geos/geos-3.4.2/src' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/c/cpp/dev/LibsExternal_/Gis/geos/geos-3.4.2/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/c/cpp/dev/LibsExternal_/Gis/geos/geos-3.4.2' > make: *** [all] Error 2 > > What i have figured out so far is to list the default search path for gcc in MinGW is to issue the command > gcc -### -o foo foo.c > > This will produce the following: > $ gcc -### -o foo foo.c > /c/dev/gcc.txt > gcc.exe: error: foo.c: No such file or directory > Using built-in specs. > COLLECT_GCC=c:\Tools\MinGW\bin\gcc.exe > COLLECT_LTO_WRAPPER=c:/Tools/MinGW/bin/../libexec/gcc/i686-w64-mingw32/4.9.1/lto-wrapper.exe > Target: i686-w64-mingw32 > Configured with: ../../../src/gcc-4.9.1/configure --host=i686-w64-mingw32 --build=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/mingw32 --with-sysroot=/c/mingw491/i686-491-posix-dwarf-rt_v3-rev0/mingw32 > --with-gxx-include-dir=/mingw32/i686-w64-mingw32/include/c++ --enable-shared --enable-static --disable-multilib --enable-languages=ada,c,c++,fortran,objc,obj-c++,lto --enable-libstdcxx-time=yes --enable-threads=posix > --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --disable-sjlj-exceptions --with-dwarf2 > --disable-isl-version-check --disable-cloog-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror > --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=i686 --with-tune=generic --with-libiconv --with-system-zlib --with-gmp=/c/mingw491/prerequisites/i686-w64-mingw32-static > --with-mpfr=/c/mingw491/prerequisites/i686-w64-mingw32-static --with-mpc=/c/mingw491/prerequisites/i686-w64-mingw32-static --with-isl=/c/mingw491/prerequisites/i686-w64-mingw32-static > --with-cloog=/c/mingw491/prerequisites/i686-w64-mingw32-static --enable-cloog-backend=isl --with-pkgversion='i686-posix-dwarf-rev0, > Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 > CFLAGS='-O2 -pipe -I/c/mingw491/i686-491-posix-dwarf-rt_v3-rev0/mingw32/opt/include -I/c/mingw491/prerequisites/i686-zlib-static/include -I/c/mingw491/prerequisites/i686-w64-mingw32-static/include' > CXXFLAGS='-O2 -pipe -I/c/mingw491/i686-491-posix-dwarf-rt_v3-rev0/mingw32/opt/include -I/c/mingw491/prerequisites/i686-zlib-static/include -I/c/mingw491/prerequisites/i686-w64-mingw32-static/include' > CPPFLAGS= LDFLAGS='-pipe -L/c/mingw491/i686-491-posix-dwarf-rt_v3-rev0/mingw32/opt/lib -L/c/mingw491/prerequisites/i686-zlib-static/lib -L/c/mingw491/prerequisites/i686-w64-mingw32-static/lib' > Thread model: posix > gcc version 4.9.1 (i686-posix-dwarf-rev0, Built by MinGW-W64 project) > > So there right at the end is the "offending" path, some script that should extract the -L paths, is bringing the ' character in, at the end of the line. > > I am not sure if it is the libtool's configure scripts, but somewhere in the configure scripts, the ' (single quote character) should not be part of the library path. I think this is a bug caused by libtools desire to dig out "predeps" and "postdeps" in order to then be able to link with -nostdlib. Libtool tries to find out the pre- and postdeps by linking a shared library with -v and analyzing the output. I suspect that the -v output matches what you quoted above (the -### output), and if that's the case, the -v output analyzer code will fail. Basically, libtool looks for all -R, -L and -l options in all lines which do not start with "Configured with:". Your MinGW-W64 compiler seems to have some extra lines starting with CFLAGS, CXXFLAGS and CPPFLAGS which should also be excluded from the hunt. I don't know if that is something the MinGW-W64 team can change, or if it is some property of newer GCC, but if my analysis is correct, many projects are b0rked. I have no time to look further, sorry... Cheers, Peter
bug-libtool <at> gnu.org:bug#18947; Package libtool.
(Wed, 05 Nov 2014 10:23:02 GMT) Full text and rfc822 format available.Message #11 received at 18947 <at> debbugs.gnu.org (full text, mbox):
From: Peter Rosin <peda <at> lysator.liu.se> To: Theuns Heydenrych <theunsheydenrych <at> gmail.com> Cc: 18947 <at> debbugs.gnu.org Subject: Re: bug#18947: unexpected EOF while looking for matching Date: Wed, 05 Nov 2014 11:22:49 +0100
On 2014-11-05 11:08, Theuns Heydenrych wrote: > Thanks for the reply Peter. > > I have successfully build other projects with the same compiler, and also used configure to generate the Makefiles. > One difference i found between the projects is the version of libtool, by executing libtool --version i get for the GEOS project 2.2.6b and for the other projects 2.4 > So maybe its the older version? Maybe. As I said, I have no more time to dig around. > How can i replace the libtool in GEOS, because it looks like its generated during the configuration process? > > Regards Please keep the bug-report in the replies. I have added it back. Your question is project specific. Usually, autoreconf will do the trick. Cheers, Peter
bug-libtool <at> gnu.org:bug#18947; Package libtool.
(Thu, 13 Nov 2014 16:09:02 GMT) Full text and rfc822 format available.Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Josef Reidinger <jreidinger <at> suse.cz> To: peda <at> lysator.liu.se, bug-libtool <at> gnu.org Subject: bug#18947: unexpected EOF while looking for matching + patch Date: Thu, 13 Nov 2014 13:09:13 +0100
Hi libtool developers, we also face this issue in opensuse with new version of libtool (2.4.3). I debug a problem and it appear that problem is that we have in automake.am ACLOCAL_AMFLAGS = -I . -I `if test -d ./build-tools; then echo ./build-tools; else pkg-config --print-errors --variable=datadir yast2-devtools; fi`/aclocal This cause double backticks in http://git.savannah.gnu.org/cgit/libtool.git/tree/libtoolize.in#n1400 To fix it, I verify that it helps to replace *,-I*) '$r'=`expr x$_G_arg : '\''x-I\(.*\)$'\''`; break ;; with *,-I*) '$r'=$(expr x$_G_arg : '\''x-I\(.*\)$'\''); break ;; as ```` is problem, but $($()) is not problem or $(``) which is result if we do not modify Makefile.am. I hope it helps. If you have any question please keep me in CC as I am not subscribed. Thanks Josef
bug-libtool <at> gnu.org:bug#18947; Package libtool.
(Thu, 13 Nov 2014 21:27:02 GMT) Full text and rfc822 format available.Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):
From: "Gary V. Vaughan" <gary <at> vaughan.pe> To: bug-libtool <at> gnu.org Subject: Re: bug#18947: unexpected EOF while looking for matching + patch Date: Thu, 13 Nov 2014 21:25:56 +0000
[resend to bug-Libtool for anyone else curious about this issue] Hi Josef, Thanks for the report. > On Nov 13, 2014, at 12:09 PM, Josef Reidinger <jreidinger <at> suse.cz> wrote: > > Hi libtool developers, > we also face this issue in opensuse with new version of libtool (2.4.3). > > I debug a problem and it appear that problem is that we have in > automake.am > ACLOCAL_AMFLAGS = -I . -I `if test -d ./build-tools; then > echo ./build-tools; else pkg-config --print-errors --variable=datadir > yast2-devtools; fi`/aclocal > > This cause double backticks in > http://git.savannah.gnu.org/cgit/libtool.git/tree/libtoolize.in#n1400 > > To fix it, I verify that it helps to replace > *,-I*) '$r'=`expr x$_G_arg : '\''x-I\(.*\)$'\''`; break ;; > with > *,-I*) '$r'=$(expr x$_G_arg : '\''x-I\(.*\)$'\''); break ;; > > as ```` is problem, but $($()) is not problem or $(``) which is result > if we do not modify Makefile.am. Except that, as described in the Shellology section of the Autoconf manual, $() is not portable to modern Solaris or Irix, so we are stuck with backticks in Libtoolize which needs to run on those architectures. That aside, I'm not at all convinced that multi-line backtick expressions in make macro expansions are well supported in any case. If your project does not care about portability beyond GNU/Linux, you could use $() in your ACLOCAL_AMFLAGS. Or if you do need portability, you could either use a GNU make $(shell ...) extension to run the test in advance, or at configure time in configure.ac using AC_SUBST to inject the result into Makefile. You might even find that all the make implementations you target provide immediate macro assignment with ::= or != ; again to avoid adding backticks to your ACLOCAL_AMFLAGS. HTH, -- Gary V. Vaughan (gary AT gnu DOT org)
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.