Example
I have a gmake 4.0 from a MinGW installation, that shows no helping error messages.
For example I have this makefile:
# test.mk
all: somefile.c
Since I have no file named somefile.c present, it fails, but without any helpful message:
$ gmake -f test.mk
gmake: ***. Stop.
When I add the --debug flag I get some hints:
$ gmake -f test.mk --debug
GNU Make 4.0
Built for x86_64-w64-mingw32
Copyright (C) 1988-2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Updating goal targets....
File 'all' does not exist.
File 'somefile.c' does not exist.
Must remake target 'somefile.c'.
gmake: ***. Stop.
Expectation
For an older gmake 3.80 from another tool set, I get a helping message:
$ gmake-old -f test.mk
gmake-old: *** No rule to make target `somefile.c', needed by `all'. Stop.
Environment
I am running these command within a git-bash under Windows. I am getting a similar message, when calling gmake within windows cmd.
Question
Are there options for gmake or environment variables that I might set in order to get gmake 4.0 to provide helping messages like No rule to make target 'somefile.c', needed by 'all'?
Related
gmake doesn't seem to have a value for $(INSTALL). is this supposed to be defined by the user?
$(CC) works fine. most sample Makefiles i went over didn't have an explicit definition of $(INSTALL)...
if it has to be defined by user, what are best practices (other than aliasing _PROGRAM and _DATA)? why prefer install over cp?
Makefile
helloworld:
echo 'hello, world' >helloworld
install:
$(INSTALL) ${HOME}/ helloworld
log
$ make helloworld
$ make install
/home/<username>/ helloworld
make: /home/kevins/: Permission denied
make: *** [Makefile:5: install] Error 127
version info
GNU Make 4.3
Built for x86_64-pc-linux-gnu
There is no default value defined for INSTALL. You can see all the default rules and variables by running:
make -p -f/dev/null
Whether install or cp is a better fit depends entirely on your use-case. install does a lot more than cp. But, you can run other commands in addition to cp to take care of those things, and install is not available on every system. So, it's what's best for you.
I'm trying to compile glibc (CORRECTION: 2.34, not 2.3.4) on a RedHat system. I get this error while trying to run configure:
*** These critical programs are missing or too old: make compiler
*** Check the INSTALL file for required versions.
I installed the latest version of 'make':
> make --version
GNU Make 4.3
However, even with the latest version of 'make', I still get the same error. What is causing the problem?
glibc's configure prefers gnumake and gmake over make if they are available on the PATH command search path. Chances is that you have gmake binary that is version 3.81.
I think you should make with gcc version 6.5.0,
ct-ng may help you to build glibc. ct-ng http://crosstool-ng.github.io/docs/
1. ct-ng menuconfig
2. ct-ng build
You can choose gcc version at step 1.
As an reminder, glibc-2.34 remove some libs and no longer create like *-2.33.so under dir sysroot/lib/ . link:https://lwn.net/Articles/864920/
I ran into this issue as well and noticed that the config.txt was looking for gmake and found it in /usr/bin/gmake which was strange.
Listing shows that there is a symlink to make.
ls -l /usr/bin/gmake
lrwxrwxrwx. 1 root root 4 Jun 11 18:18 /usr/bin/gmake -> make
I installed make 4.3 in a custom path AND ensured that it was on $PATH but I was still getting the same error. Making a symlink to my custom installed version of make resolved the problem.
ln -s <custom path>/bin/make <custom path>/bin/gmake
Solved this by setting the MAKE variable. When looking in the configure script, it checks against "if test -n "$MAKE"; then", i.e.
MAKE=//make
export MAKE
I found a difference of behaviour between GNU Make 4.1 and 3.81 and wonder whether my code is not POSIX compliant which 4 is enforcing more strictly, or whether something else is going on.
I distilled the failure case to this Makefile
.POSIX:
all: test-b
test-a:
cat a.txt b.txt c.txt >results.txt
test-b:
cat {a,b,c}.txt >results.txt
Assuming those files have been created with cat {a,b,c}.txt, target test-a always works, yet test-b works on Make 3.81 but fails on 4.1.
The output for 3.81:
$ make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i386-apple-darwin11.3.0
$ make
cat {a,b,c}.txt >results.txt
$ echo $?
0
The output for 4.1:
$ make --version
GNU Make 4.1
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ make
cat {a,b,c}.txt >results.txt
cat: {a,b,c}.txt: No such file or directory
Makefile:9: recipe for target 'test-b' failed
make: *** [test-b] Error 1
$ echo $?
2
It's possible the cat command is actually failing in 3.81 and it just isn't pointing it out, as later versions of GNU Make mention passing the -e flag to the shell when invoking target commands to make it more POSIX compliant, but I can't see how that command could be failing.
I assume the wildcards are handled solely by the shell, so I can't see how invoking the shell via a make target command should be any different.
Which is these behaviours are correct? If wildcards like that don't work in Makefiles, which other wildcards can I assume to work?
test-b still fails in 4.1 even if .POSIX: is removed from the file.
Recipes are sent to the shell. They are not interpreted by make. So your question is really, are curly-brace expansions supported by the shell?
That depends on which shell make uses. They are not supported by POSIX standard sh. They are supported by bash (and many other shells).
Make always invokes /bin/sh, regardless of what shell you personally use, unless you specifically set the make SHELL variable to something else. On some systems, /bin/sh is a symlink to /bin/bash so they are the same thing (bash runs in a "POSIX emulation" mode when invoked as /bin/sh but most bash features are still available). Other systems use different shells, such as dash, as /bin/sh which do not have extra bash features.
So, you can either (a) not have a portable makefile and assume /bin/sh is the same as /bin/bash, (b) set SHELL := /bin/bash in your makefile to force it to use bash always (but fail on systems that don't have bash installed), or (c) write your makefile recipes to use only POSIX sh features so it works regardless of which shell is used for /bin/sh.
I am running Arch Linux and trying to build a project in Qt however, Qt spits the following error:
/opt/cuda/include/crt/host_config.h:129: error: #error -- unsupported GNU version! gcc versions later than 7 are not supported!
I have already tried a suggestion from a previous Stack Overflow post found here:
CUDA incompatible with my gcc version
I did not use the exact command as my cuda is located in /opt/cuda/bin/gcc. I did the same command for g++. However, the terminal outputs that these files are already linked. I did confirm this by going to the actual file and looking at it's properties.
Can someone please suggest a solution to my issue?
I managed to do so usung this two lines, this will update the symbolic links of cuda to gcc7
ln -s /usr/bin/gcc-7 /usr/local/cuda/bin/gcc
ln -s /usr/bin/g++-7 /usr/local/cuda/bin/g++
The issue comes from cuda-10.0/targets/x86_64-linux/include/crt/host_config.h in the main CUDA-10 directory tree. The target for your architecture was placed in /opt.
Some posts recommend faking the inequality
if __GNUC__ > 7
to say
if __GNUC__ > 8
but that is a bad idea. Using
make 'NVCCFLAGS=-m64 -D__GNUC__=7' -k
is permissible in some trivial cases, but still fundamentally the same bad hack.
You probably have alternates on your system which has constructed symbolic links pointing to the version 8 gnu tool chain files. That's why you get an indication version 7 is already installed.
You can learn how to modify your alternates for just your developer users BUT NOT for root or any system admin accounts. You may want to remember how to switch back and forth between 7 and 8 so you only use 7 when actually needed, since many other things may be tested only with 8.
If that doesn't work for you, you can build gcc-7 from source. The preparatory system admin work includes a dnf install, a build from source, an install of 7.4 gnu compiler, and a set up of paths for CUDA development only. If you have gnu gcc and g++ version 8 installed with the appropriate standard libraries and it works, the version 7 compiler can be installed with relative ease.
Browse and find the nearest mirror listed on https://gcc.gnu.org/mirrors.html and then copy the link location for gcc-7.4.0.tar.xz and place it in the shell variable u like this example.
u="http://mirrors.concertpass.com/gcc/releases/gcc-7.4.0/gcc-7.4.0.tar.xz"
Then you can do the rest as commands.
sudo dnf install libmpc-devel
cd
mkdir -p scratch
cd scratch
wget -O - "$u" |tar Jxf -
cd gcc-7.4.0
mkdir build
cd build
../configure --prefix=/usr/local/gcc-7
make
sudo bash -c "cd \"`pwd`\"; make install"
Then you execute this in the shells and tools you develop with. Do NOT put this in the system login apparatus or in .bashrc or .bash_profile, for the same reason as above. Other things may be tested with version 8 only. Instead place them in your development environment where they belong.
LD_LIBRARY_PATH=/usr/local/gcc-7/lib64:$LD_LIBRARY_PATH
LD_LIBRARY_PATH=/usr/local/gcc-7/lib:$LD_LIBRARY_PATH
LD_LIBRARY_PATH=/usr/local/cuda-10.0/NsightCompute-1.0/host/linux-desktop-glibc_2_11_3-glx-x64/Plugins:$LD_LIBRARY_PATH
LD_LIBRARY_PATH=/usr/local/cuda-10.0/NsightCompute-1.0/target/linux-desktop-glibc_2_11_3-glx-x64:$LD_LIBRARY_PATH
LD_LIBRARY_PATH=/usr/local/cuda-10.0/targets/x86_64-linux/lib/stubs:$LD_LIBRARY_PATH
PATH=/usr/local/gcc-7/bin:$PATH
PATH=/usr/local/cuda-10.0/bin:$PATH
PATH=$HOME/big/cuda.samples/NVIDIA_CUDA-10.0_Samples/bin/x86_64/linux/release:$PATH
I am trying to compile Qt 4.7.3 on mignw32 using gcc 4.6.0.
I get the following error when running ./configure:
In file included from C:/work/qt-gcc-4.6.0/include/QtCore/private/qcore_unix_p.h:1:0,
from C:/work/qt-gcc-4.6.0/src/corelib/io/qfsfileengine_unix.cpp:45:
C:/work/qt-gcc-4.6.0/include/QtCore/private/../../../src/corelib/kernel/qcore_unix_p.h:59:3: error: #error "qcore_unix_p.h included on a non-Unix system"
The weird thing is that I am running Windows 7, and it is trying to include that.
Also in the Makefile it is using qfsfileengine_unix and qfsfileengine_iterator_unix instead of qfsfileengine_win and qfsfileengine_iterator_win.
If I change the Makefile to use the Windows' ones, I get the following error (the file does not exist):
In file included from C:/work/qt-gcc-4.6.0/include/QtCore/../../src/corelib/global/qglobal.h:62:0,
from C:/work/qt-gcc-4.6.0/include/QtCore/qglobal.h:1,
from C:/work/qt-gcc-4.6.0/mkspecs/win32-g++/qplatformdefs.h:53,
from C:/work/qt-gcc-4.6.0/src/corelib/io/qfsfileengine_win.cpp:43:
C:/work/qt-gcc-4.6.0/include/QtCore/qconfig.h:1:46: fatal error: ../../src/corelib/global/qconfig.h: No such file or directory
compilation terminated.
When compiling /qt/src/corelib/io/qfsfileengine_win.cpp
Suggestions?
Try ./configure --help
There is probably a flag for a ms-windows, x86 compilation.
It might be something like:
./configure --target-os=mingw32
Keep in mind -- the os parameter name might be different, and the selectable target values *might be different* -- with scripts from different authors -- some values you might encounter might be 'win32', 'win32-386', 'x86-windows32', etc.
See if
./configure --help
Won't give you a list...
You can also redirect its output to a file for easy reading in your favorite editor,
./configure --help > myconfighelp.txt
Good luck!