I get /bin/sh: -c: line 1: syntax error: unexpected end of file for the if statement in the makefile below — what's wrong? (My prompt is /tmp >.)
/tmp > make test
set -e
if [[ -f /tmp/device ]] ; then
/bin/sh: -c: line 1: syntax error: unexpected end of file
make: *** [test] Error 2
/tmp > cat Makefile
.ONESHELL:
test:
set -e
if [[ -f /tmp/device ]] ; then
echo 'Do something'
fi
I am using GNU Make 3.81.
Using GNU Make 3.81, the .ONESHELL feature is demonstrably not supported — you showed that, and I showed that. I tested on Mac OS X 10.11.5, with the supplied /usr/bin/make as GNU Make 3.81. I demonstrated to my satisfaction by adding strategically placed echo PID=$$$$ lines before set -e, after it, and so on, and observed different PID values. GNU Make version 3.81 is from 2006 (there was also version 3.82 from 2010, before version 4.x was released, starting with 4.0 in 2013).
The current version of GNU Make is 4.2.1 (June 2016). That version does support the feature; your script works as expected when using a sufficiently recent version of GNU Make. It is a feature that has been around for a while — you probably don't have to upgrade to the latest to get the support, but why would you go with a down-version if you're going to upgrade anyway.
If you wish to use the .ONSHELL: feature, you'll have to ensure you are using a new enough version of GNU Make (newer than version 3.81). If that's not feasible, don't use the feature.
Reading the NEWS file from 4.2.1, it is clear that ONESHELL was added to GNU Make version 3.82:
Version 3.82 (28 Jul 2010)
…
* New special target: .ONESHELL instructs make to invoke a single instance
of the shell and provide it with the entire recipe, regardless of how many
lines it contains. As a special feature to allow more straightforward
conversion of makefiles to use .ONESHELL, any recipe line control
characters ('#', '+', or '-') will be removed from the second and
subsequent recipe lines. This happens _only_ if the SHELL value is deemed
to be a standard POSIX-style shell. If not, then no interior line control
characters are removed (as they may be part of the scripting language used
with the alternate SHELL).
Related
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'm building mono on an android device and getting an error when the build runs ./doltlibtool
make[4]: Entering directory `/bld/mono/mono-4.0.0/eglib/src'
CC libeglib_la-garray.lo
../doltlibtool: line 4: syntax error: unexpected "("
Here is line 4 of doltlibtool:
1 #!/bin/bash
2 top_builddir_slash="${0%%doltlibtool}"
3 : ${top_builddir_slash:=./}
4 args=()
5 modeok=false
6 tagok=false
From what I can tell, the problem is due to the fact that I'm not using bash. Is there any way to fix this without building and using bash?
CORRECTION
I am using bash...but the busybox version of bash, which isn't really bash and so does not support arrays.
From the mono-devel mailing list, to which I posted the question:
Is it possible to build mono without bash?
It is unlikely.
Your best bet is to cross compile.
Shells that do not handle arrays (like the default Android shell or the default shell in KBOX...which is a busybox version of bash) cannot be used when compiling mono 4.0.0. Specifically the line
args=()
will throw an error.
I ended up downloading the bash source and building it before trying to build mono
I have encountered errors on running the conditional assignment operator in a Makefile in Solaris 11.1. However I encounter no errors on running the same Makefile in Ubuntu.
version ?= 6.1
all:
echo $(version)
Note: Before the echo, there is a tab before the echo in the original code. Using four spaces here just for convenience of editing.
Error encountered in Solaris 11.1:
make: Fatal error in reader: Makefile, line 1: Badly formed macro assignment
However, there are no such errors on Ubuntu.
Better you use gmake because many Makefiles use Gnu-specific features. Solaris make might be using slightly different syntax. You can read the Solaris makefile manual; you will find that there is no ?= operator in it. Hence you are getting that error.
?= is a feature added by GNU make, which is the default version of make on Ubuntu, but on Solaris is installed as gmake or /usr/gnu/bin/make. ?= is not supported by the native make command on Solaris, which is installed as /usr/ccs/bin/make on older releases, /usr/bin/make on Solaris 11 and later.
If you need to use the GNU extensions in your makefiles, make sure you run the GNU make, not the Solaris make.
git-slave documentation only has the following not-so-helpful comment regarding installation on Windows:
* Limited windows support
Multiple users have been successful in using gitslave with Windows.
This is "supported" only in the sense that people have reported it to
work and we accept bugfixes, not that you can `make` install or check,
or that it is QAed on this platform prior to release."
When I try to download and run 'nmake install' I get the equally cryptic error:
makefile(2) : fatal error U1001: syntax error : illegal character '{' in macro
Stop.
Does anyone have any experience with this and can point me in the right direction?
The Makefile for git-slave has only been used with GNU Make - as it is a rather simple makefile, there is no reason it shouldn't work with Microsoft nmake as well, except for "gratuitous" use of Make extensions that are not supported by Microsoft nmake. ( How similar/different are gnu make, microsoft nmake and posix standard make? has a good summary of the differences).
On lines 2-4 of gitslave/Makefile, if you replace ${prefix} with $(prefix) and ${mandir} with $(mandir) [essentially replace braces with parentheses (brackets)] nmake should no longer choke on Makefile. However, unless you have installed a bunch of POSIX utilities or something that allows commands like mkdir -p, rm -f, and sed to work, fixing the nmake incompatibility would only allow (at best) make testcheck to work.
None of the gitslave developers have regular(?) access to Windows development machines, so like the documentation says: "we accept bugfixes, [but do] not [claim] that you can make install or check,
or that it is QAed on this platform."
I imagine that the other people who have used git-slave on windows just made sure that Perl and gitslave and any POSIX utilities that gitslave depends on (e.g. grep and rm) are installed somewhere in PATH.
On Windows you can download and install the free unix tool kit including all necessary programs:
https://sourceforge.net/projects/unxutils/
You also need a perl tool kit because "pod2man" is used in the make process.
Furthermore the script "gits" is a perl script which runs under *ix because of the "she-bang" instruction in the first line ("#!/usr/bin/perl") - this doesn't work on Windows.
I created a small wrapper batch scripts that uses my perl to start the original script:
gits.bat:
perl gits %*
Hope this helps.
I've got this Makefile that is presenting some odd behaviour:
$ javac -d Classes -sourcepath .. -classpath `for x in \`ls Classes/jars/*\`; do echo -n $x:; done` PCA/PCAClassifier.java
compiles the java just fine. But for somereason when I call
make PCA
I get:
Compiling PCAClassifier
javac -d Classes -sourcepath .. -classpath `for x in \`ls Classes/jars/*\`; do echo -n $x:; done` PCA/PCAClassifier.java
javac: invalid flag: Classes/jars/Jama.jar:
Usage: javac <options> <source files>
use -help for a list of possible options
make: * [Classes/RobotSuite/PCA/PCAClassifier.class] Error 2
I am so confused. Anyone have a solution?
Make version info:
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-darwin10.0
Background: Working on a group project. I'm running Ubuntu, my partner is running Mac OS X. For whatever reason, This makefile works just fine on my computer, but not on his. Even though the command works in his BASh terminal, somehow Make isn't sending it correctly.
You have given us almost no information to go on. Nonetheless, you are in luck!
On Mac OS X, bash has been built with --enable-strict-posix-default and hence the xpg_echo shell option defaults to being on in POSIX mode. POSIX mode is on when the shell has been invoked as /bin/sh, as it has been when it is invoked by Make, unless you instruct it otherwise by setting the $(SHELL) make variable (which you probably shouldn't).
This is the difference between Linux and Mac OS that is killing your makefile. When xpg_echo is on, the shell's built-in echo treats -n as just another argument to be printed (and hence also prints a newline). So the single classpath argument that you're trying to construct ends up as a bunch of separate arguments (half of which are "-n") and javac gets confused.
(This doesn't happen on the command line, even on Mac OS X, because then the shell has been invoked as /bin/bash, so it's not in POSIX mode and xpg_echo is off.)
So you have a number of options for fixing this:
Use /bin/echo -n in your shell snippet; unlike the built-in one, the real echo command these days mostly always understands -n;
Construct the classpath argument in a less roundabout way than your shell for loop; for example
... -classpath `ls Classes/jars/* | tr '\n' :` ...
or, if you are already assuming GNU Make, using make wildcards and functions instead of a shell snippet;
Have your colleague add shopt -u xpg_echo to an appropriate bash startup file on their machine (however this will just lead to future confusion when your next Mac OS-using colleague comes along and you've all long since forgotten how you fixed this this time).
Finally, a general note about debugging makefiles: when a javac ... command in a makefile recipe is giving incomprehensible error messages, change it to echo javac ... instead. Then you'll be able to see exactly how it's being invoked -- which, as seen here, may not be what you intended.