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.
I do not know why, but I found that the following packages interfered with configure.
mingw-w64-i686-grep
mingw-w64-i686-sed
mingw-w64-x86_64-grep
mingw-w64-x86_64-sed
These packages appear to be obsolete. When I removed them configure worked.
Related
The man page of ld (which I think is used by gfortran in the background) says:
-lnamespec: ...If namespec is of the form :filename, ld will search the library path
for a file called filename...
Compiling the trivial Fortran program test.f:
END
with gfortran -l:libquadmath.a test.f does not throw an error on some of my machines (CENTOS 7 with GNU Fortran (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)).
However, for f in $(echo $LIBRARY_PATH | sed 's/:/ /g');do find $f -name libquadmath.a; done gives zero results, indicating that there is no file called libquadmath.a.
Additonally, the output of ld -l:libquadmath.a is ld: cannot find -l:libquadmath.a.
What is going on here?
I'm trying to reproduce a situation which happens only in some machines. To reproduce it, I create a directory with 2000 files:
mkdir /tmp/test
cd /tmp/test
for f in $(seq 1 2000); do touch $f.txt; done
Then I use the following Makefile (simplified from the real use case):
FILES:=$(shell find . -name '*.txt')
%.done: %.txt
#echo "done $#"
toolong:
#$(foreach file,$(sort $(FILES)), \
if $(MAKE) $(file); \
then echo "did $(file)" >> $#; \
else echo "failed $(file)" >> $#; fi; )
Running make produces, unsurprisingly, an error:
make: execvp: /bin/sh: Argument list too long
This question presents a solution which does work. However, I need to understand exactly why this error does not happen on my colleagues' computers. I tried the following things:
Increasing stack limit (ulimit -s gives the same result on both machines, 8192, and increasing it does not change anything);
Checking getconf ARG_MAX (2097152 in both machines);
Checking MAX_ARG_STRLEN (131072 in both machines);
Using a different shell (zsh is being used in both machines; I also tried bash, dash and sh, via export SHELL=<shell> make, and also by replacing the symlink /bin/sh -> /bin/bash with a link to dash).
Finally, I tried recompiling Make from source, and realized that, even when I compile the same version of Make (4.1) in my Ubuntu test machine, I get the same behavior as I had in my Fedora, that is, the error "argument list too long".
make --version only shows a single difference between them:
Version from the apt package:
GNU Make 4.1
Built for x86_64-pc-linux-gnu
Version compiled from source (./configure && make):
GNU Make 4.1
Built for x86_64-unknown-linux-gnu
I even tried compiling make-dfsg, which results in an identical make --version, but the result is the same as with my other manually-compiled make.
By increasing the number of files on Ubuntu, I managed to identify that the actual limits in the size of the generated command line are:
Fedora or Arch Linux (both with Make 4.2.1), or Ubuntu with manually-compiled Make 4.1: 128 KB (~1200 files);
Debian Sid or Ubuntu, both with Make 4.1 installed from apt package: 2 MB (~19300 files).
I'd really like to understand (1) why this difference exists, and (2) how could I compile Make to obtain the higher limit, so that I can have the exact same behavior on both machines.
Your recipe expands as a one-line shell compound command (because of the line ending backslashes). And this line is probably way too long. Did you check what it looks like (the shell compound command) on all machines? I suggest that you wrap it in $(info...):
toolong:
#$(info $(foreach file,$(sort $(FILES)), \
if $(MAKE) $(file); \
then echo "did $(file)" >> $#; \
else echo "failed $(file)" >> $#; fi; ))
and see if the output is the same on your machine and on the others. If, for any reason, yours is longer, it could be the explanation. Else it must be a OS difference...
Note: you could have one rule per target, instead of one single rule with a huge recipe for all.
Note: your recipe (independently from its fantastic length) does nothing useful. As the files already exist and do not have pre-requisites, all your sub-make calls will just tell you that the files are up-to-date.
can anybody help me why these packages showed unavailable even they are installed?
I am trying to install NS2.3.5 on windows 10 64bit using cygwin.
as known, the install script of ns will check for required package in cygwin which are installed:
packages_base="gcc gcc-g++ gawk tar gzip make patch perl w32api"
packages_xorg="xorg-server xinit libX11-devel libXmu-devel"
you may notice that I modified the script to check for gcc instead of gcc4 and gcc-g++ instead of gcc4-g++, since the gcc4 is obsolete.
I also run the command gcc -dumpversion and I got the version 4.9.3
the basic command to check the package is:
cygcheck -c gcc
and the expected output is:
Package version Status
gcc-g++ 4.9.3-1 OK
however, the script that checks the packages failed to find gcc and w32api even they are installed. all other packages including gcc-g++ were checked successfully and get the exact version.
Okay,
Tried at my end ( as I already have a cygwin package installed ).
To me, this is more of an issue of "cygcheck" utility than anything else.
At my end too "cygcheck" failed to report details in proper for "gcc", with command "cygcheck -c gcc | grep gcc"
I am suggesting a trick here to over come this, but its just a trick.
In script "install" from "ns-2.35", find a function "test_packages" and change it something like below
test_packages() {
for i in $#; do
echo -n "Checking for ${i}... ";
cygcheck -c ${i} | grep ${i} >/dev/null 2>&1;^M
if [ "$?" -eq "0" ]; then
echo "ok";
else^M
cygcheck -l | grep ${i} >/dev/null 2>&1;
if [ "$?" -eq "0" ]; then
echo "ok";
else^M
echo "NO!";^M
echo "";
echo "Package ${i} is not present on your system.";
echo "";
echo "Please install it using Cygwin's setup.exe";
echo "before trying to install the ns-2 distribution.";
fi;
test_proceed;
fi;
done;
}
Basically rechecking again with "cygcheck -l" after first fail.
This passed the test but, I did not go further with installation.
Also there is a link which explains the installation os ns-2.35 on windows
which could be useful too.
http://www.slideshare.net/TBear76/ns235-installation-3395974
Please try out the 'Nov 2014 update', ns-allinone-2.35_gcc482.tar.gz
https://drive.google.com/file/d/0B7S255p3kFXNSGJCZ2YzUGJDVk0/view?usp=sharing
Can use all gcc/g++ versions 4.4.x .. 5.2.0
ns2
Is there a way to make gcc ignore an invalid option, instead of dying with "unrecongized option"? Reason is I want to use an option only available in later versions of gcc (-static-libstdc++), but it should also compile on older compilers. I could check for gcc version in the makefile but it is a bit ugly.
no, but you can set the flags based on the gcc version as follows:
version=`gcc --version | head -1 | cut -d ' ' -f3`
if [ `echo -e "$version\n4.6.1" | sort -V -C; echo $?` == 0 ]; then
flags = -static-libstdc++;
fi
gcc $flags ...
(Disclaimer: I'm not sure which version first uses static-libstdc++, 4.6.1 is just a guess).
John
You can run gcc and check if it accepts the flag:
STATIC_LIBCPP_FLAG := $(shell if gcc -static-libstdc++ --version 2>&1 | grep -q 'unrecognized option'; then true; else echo -static-libstdc++; fi)
CFLAGS += $(STATIC_LIBCPP_FLAG)
Is there a way to make gcc use the absolute path when printing errors found in files compiled in the current directory?
For instance the following does what I want when print errors:
g++ -I. -I../../.. /home/some/path/somefile.cpp
but I want to achieve the same with something like:
g++ -I. -I../../.. somefile.cpp
I want warnings and errors to be formatting something like:
/home/some/path/somefile.cpp:299:52: warning: some warning
There is no way to do this with gcc itself, but it's trivial with a wrapper script, installed as "gcc", "g++", etc in a directory before /usr/bin in your PATH:
#! /bin/sh
sourcefile="$1"; shift
case "$sourcefile" in
/*) ;;
*) sourcefile="$PWD/$sourcefile" ;;
esac
exec "/usr/bin/${0##*/}" "$sourcefile" "$#"
... provided that you always put the source file first in your compiler invocation (you'll have to tweak your Makefiles).