When I try to run "make all" on a makefile with some complexity I get this errors:
C:\BITCLOUD\BitCloud_PS_SAM3S_EK_1_10_0\BitCloud_PS_SAM3S_EK_1_10_0\Applications\ZAppSi\Dem o\SEDevice>make all
make -C makefiles/PC -f Makefile_PC_Gcc all APP_NAME=DemoSE
make[1]: Entering directory
'C:/BITCLOUD/BitCloud_PS_SAM3S_EK_1_10_0/BitCloud_PS_SAM3S_EK_1_10_0/Applications/ZAppSi/Demo/SEDevice/makefiles/PC'
A sintaxe do comando está incorrecta.
make[1]: *** [directories] Error 1
make[1]: Leaving directory
'C:/BITCLOUD/BitCloud_PS_SAM3S_EK_1_10_0/BitCloud_PS_SAM3S_EK_1_10_0/Applications/ZAppSi/Demo/SEDevice/makefiles/PC'
make: *** [all] Error 2
where the line
A sintaxe do comando está incorrecta.
translated to english means: "The syntax of the command is incorrect"
I already tried to change the project to different directories, check spaces in file names, using GNU make and also use MinGW make (mingw32-make) and the result is the same with both "make". I also checked for all files that are included in the makefile and they correspond.
Im not an expert in makefiles, so Im asking for help.
What is the main problem that occurs when make throws this type of error?
It is likely not make that throws this error, but a command executed by make returns with a nonzero exit status, in this case with status 1 (due to Error 1); then the top level make stops with Error 2. Note that make by default stops as soon as a command fails.
Since the output doesn't show what command was executed, there is no way to tell what went wrong exactly.
EDIT: from the GNU make manual:
-d Print debugging information in addition to normal processing.
The debugging information says which files are being considered
for remaking, which file-times are being compared and with what
results, which files actually need to be remade, which implicit
rules are considered and which are applied---everything inter‐
esting about how make decides what to do.
--debug[=FLAGS]
Print debugging information in addition to normal processing.
If the FLAGS are omitted, then the behavior is the same as if -d
was specified. FLAGS may be a for all debugging output (same as
using -d), b for basic debugging, v for more verbose basic
debugging, i for showing implicit rules, j for details on invo‐
cation of commands, and m for debugging while remaking make‐
files.
I suggest running make --debug=j to see the commands.
Related
So I'm trying to install the Homotopy Type Theory library for Coq from github following these instructions. Running the command etc/install_coq.sh sets it off messing with a bunch of files before it hits an error as so:
$ make clean
make: *** No rule to make target `clean'. Stop.
Apparently there's one or more bugs present within Makefile.am, and according to what I've read while googling the issue it's likely related to improper whitespace. Running make clean myself yields the same thing:
make: *** No rule to make target `clean'. Stop.
Meanwhile running make -f Makefile.am clean yields:
Makefile.am:4: *** missing separator. Stop.
Lines 4-6 in the file are simply:
if make_hoqide
bin_SCRIPTS += hoqide
endif
What's wrong with that that's causing the problem?
Makefile.am is generally paired with Makefile.in; these need to be processed with automake or configure before you get a usable real Makefile.
If you've got a script "autogen.sh" in your top-level source directory, run that
first, then configure:
$ ./autogen.sh
$ ./configure
$ make
This is, in fact, step 3 of the instructions that you linked to. Perhaps the install_coq.sh script isn't finding all of the dependencies that you need?
From the docs:
To avoid this you can use the --output-sync (-O) option. This
option instructs make to save the output from the commands it invokes
and print it all once the commands are completed. Additionally, if
there are multiple recursive make invocations running in parallel,
they will communicate so that only one of them is generating output at a
time.
So, given a makefile:
# A "recipe" that will always fail.
all::
#foo bar baz
And running, we get:
# A "non-synchronized" run
$ make
make: foo: Command not found
makefile:3: recipe for target 'all' failed
make: *** [all] Error 127
# Synchronize!
$ make --output-sync
makefile:3: recipe for target 'all' failed
make: *** [all] Error 127
Can you see a difference between the 2 runs?
Well, they both fail!
But, in the first run, Make let's us know why it failed, as it "let-through" the failing error(s) from the recipe:
make: foo: Command not found
But, for the second run, all we get, is:
makefile:3: recipe for target 'all' failed
make: *** [all] Error 127
But why? Why did it fail..Were there any debugging errors - from the recipe - that it failed? Sure there were! As evident by the 1st run! So, Why is Make so quick to hide them?
Now - that Make is hiding the error message - all we can do here, is: to guess!
We are very lucky here, because we know that "foo..." is an invalid command, so probably, somewhere, behind the curtains, this command was not acceptable, for this very reason.
But, consider this:
Imagine, when you have some typo in a command?
Now, imagine a typo in complex makefile!
Now, imagine the typo in a complex makefile run recursively!
Now, imagine all that in a makefile that runs for long period of times, outputting considerable amount of output!
How, then, could it be still justified for Make to "hide" some debugging errors, and show others?
(Versions note: All versions supporting synchronization, hence: 4.0 and up).
I had opened a bug report on this the other day here https://savannah.gnu.org/bugs/index.php?47365
It should be fixed now http://git.savannah.gnu.org/cgit/make.git/commit/?id=14b2d7effb0afd75dfd1ed2534e331784f7d2977
I guess you can build the latest version from source or wait until they make another official release. I'll be building from source as I need this fix ASAP :)
I am trying to build mysql-workbench from source (for a 32 bit Fedora 22).
After many attempts and fixes, I got the following error:
plugins/migration/CMakeFiles/wbcopytables-bin.dir/build.make:163: *** target pattern contains no '%'. Stop.
Line build.make:163 is
plugins/migration/wbcopytables-bin: /bin/sh:\ /root/linux-res-6.3/usr/bin/iodbc-config:\ No\ such\ file\ or\ directory
Do you see any typo, with respect to Make and its syntax of Static Pattern Rules? Or am I on a complete wrong track?
Also, is there a way to check corrections of line 163 without to build the entire .rpm (which takes almost 1h)?
m.
As there is not enough information given in the question, this answer is given on the grounds that it is easy to reproduce the error message in a way that appears to emulate what line 168 has in it.
Given a Makefile that contains a construct something this:
this: that: somethingelse:
echo the stuff
The error message in the question results:
$ make this
Makefile:1: *** target pattern contains no `%'. Stop
And further, since the line 168:
plugins/migration/wbcopytables-bin: /bin/sh:\ /root/linux-res-6.3/usr/bin/iodbc-config:\ No\ such\ file\ or\ directory
looks an awful lot like:
this: that: somethingelse:
build.make rather seems to have been generated by some script that encountered an error and output:
/bin/sh: /root/linux-res-6.3/usr/bin/iodbc-config: No such file or directory
It would further appear that said script probably for some reason redirected stderr onto stdout or whatever file descriptor was being used to generate build.make, with the result being that the generated file was so damaged as to produce this error.
Of course, all this presupposes much and the question provides far too little contextual information, but certainly this explanation seems plausible.
In a real Makefile, one would correct the situation by removing the colons from all but the final target name, but the OP's file is apparently compromised since it is most improbable that the error message was ever intended to be a target name.
I have two GNUmakefiles in my directory as follows,
GNUmakefile &
GNUmakefile2
Could someone please let me know the command I have to use, if I have to let the "make" command to process "GNUmakefile2" instead of "GNUmakefile".
I used the below command,
make -f GNUmakefile2
but in that case, I am getting the following errors,
This is gnustep-make 2.6.1. Type 'make print-gnustep-make-help' for help.
make[1]: ** No rule to make target `internal-master-tool-all'. Stop.*
make: ** [internal-all] Error 2*
I think it is considering GNUmakefile as makefile (when I use make with -f command), so it is checking for rules in GNUmakefile.
At present what I am doing is I am renaming the required file (which I want, make command to execute) to "GNUmakefile". And I am not getting any errors while executing "make" command, but I don't think this is the correct solution.
Please let me know which command I need to use for this scenario. Thanks for your help.
After checking Beta's solution (i.e.,but that makefile is invoking Make a second time, and the second Make process is probably reading GNUmakefile) what I have done is I renamed existing "GNUmakefile" to "GNUmakefile3".
So at present in my directory the following makefiles are present:- "GNUmakefile2" & "GNUmakefile3".
And then I executed the following command:- $ make -f GNUmakefile2
I recieved the below errors,
This is gnustep-make 2.6.1. Type 'make print-gnustep-make-help' for help.
make[1]: GNUmakefile: No such file or directory
make[1]: * No rule to make target `GNUmakefile'. Stop.
make: * [internal-all] Error 2
Please let me know what is the problem here
Your makefile includes two huge makefiles from the FSF. The second, library.make, contains this rule:
ifeq ($(GNUSTEP_MAKE_PARALLEL_BUILDING), no)
# Standard building
...
else
# Parallel building. ...
internal-library-all_:: $(GNUSTEP_OBJ_INSTANCE_DIR) $(OBJ_DIRS_TO_CREATE)
$(ECHO_NOTHING_RECURSIVE_MAKE)$(MAKE) -f $(MAKEFILE_NAME) ...
endif
and the first, common.make contains this assignment:
# The default name of the makefile to be used in recursive invocations of make
ifeq ($(MAKEFILE_NAME),)
MAKEFILE_NAME = GNUmakefile
endif
So try either make -f GNUmakefile2 GNUSTEP_MAKE_PARALLEL_BUILDING=no or make -f GNUmakefile2 MAKEFILE_NAME=GNUmakefile2, and see if that solves the problem.
I have a legacy makefile based build system that I am trying to make changes to. I am not familiar with make and so was making changes on a trial and error basis.
Not being able to deduce what the problem is I inserted this bit of code in the makefile:
ARG1 = GCC
ARG2 = ARM
ifeq($(ARG1),$(ARG2))
$(warning *** WARNING ***)
endif
When I run make, I always get the print:
\PathToBuildDirectory\makefile.options:54:*** WARNING ***
NOTE: I am using clearmake with the -C gnu option.
How or why does the condition evaulate to true?
If it behaves this way for a makefile consisting of only the above content then it's a bug in clearmake. I know that clearmake's emulation of GNU make is incomplete, but this seems pretty simple.
However, since you're already echoing an error wouldn't it be straightforward to also show the values of ARG1 and ARG2? Maybe they ARE equal. Maybe one or both are set on the command line. Maybe elsewhere one or both was assigned with the override option. Maybe clearmake is invoked with the -e option and one or both of those variables are set in the environment.
If you show their values, then you'll know.
ETA: Maybe the problem is this: in GNU make you must put a space after the ifeq, like this:
ifeq ($(ARG1),$(ARG2))
If you try your original version with GNU make, you'll get an error:
Makefile:3: *** missing separator. Stop.
but I guess clearmake just ignores the line without any error messages.