So here's the thing.
I'm trying to build pngwriter. In the makefile there's a line saying:
include make.include
The file make.include has the function to specify the platform used via a symlink, it has just one line:
make.include.linux
(there's a file in the same directory called make.include.linux which has some necessary settings. And by the way, I'm doing this on Windows with MinGW)
in the msys shell, when I do make, it says:
make.include:1: *** missing separator. Stop.
I've looked at other missing separator posts and they're about spaces/tabs, which I think it's not the case here. I've searched about makefiles, symlinks, separators and could solve it.
Please help!
EDIT! OK, so make.include.linux isn't a command, it's a file whose contents need to be included in the original makefile. The make.include should be, as I read, a symlink to make.include.linux.
What you have there isn't valid make syntax. Commands can only be run as part of a target recipe. In your case it seems like what you want is:
all:
make.include.linux
Assuming that make.include.linux is a command, and not something else. Make sure the indentation is a tab character.
Related
I have seen this question and has read its many answers. I understand that this problem usually (always??) appears because of a mistake in using tabs vs spaces in Makefiles. So far that is the general case.
In my case, I have found the error in the title but not when doing make with a Makefile I suspect.
I do:
make a_configuration_file
and I get
Makefile:1: *** missing separator. Stop.
I suppose this "1" means that the error is occurring in the first line of the file, right?
This a_configuration_file is actually a generated file and the first lines are copied here :
#
# Automatically generated file; DO NOT EDIT.
# Ambarella SDK Configuration
#
CONFIG_THREADX=y
CONFIG_BOOT_CORE_SRTOS=0
So my questions for my particular case are:
The "1" refers to the comment line "#"? or the CONFIG_THREADX line?
This configuration file is not using Tabs. So what could be the problem?
EDIT:
Robert tells me that the problem could be the end-of-line. I checked with cat -A a_configuration_file and it seems there are no \r characters (I ve had problems with this before so I learned how to check for end-of-line chars)
Wander Nauta tells me the problem is in the Makefile. Which Makefile should I check? Right now there is a Makefile in the directory from where I call make and it is like this
build/Makefile
no tabs or spaces
I also did cat -A Makefile and I got
build/Makefileroot#themachine.....
If you are wondering what is that, is just that it seems that the Makefile does not have an end of the line at the end, so the cat command prints the contents and the rest (root#themachine...) is just the normal line in the command line
EDIT2:
I think I am close to finding the error.
Originally the "Makefile" was a link as in
ls ./ -l
lrwxrwxrwx 1 1133 543 13 Mar 18 Makefile -> build/Makefile
However now it is just a plain text file
ls ./ -l
-rw------- 1 11250 10513 14 Jul 6 Makefile
Somehow in the linux-windows-linux transference the link condition got lost
In my case, I have found the error in the title but not when doing make with a Makefile I suspect.
The error in the title specifies the name of the file in which the error is encountered: Makefile. Thus, your suspicion about "not when doing so with a Makefile" is unfounded. Although it is possible to run make without a makefile, and doing so can even be advantageous, make will always read a makefile if it can find one by one of the default names it looks for.
Moreover, though it may not be obvious in this case, the name given in the message is not just a base name but a (relative) path to the file. It is therefore complaining about a file named Makefile in make's working directory.
Right now there is a Makefile in the directory from where I call make
and it is like this
build/Makefile
no tabs or spaces I also did cat -A Makefile and I got
build/Makefileroot#themachine.....
Those two claims do not appear to be consistent with each other. In any case, however, neither one attributes valid makefile content to the makefile in question. This is likely the cause of the error message, which would then be a bit misleading.
It looks like you may be trying to have one makefile specify that another make be run in the build/ directory -- a so-called "recursive make". There are a couple of variations on how that is done, and they differ slightly in effect, but here's a guess at what you might be after for that top-level Makefile:
all:
$(MAKE) -C build
Of course, that second line needs to be indented with a leading tab, not spaces.
That will cause the top-level make run to trigger a second make run with the build/ directory as the second's working directory.
I have a simple Makefile that was included in the nRF52 sdk for one of the Bluetooth examples.
I want to make a copy of the file and move it, hence I need to update some parameters.
The part of the makefile I changed looks as such
SDK_ROOT := C:/Nordic_SDKS/nRF5SDK1702d674dde
It previously was the relative path using ../../../
When I run make I get the following output
make: *** No rule to make target `C\:/Nordic_SDKS/nRF5SDK1702d674dde/modules/nrfx/mdk/gcc_startup_nrf52.S', needed by `_build/nrf52832_xxaa/gcc_startup_nrf52.S.o'. Stop.
My Knowledge of Makefiles is very limited, but I presume the inserted "\" after the C directory is the reason the recipe is failing, since without that backslash that file exists.
Is there a way to stop this from happening, or am I wrong with what the problem is?
A couple of things:
Escaping in Windows/Batch File can be done with a carrot like C^:/Nordic instead of \ but I don't think it's your issue.
Change
SDK_ROOT := C:/Nordic_SDKS/nRF5SDK1702d674dde
to
SDK_ROOT := C:\Nordic_SDKS\nRF5SDK1702d674dde
Then of course verify the path/name combo truly exist with copy and paste to look for typos. In a command prompt
dir C:\Nordic_SDKS\nRF5SDK1702d674dde\modules\nrfx\mdk\gcc_startup_nrf52.S
Although both names will do the job, what is the correct name for makefiles?
GNU `make' homepage uses Makefile, and I guess it is the good way to name it. Any reasons for typing the front M in upper case ?
What Name to Give Your Makefile chapter of GNU Make manual clarifies it:
By default, when make looks for the makefile, it tries the following names, in order: GNUmakefile, makefile and Makefile. Normally you should call your makefile either makefile or Makefile. (We recommend Makefile because it appears prominently near the beginning of a directory listing, right near other important files such as README.) The first name checked, GNUmakefile, is not recommended for most makefiles. You should use this name if you have a makefile that is specific to GNU make, and will not be understood by other versions of make. Other make programs look for makefile and Makefile, but not GNUmakefile.
I think that Makefile is displayed at the almost top of the list rather than makefile when using the ls command.
it is not only the reason that it appears prominently near the beginning of a directory listing, but also that it would cause a compile error when you using “makefile” to replace “Makefile”。 you could try to test in the helloworld case of Linux device driver..
I understand that # suppresses printing of a command in a Makefile...
http://www.gnu.org/software/make/manual/make.html#Echoing
... and I understand that $# is the target name...
http://www.gnu.org/software/make/manual/make.html#Automatic-Variables
... but I can't find any information on what a line like this might mean:
variable=#value#
I'm not trying to fix anything here, just trying to better understand Makefiles.
Update: The "Makefile Subsitutions" section of the GNU autoconf manual explains that it's a value that is substituted by autoconf.
Typically you find this in Makefile.in files, which are processed by configure (which are in turn generated by autoconf) scripts.
In that case #X# will be replaced by the value of a shell variable $X, if configure is told so. If it's not, no occurrence in the input file will be touched by configure, hence leaving the replaceable string as it is. If you ask me these instances indicate slips in the build system.
I'm trying to 'make' using a pretty simple makefile. My makefile is named 'Makefile' so I'm simply using the command 'make'.
I get this strange error:
make: *** No rule to make target `/Makefile', needed by `Makefile'. Stop.
If, however, I use
make -f "full-path-to-makefile" it actually does run (with odd consequences...). I should say that I'm running all this from the directory where the Makefile lies, of course.
I'm working on Mac OSX, using tcsh.
Edit:
I'm working in the LLVM framework, trying to compile a pass function and this is the associated makefile:
LEVEL = ../../../
LIBRARYNAME = FunctionName
LOADABLE_MODULE = 1
include $(LEVEL)/Makefile.common
Any ideas will be appreciated :)
I had the same problem trying to write a new pass for LLVM i followed these instructions trying to make a HelloB (as Hello already exsited) http://llvm.org/docs/WritingAnLLVMPass.html#quickstart
What i has to do was do a ./configure again then make from the base directory.
I'll go out on a limb: you have an extra slash. Try omitting the final slash in $(LEVEL).
I found the answer, sort of:
The problem was with the installation process of LLVM. It seems that if you do the installation in one order instead of another it can lead to this error. It doesn't make any sense to me, but after I installed it properly everything compiles great (same code, same Makefile, same make program).
I don't really know why this happened, but I know how to fix it :)
What you want to do is ./configure again then make from the base directory (contrary to what is stated in the instructions on the web-site). That worked for me.
BTW - I got the same results running on Ubuntu (with the same fix).
Just to add some information here (since this is the first hit that comes up on Google when looking for the error) - I had the same problem which suddenly popped up on a (previously working) LLVM setup on OSX, and traced it back to the behavior of the realpath command in make.
Specifically, what was happening was that I had a directory called "LLVM/llvm-2.9-build", but for some reason the attempt to resolve PROJECT_OBJ_ROOT at the top of Makefile.config would decide that this directory was in fact called "llvm/llvm-2.9-build". Since OSX is case-insensitive by default, this doesn't cause an immediate problem, except that subsequently LLVM_SRC_ROOT would be set to "LLVM/llvm-2.9-build". This then meant that the creation of PROJ_SRC_DIR using patsubst to replace the object directory would result in a non-existent path (as the unmatched case means that no pattern replace occurs), which in turn would get resolved to / by realpath.
With PROJ_SRC_DIR set to /, this results in the makefile copy rule in Makefile.rules deciding that the source makefile is at $(PROJ_SRC_DIR)/Makefile (ie /Makefile), and the error message described.
It seems that it is only the built-in implementation of realpath in Make (GNU Make 3.81 in my case) that has this behaviour, as forcibly using the macro version of realpath from the top of Makefile.config fixes the problem. However, this isn't a good long-term fix, as you'd have to manually patch every one of the LLVM makefiles.
In the end, I couldn't see where realpath would be getting the lower-case "llvm" from, but figured it was probably an artifact somehow of some caching of the name from a point in time when I'd referenced the directory using its lower-case name. Hence I tried going to that directory and mv-ing it to a completely different name, and then back to "LLVM" before going in and building again, and that seems to have solved the problem.
I hope that's of some use to anyone else who comes across this particular weirdness!
It's not a complete answer, but what you are seeing is gmake not finding the Makefile it is told to include, and thus it is trying to remake it and failing because it can't find a recipe for it either.
However, the Makefile snippet you posted does not produce the error message you are seeing, so I think the problem is inside the Makefile.common file. Look for include statements which reference a $(some variable expansion)/Makefile and work backwards from there. You can also try to run gmake with the -d option and follow the processing based on the output.
Since your include line reads:
include $(LEVEL)/Makefile.common
it is puzzling that you are not getting an error about /Makefile.common. If you were, then I'd suggest that maybe you have a trailing blank after the definition of LEVEL.
Could there be a line in Makefile.common that itself includes $(SOMEMACRO)/Makefile and you have not set the value of SOMEMACRO?
here's my fixes for this issue: (https://github.com/rust-lang/rust/issues/24887#issuecomment-99391849)
update src/llvm/Makefile.config.in before running ./configure
or update x86_64-apple-darwin/llvm/Makefile.config before make
line 59:
PROJ_SRC_DIR := $(LLVM_SRC_ROOT)$(patsubst $(PROJ_OBJ_ROOT)%,%,$(PROJ_OBJ_DIR))
update to
PROJ_SRC_DIR := $(patsubst $(PROJ_OBJ_ROOT)%,$(LLVM_SRC_ROOT)%,$(PROJ_OBJ_DIR))
line 86:
PROJ_SRC_DIR := $(call realpath, $(PROJ_SRC_ROOT)/$(patsubst $(PROJ_OBJ_ROOT)%,%,$(PROJ_OBJ_DIR)))
update to
PROJ_SRC_DIR := $(call realpath, $(patsubst $(PROJ_OBJ_ROOT)%,$(PROJ_SRC_ROOT)%,$(PROJ_OBJ_DIR)))