[bug #25493] -include filename does not show correct dependency errors
URL: <http://savannah.gnu.org/bugs/?25493> Summary: -include filename does not show correct dependency errors Project: make Submitted by: willard Submitted on: Wed 04 Feb 2009 09:52:12 PM GMT Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 3.81 Operating System: None Fixed Release: None ___ Details: When using the "-include filename"(instead of just "include filename"), if this filename includes dependencies that are missing, make does not show those missing dependencies... For example, if using: -include foo.d with foo.d being: food.d foo.o: foo.c xxx.h Let's say xxx.h does not exist (and cannot be generated) , the make fails, but it does not say it's because of xxx.h missing. If instead, this is used: include foo.d then it works fine... I understand that the '-' in front of include means that THIS file 'foo.d' should not itself generate an error, but I would expect the content of foo.d to be used normally Full 1st example: - $ cat bad.mak all: foo.d foo.ooo COMPILE=gcc %.o: %.c $(COMPILE) -c $< %.d: %.c $(COMPILE) -c $< -MM -o $*.d -include foo.d foo.ooo: foo.o ld -o foo.ooo foo.o [/cygdrive/d/tstmake] $ make -f bad.mak make: *** No rule to make target `foo.d', needed by `all'. Stop. [/cygdrive/d/tstmake] $ cat good.mak all: foo.d foo.ooo COMPILE=gcc %.o: %.c $(COMPILE) -c $< %.d: %.c $(COMPILE) -c $< -MM -o $*.d include foo.d foo.ooo: foo.o ld -o foo.ooo foo.o [/cygdrive/d/tstmake] $ make -f good.mak make: *** No rule to make target `xxx.h', needed by `foo.d'. Stop. [/cygdrive/d/tstmake] $ cat foo.d foo.d foo.o: foo.c xxx.h the only difference between the 'good.mak' and 'bad.mak' is the '-' prefix on the include... See that the good.mak really displays what the problem is... whereas the bad.mak messages are not helpful. Full 2nd example: - it's the same if foo.d is not a direct target. It's even worse as make fails without ANY error message. Example2: $ cat bad2.mak all: foo.ooo COMPILE=gcc %.o: %.c $(COMPILE) -c $< %.d: %.c $(COMPILE) -c $< -MM -o $*.d -include foo.d foo.ooo: foo.o ld -o foo.ooo foo.o [/cygdrive/d/tstmake] $ make -f bad2.mak [/cygdrive/d/tstmake] $ cat makefile all: $(MAKE) -f bad2.mak [/cygdrive/d/tstmake] $ make make -f bad2.mak make: *** [all] Error 2 [/cygdrive/d/tstmake] $ cat foo.d foo.d foo.o: foo.c xxx.h See that the 'make -f bad2.mak' shows no message at all..(but going thru a makefile shows Error 2). ___ Reply to this item at: <http://savannah.gnu.org/bugs/?25493> ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: -include filename does not show correct dependency errors
I am new to this message board... I did not intend to yell... Thanks for the info... I hope the Gnu Make developers are listening to bug-m...@gnu.org. I had a quick look at the CVS tree bug tracking (on sourceforge.net), and I didn't see anything resembling this issue... -- View this message in context: http://www.nabble.com/-include-filename-does-not-show-correct-dependency-errors-tp21699973p21715450.html Sent from the Gnu - Make - Bugs mailing list archive at Nabble.com. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: -include filename does not show correct dependency errors
it's the same if foo.d is not a direct target. It's even worse as make fails without ANY error message. Example2: $ cat bad2.mak all: foo.ooo COMPILE=gcc %.o: %.c $(COMPILE) -c $< %.d: %.c $(COMPILE) -c $< -MM -o $*.d -include foo.d foo.ooo: foo.o ld -o foo.ooo foo.o [/cygdrive/d/opentv/tstmake] $ make -f bad2.mak [/cygdrive/d/opentv/tstmake] $ cat makefile all: $(MAKE) -f bad2.mak [/cygdrive/d/opentv/tstmake] $ make make -f bad2.mak make: *** [all] Error 2 [/cygdrive/d/opentv/tstmake] $ cat foo.d foo.d foo.o: foo.c xxx.h See that the 'make -f bad2.mak' shows no message at all..(but going thru a makefile shows Error 2). I am sure I can find a work-around, but this seems like a nasty bug THAT SHOULD BE FIXED. -- View this message in context: http://www.nabble.com/-include-filename-does-not-show-correct-dependency-errors-tp21699973p21710735.html Sent from the Gnu - Make - Bugs mailing list archive at Nabble.com. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: -include filename does not show correct dependency errors
this is my example (create the foo.d manually as below) $ cat bad.mak all: foo.d foo.ooo COMPILE=gcc %.o: %.c $(COMPILE) -c $< %.d: %.c $(COMPILE) -c $< -MM -o $*.d -include foo.d foo.ooo: foo.o ld -o foo.ooo foo.o [/cygdrive/d/opentv/tstmake] $ make -f bad.mak make: *** No rule to make target `foo.d', needed by `all'. Stop. [/cygdrive/d/opentv/tstmake] $ cat good.mak all: foo.d foo.ooo COMPILE=gcc %.o: %.c $(COMPILE) -c $< %.d: %.c $(COMPILE) -c $< -MM -o $*.d include foo.d foo.ooo: foo.o ld -o foo.ooo foo.o [/cygdrive/d/opentv/tstmake] $ make -f good.mak make: *** No rule to make target `xxx.h', needed by `foo.d'. Stop. [/cygdrive/d/opentv/tstmake] $ cat foo.d foo.d foo.o: foo.c xxx.h the only difference between the 'good.mak' and 'bad.mak' is the '-' prefix on the include... See that the good.mak really displays what the problem is... whereas the bad.mak messages are not helpful. -- View this message in context: http://www.nabble.com/-include-filename-does-not-show-correct-dependency-errors-tp21699973p21700324.html Sent from the Gnu - Make - Bugs mailing list archive at Nabble.com. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
-include filename does not show correct dependency errors
When using the "-include filename"(instead of just "include filename"), if this filename includes dependencies that are missing, makefile does not show those missing dependencies... For example, if using: -include foo.d with foo.d being: foo.o: foo.c xxx.h Let's say xxx.h does not exist (and cannot be generated) , the make fails, but it does not say it's because of xxx.h missing. If instead, this is used: include foo.d then it works fine... I understand that the '-' in front of include means that THIS file 'foo.d' should not itself generate an error, but I would expect the content of foo.d to be used normally Looks like a bug to me. Btw, I am using make 3.81. -- View this message in context: http://www.nabble.com/-include-filename-does-not-show-correct-dependency-errors-tp21699973p21699973.html Sent from the Gnu - Make - Bugs mailing list archive at Nabble.com. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Compilation error
May you please help
I get the following compilation error when I try to compile a nurbs++ package
with openGL support .
This is part of what i get until the error at the end
checking if the linker (c:/MinGW/mingw32/bin/ld.exe) is GNU ld... yes
checking for c:/MinGW/mingw32/bin/ld.exe option to reload object files... -r
checking for BSD-compatible nm... /mingw/bin/nm
checking whether ln -s works... yes
checking how to recognise dependant libraries... file_magic file format
pei*-i38
6(.*architecture: i386)?
checking command to parse /mingw/bin/nm output... ok
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... no
checking dlfcn.h presence... no
checking for dlfcn.h... no
checking for ranlib... ranlib
checking for strip... strip
checking for objdir... .libs
checking for gcc option to produce PIC... -DDLL_EXPORT
checking if gcc PIC flag -DDLL_EXPORT works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.lo... yes
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking whether the linker (c:/MinGW/mingw32/bin/ld.exe) supports shared
librar ies... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... Win32 ld.exe
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
creating libtool
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C preprocessor... gcc -E
checking for a BSD-compatible install... /bin/install -c
checking whether make sets ${MAKE}... (cached) yes
checking for cppunit-config... no
no
no
checking for X... no
checking "if you want to use the OpenGL extensions"... yes
checking "we like Mesa GL instead of just OpenGL"... "no"
checking "for Gl location"... "/usr/local/gl"
checking "for Gl include paths"... "Good, includes in your path"
"+ Gl libraries , Gl includes "
checking for main in -lGL... no
configure: WARNING: "Can\'t not link with Gl, trying the Mesa library..."
checking for main in -lMesaGL... no
configure: error: "You need to install \(Mesa\) OpenGL first: can\'t find
either the GL or MesaGL library"
I have checked and all my openGL libraries and files are in place
__
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
