I have recently been experiencing problems with the configure step of two open source projects, GNU GetText and W3M.
The configure step fails at the same place for both projects.
checking for ld used by GCC...
System details:
- Operating System: Windows 10 Pro 64-bit
- MSYS2
- gcc --version: gcc.exe (Rev4, Built by MSYS2 project) 5.2.0
- gcc -dumpmachine: x86_64-w64-mingw32
- bash --version: GNU bash, version 4.3.42(2)-release (x86_64-pc-msys)
Any ideas on what might be causing this?
The following is the code that configure uses to perform this test.
# Check if gcc -print-prog-name=ld gives a path.
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for ld used by GCC" >&5
$as_echo_n "checking for ld used by GCC... " >&6; }
case $host in
*-*-mingw*)
# gcc leaves a trailing carriage return which upsets mingw
ac_prog=`($CC -print-prog-name=ld) 2>&5 | tr -d '\015'` ;;
*)
ac_prog=`($CC -print-prog-name=ld) 2>&5` ;;
esac
case $ac_prog in
# Accept absolute paths.
[\\/]* | [A-Za-z]:[\\/]*)
re_direlt='/[^/][^/]*/\.\./'
# Canonicalize the path of ld
ac_prog=`echo $ac_prog| sed 's%\\\\%/%g'`
while echo $ac_prog | grep "$re_direlt" > /dev/null 2>&1; do
ac_prog=`echo $ac_prog| sed "s%$re_direlt%/%"`
done
test -z "$LD" && LD="$ac_prog"
;;
"")
# If it fails, then pretend we aren't using GCC.
ac_prog=ld
;;
*)
# If it is relative, then search for the first ld in PATH.
with_gnu_ld=unknown
;;
esac
I added debugging code to determine exactly where the problem is occurring. It is happening in the while loop in which grep is called.
