On Jul 8, 2014, at 4:43 PM, Sumit Bhardwaj <bhardw...@gmail.com> wrote:
> On Mon, Jul 7, 2014 at 11:38 AM, John Ralls <jra...@ceridwen.us> wrote: > > On Jul 7, 2014, at 4:03 PM, Sumit Bhardwaj <bhardw...@gmail.com> wrote: >> Hi John, >> >> Sumit, >> >> I don't understand how you concluded that the AM_CXXFLAGS are being included >> when make builds gfec.c, nor do I understand why you think that it's using >> g++. The command make emitted when it failed was: >>>> gcc -DHAVE_CONFIG_H -I. -I../.. -Wno-error=deprecated-declarations >>>> -I../../lib/libc -I../../src -I../../src -I../../src/gnc-module >>>> -I../../src/app-utils/calculation -I../../src/core-utils >>>> -I../../src/engine -I../../src/libqof/qof -I../../src/backend/xml -pthread >>>> -I/usr/include/guile/2.0 -pthread -I/usr/include/glib-2.0 >>>> -I/usr/lib64/glib-2.0/include -pthread -I/usr/include/gtk-2.0 >>>> -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 >>>> -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 >>>> -I/usr/include/libdrm -I/usr/include/libpng16 >>>> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 >>>> -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 >>>> -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include >>>> -I/usr/include/freetype2 -I/usr/include/libxml2 -I/usr/include/libxml2 >>>> -DG_LOG_DOMAIN=\"gnc.app-utils\" -Werror -Wdeclaration-after-statement >>>> -Wno-pointer-sign -D_FORTIFY_SOURCE=2 -Wall -Wunused -Wmissing-prototypes >>>> -Wmissing-declarations -Wno-non-li! teral-null-conversion -Wno-unused -g -O2 -MT gfec.lo -MD -MP -MF .deps/gfec.Tpo -c gfec.c -fPIC -DPIC -o .libs/gfec.o >> >> Clearly showing that it's calling gcc and clearly not including >> -Wno-deprecated-register. >> >> Apologies for not being clear. This compile shouldn't cause problem if the >> compiler was gcc. My test >> gcc -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations >> -Wno-non-literal-null- >> conversion -Wno-unused -g -O2 -Werror -D_FORTIFY_SOURCE=2 helloworld.c >> worked without any problems, but the test with g++ threw the error saying >> -Wno-non-literal-null-conversion is not a valid option. > > Yeah, I got that. What I don't understand is why you think that's germane > when it's clearly gcc that's failing to compile gfec.c and it's clearly cc1, > not cc1plus, that's rejecting the -Wno-non-literal-null-conversion argument. > > My hypothesis is based on the experiment on the trivial helloworld.c with gcc > and g++. While gcc compiles and links with the > -Wno-non-literal-null-conversion argument, g++ doesn't. > > My hypothesis for the fail step is that cc1plus is invoked in the background > which bonks with this argument. I will google to see if that's the behavior > in mixed (C and C++) codebases. You can test that by pasting the gcc invocation directly to a command prompt. If gfec.c compiles that way, you're hypothesis is proved and make or libtool is doing something sttange; if not, the problem is in gcc or maybe something about gfec.c. It's perhaps significant that app-utils is about halfway through the compilation, so lots of files have compiled quite happily with that argument. > > So adding actual code to be compiled doesn't make any difference, it still > passes only to fail later. Rats. > Of course, we can drop this argument as a workaround. Barring that, configure > is setting CFLAGS and CXXFLAGS correctly. Rats indeed! Regards, John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
