I have a makefile, which is missing an ldflag. I know how to fix it, but I don't know which line in the makefile the error is generated on.
+ make
CCLD test
test-test.o: In function `write_png':
/home/lenovo/scratch/libass/test/test.c:52: undefined reference to `png_create_write_struct'
...
/home/lenovo/scratch/libass/test/test.c:57: undefined reference to `png_destroy_write_struct'
collect2: ld returned 1 exit status
make: *** [test] Error 1
How do I get make to print out the line the error is on?
(If anybody is wondering, it is a makefile from the libass project in the test directory.)
Try using remake to see if it helps.
http://static.usenix.org/events/lisa11/tech/full_papers/Bernstein.pdf
Heres an example obtained from the link above:
Hope this helps!
Related
Here's the last few lines from the output of running "make install" at root level /home/gm/TEST/:
make[3]: Leaving directory `/home/gm/TEST/tppf/tm/ipmgt'
ld ipfac.o ipfacV.o ipfac_rset.o ipfac_args.o ipfac_d2a.o ipfac_a2d.o ipfac_modr.o ipfac_mod.o ipfac_read.o ipfac_add.o ipfac_del.o ipfac_list.o ipfac_unlk.o ipfac_lock.o ipfac_util.o ipfac_lkid.o -r -o /home/gm/TEST/tppf/lib/ipfac_tppf.o
make[3]: Leaving directory `/home/gm/TEST/tppf/tm/ipfac'
make[2]: Leaving directory `/home/gm/TEST/tppf/tm'
make[1]: *** [i_tm] Error 2
make[1]: Leaving directory `/home/gm/TEST/tppf'
make: *** [i_tppf] Error 2
And the Makefile under /home/gm/TEST/tppf/tm/ipfac contains this rule:
install: ipfac.h $(TPPLIB)/ipfac_tppf.o
$(TPPLIB)/ipfac_tppf.o: $(PROPOBJS)
ld $(PROPOBJS) -r -o $(TPPLIB)/ipfac_tppf.o
Is there something wrong with the linking process? Make should've told me what the error actually is, but it didn't.
BTW, I think /home/gm/TEST/tppf/lib/ipfac_tppf. O was linked and created successfully, or at least it was there in directory /home/gm/TEST/tppf/lib/ after make failed and exited.
That line is not the error line. You can tell that it succeeded because there was no error message there, for building the target /home/gm/TEST/tppf/lib/ipfac_tppf.o.
The error is here:
make[1]: *** [i_tm] Error 2
The [1] means that it was the first level of makefile (note the recipe you are quoting here was in the 3rd level of makefile) and the [i_tm] means that the build of the target i_tm failed. You need to look back up further in the output of make, earlier than what you've shown us, and find the *** error line for building the i_tm target and see what errors were generated there.
I want to run some code in torch that requires the gnuplot lib however I get the following error;
/Users/mattsmith/torch/install/bin/luajit: ...attsmith/torch/install/share/lua/5.1/gnuplot/gnuplot.lua:127: Gnuplot terminal is not set
stack traceback:
[C]: in function 'error'
...attsmith/torch/install/share/lua/5.1/gnuplot/gnuplot.lua:127: in function 'getfigure'
...attsmith/torch/install/share/lua/5.1/gnuplot/gnuplot.lua:808: in function 'figure'
...attsmith/torch/install/share/lua/5.1/gnuplot/gnuplot.lua:288: in function 'getCurrentPlot'
...attsmith/torch/install/share/lua/5.1/gnuplot/gnuplot.lua:308: in function 'writeToCurrent'
...attsmith/torch/install/share/lua/5.1/gnuplot/gnuplot.lua:836: in function 'gnulplot'
...attsmith/torch/install/share/lua/5.1/gnuplot/gnuplot.lua:976: in function 'plot'
practical3.lua:217: in main chunk
[C]: in function 'dofile'
...mith/torch/install/lib/luarocks/rocks/trepl/scm-1/bin/th:131: in main chunk
[C]: at 0x0104467190
I read here Lua Error: "Gnuplot terminal is not set" that I require the gnu plot executable installed. So I downloaded this and followed the website instructions here http://gnuplot.sourceforge.net/ReleaseNotes_5_0.html and then I get this error;
In file included from ./term.h:414:
../term/lua.trm:113:10: fatal error: 'lua.h' file not found
#include <lua.h>
^
1 error generated.
make[3]: *** [term.o] Error 1
make[2]: *** [install-recursive] Error 1
make[1]: *** [install] Error 2
make: *** [install-recursive] Error 1
Not too sure if I am going about this the correct way. Any help would be greatly appreciated!
Thanks
Find wherever lua.h is located. For me it was in: /usr/local/Cellar/lua/5.3.5_1/include/lua
Then, open lua.trm inside the gnuplot installation files, find #include lua.h and replace it with path/lua.h. In my case: /usr/local/Cellar/lua/5.3.5_1/include/lua/lua.h
You will notice that there are other "includes" that will throw the same error as the one with lua.h. There are all on the same path. Therefore, modify the includes the in the same manner.
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 :)
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.
When I am compiling my code with makefiles (I have 12 makefiles) there is an error telling
make.exe[1]: Leaving directory Error 2 what is the reason for this?
Also what does the "Error 2 or Error 1 " mean?
When make prints "Error 2" in this context it just means that there was an error in a recursive make invocation. You have to look at the error messages preceeding that message to determine what the real problem was, in the submake. For example, given a Makefile like this:
all:
$(MAKE) -f sub.mk
... and a sub.mk like this:
all:
#exit 1
When I run GNU make, it prints the following:
gmake -f sub.mk
gmake[1]: Entering directory `/tmp/foo'
gmake[1]: *** [all] Error 1
gmake[1]: Leaving directory `/tmp/foo'
gmake: *** [all] Error 2
Error 2 tells me that there was an error of some sort in the submake. I have to look above that message, to the Error 1 message from the submake itself. There I can see that some command invoked while trying to build all exited with exit code 1. Unfortunately there's not really a standard that defines exit codes for applications, beyond the trivial "exit code 0 means OK". You have to look at the particular command that failed and check its documentation to determine what the specific exit code means.
These error messages have nothing to do with Unix errno values as others have stated. The outermost "2" is just the error code that make itself assigns when a submake has an error; the inner "1" is just the exit code of a failed command. It could just as easily be "7" or "11" or "42".