Bug 56412 - [4.8] "libtool: cygpath: command not found" for mingw32 host
Summary: [4.8] "libtool: cygpath: command not found" for mingw32 host
Status: SUSPENDED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.8.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: build
Depends on:
Blocks:
 
Reported: 2013-02-20 19:35 UTC by Daniel Starke
Modified: 2021-03-24 23:04 UTC (History)
3 users (show)

See Also:
Host: mingw32
Target: mingw32
Build: mingw32
Known to work:
Known to fail: 4.8.0
Last reconfirmed: 2013-09-10 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Starke 2013-02-20 19:35:19 UTC
Configuring gcc r196092 for mingw32 on ming32 host without bootstrapping it failed at lto-plugin for libtool with the following configuration:

../gcc-4.8/configure --enable-languages=c --disable-sjlj-exceptions --disable-nls --disable-shared --enable-static --enable-fully-dynamic-string --enable-libgomp --enable-lto --with-dwarf2 --disable-win32-registry --enable-version-specific-runtime-libs --disable-bootstrap --build=mingw32 --enable-abi=32 --enable-checking=release --with-mpfr=/mingw --with-gmp=/mingw --with-mpc=/mingw --prefix=/mingw

The error message for "make all-gcc" is:
make[2]: Entering directory `/new-gcc/bin/lto-plugin'
/bin/sh ./libtool --tag=CC --tag=disable-static  --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../gcc-4.8/lto-plugin  -I../../gcc-4.8/lto-plugin/../include -DHAVE_CONFIG_H -DPTW32_STATIC_LIB -Wall -g -O2 -D__USE_MINGW_ACCESS -c -o lto-plugin.lo ../../gcc-4.8/lto-plugin/lto-plugin.c
./libtool: line 2008: cygpath: command not found
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../gcc-4.8/lto-plugin -I../../gcc-4.8/lto-plugin/../include -DHAVE_CONFIG_H -DPTW32_STATIC_LIB -Wall -g -O2 -D__USE_MINGW_ACCESS -c ""  -DDLL_EXPORT -DPIC -o .libs/lto-plugin.o
gcc.exe: : No such file or directory
gcc.exe: no input files

with the following values assigned:
srcfile: ../../gcc-4.8/lto-plugin/lto-plugin.c
fix_srcfile_path: `cygpath -w "$srcfile"`

The problem is probably within libtool.m4 where fix_srcfile_path is assigned with cygpath even for mingw host at line 4790 with:
_LT_TAGVAR(fix_srcfile_path, $1)='`cygpath -w "$srcfile"`'
Comment 1 Daniel Starke 2013-02-20 20:15:58 UTC
A patch of lto-plugin/configure could solve this issue for now if the patch of libtool.m4 was too extensive for stage4.

--- gcc-4.8.0-r196092/lto-plugin/configure	2013-02-15 22:11:56 +0000
+++ gcc-4.8.0-patched/lto-plugin/configure	2013-02-20 20:05:25 +0000
@@ -8734,7 +8734,7 @@
       old_archive_from_new_cmds='true'
       # FIXME: Should let the user specify the lib program.
       old_archive_cmds='lib -OUT:$oldlib$oldobjs$old_deplibs'
-      fix_srcfile_path='`cygpath -w "$srcfile"`'
+      fix_srcfile_path=''
       enable_shared_with_static_runtimes=yes
       ;;
Comment 2 Daniel Starke 2013-02-20 20:23:32 UTC
Sorry, here is the correct patch proposed.

--- gcc-4.8.0-r196092/lto-plugin/configure	2013-02-15 22:11:56 +0000
+++ gcc-4.8.0-patch/lto-plugin/configure	2013-02-20 20:19:57 +0000
@@ -8734,7 +8734,14 @@
       old_archive_from_new_cmds='true'
       # FIXME: Should let the user specify the lib program.
       old_archive_cmds='lib -OUT:$oldlib$oldobjs$old_deplibs'
-      fix_srcfile_path='`cygpath -w "$srcfile"`'
+      case $host_os in
+        cygwin*)
+          fix_srcfile_path='`cygpath -w "$srcfile"`'
+          ;;
+        *)
+          fix_srcfile_path=''
+          ;;
+      esac
       enable_shared_with_static_runtimes=yes
       ;;
Comment 3 Andrew Pinski 2013-02-20 22:00:41 UTC
(In reply to comment #2)
> Sorry, here is the correct patch proposed.

Is there a patch to configure.ac as configure is generated from configure.ac.  If the problem is in libtool.m4, then propose a patch to the libtool list instead and we will then port it from there and regenerate the files.
Comment 4 nightstrike 2013-04-19 02:55:57 UTC
I'm seeing the same thing occur in building binutils bfd.  Did anything make its way to libtool upstream?
Comment 5 nightstrike 2013-04-19 17:46:37 UTC
CYGPATH_W gets set correctly, but libtool seems to ignore it.
Comment 6 Kai Tietz 2013-09-10 10:09:47 UTC
Yes, this is a libtool bug.  If thing is solved on libtool, then we can continue on that.  So long I set bug in status waiting
Comment 7 Eric Gallager 2017-08-02 12:11:02 UTC
(In reply to Kai Tietz from comment #6)
> Yes, this is a libtool bug.  If thing is solved on libtool, then we can
> continue on that.  So long I set bug in status waiting

If there's an upstream URL for the libtool bug report, we can set it to RESOLVED MOVED instead of WAITING.
Comment 8 Eric Gallager 2017-11-02 10:52:44 UTC
(In reply to Eric Gallager from comment #7)
> (In reply to Kai Tietz from comment #6)
> > Yes, this is a libtool bug.  If thing is solved on libtool, then we can
> > continue on that.  So long I set bug in status waiting
> 
> If there's an upstream URL for the libtool bug report, we can set it to
> RESOLVED MOVED instead of WAITING.

changing it to SUSPENDED instead for now since no one from gcc is working on it, but I still want to move it out of the WAITING queue and don't want to close it either