gnucash master: Multiple changes pushed

Tue Jul 8 21:05:08 EDT 2014

Hello gnucash-devel,

I've been following this thread and trying to compile GnuCash myself and
have been getting the same error about unrecognised command line option but
have gotten different results through experimenting.

First of all, I'm running Arch Linux 64bit. And gcc/g++ version 4.9.0. I'm
trying to compile the latest source from git as of July 8, around 14:00 EDT.

$ gcc --version
gcc (GCC) 4.9.0 20140604 (prerelease)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I ran ./configure with the --disable--error-on-warning option just so one
warning won't halt the whole compile.

When compiling, sometimes there are two warnings: a warning about
FORTIFY_SOURCE and a warning about the unrecognised command line option
-Wno-non-literal-null-conversion:

In file included from /usr/include/string.h:25:0,
                 from swig-core-utils-guile.c:300:
/usr/include/features.h:341:4: warning: #warning _FORTIFY_SOURCE requires
compiling with optimization (-O) [-Wcpp]
 #  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
    ^
cc1: warning: unrecognized command line option
"-Wno-non-literal-null-conversion"

These two warnings always appear together. Like Sumit, I tried compiling
some trivial C and C++ programs with that compiler option to see what would
happen. Neither gcc nor g++ issued warnings or erros about using that
argument when I tried it on my sample code.

$ make
gcc -c -Wall -Wno-non-literal-null-conversion -Werror -o main.o main.c
gcc -c -Wall -Wno-non-literal-null-conversion -Werror -o foo.o foo.c
gcc -o main main.o foo.o
$

$ make
g++ -c -Wall -Wno-non-literal-null-conversion -Werror -std=c++11 -o main.o
main.cpp
g++ -c -Wall -Wno-non-literal-null-conversion -Werror -std=c++11 -o foo.o
foo.cpp
g++ -c -Wall -Wno-non-literal-null-conversion -Werror -std=c++11 -o bar.o
bar.cpp
g++ -o main main.o foo.o bar.o
$

The wierd part: I changed configure.ac around line 1318 to add the -O2
option to CFLAGS and CXXFLAGS. (I doubt this is the right way to do it, but
I'm not too familliar with the GNU build system, and I'm doing it just to
see what would happen).

# This has to come after AC_PROG_CC _AND_ GNOME_COMPILE_WARNINGS
AC_LANG([C++])
AX_CHECK_COMPILE_FLAG([-Wno-deprecated-register],
    [AM_CXXFLAGS="${AM_CXXFLAGS} -Wno-unused -Wno-deprecated-register -O2"],
    [AM_CXXFLAGS="${AM_CXXFLAGS} -Wno-unused"], [-Werror])
AC_LANG([C])
AX_CHECK_COMPILE_FLAG([-Wno-non-literal-null-conversion],
    [AM_CFLAGS="${AM_CFLAGS} -Wno-non-literal-null-conversion -O2"],
    [], [-Werror])

After making this change and running autogen.sh, configure, and make, the
warning about FORTIFY_SOURCE still appears about 4 times. But, the warning
about -Wno-non-literal-null-conversion has disappeared.

gcc -DHAVE_CONFIG_H -I. -I../../../..  -I../../../../lib/libc
-I../../../../src -I../../../../src/core-utils -I../../../../src/gnc-module
-I../../../../src/test-core -I../../../../src/engine
-I../../../../src/engine/test-core -I../../../../src/backend/sql
-I../../../../src/libqof/qof -pthread -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include  -D_FORTIFY_SOURCE=2 -pthread
-DG_LOG_DOMAIN=\"gnc.backend.sql\"  -DTESTPROG=test_sqlbe -I. -I../../../..
-I../../../../src/backend/sql/ -I../../../../src/backend/dbi/
-I../../../../src/libqof/qof/ -I../../../../src/test-core/ -pthread
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include  -g  -g  -MT
test_sqlbe-utest-gnc-backend-sql.o -MD -MP -MF
.deps/test_sqlbe-utest-gnc-backend-sql.Tpo -c -o
test_sqlbe-utest-gnc-backend-sql.o `test -f 'utest-gnc-backend-sql.c' ||
echo './'`utest-gnc-backend-sql.c
In file included from /usr/include/string.h:25:0,
                 from utest-gnc-backend-sql.c:24:
/usr/include/features.h:341:4: warning: #warning _FORTIFY_SOURCE requires
compiling with optimization (-O) [-Wcpp]
 #  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
    ^
mv -f .deps/test_sqlbe-utest-gnc-backend-sql.Tpo
.deps/test_sqlbe-utest-gnc-backend-sql.Po

I noticed that, for the files that still emit the FORTIFY_SOURCE warning
when compiled, the CFLAGS in the configure.ac file are not being used. My
-O2 and the -Wno-non-literal-null-conversion don't show up in the terminal.

So, it seems trying to eliminate one compiler warning not only doesn't work
but somehow eliminates another completely unrelated compiler warning.

I post this in the hopes that it might help someone much smarter than me
figure out what's actually going on.

Tim

On Tue, Jul 8, 2014 at 2:40 PM, John Ralls <jralls at ceridwen.us> wrote:

>
> On Jul 8, 2014, at 4:43 PM, Sumit Bhardwaj <bhardwajs at gmail.com> wrote:
>
> > On Mon, Jul 7, 2014 at 11:38 AM, John Ralls <jralls at ceridwen.us> wrote:
> >
> > On Jul 7, 2014, at 4:03 PM, Sumit Bhardwaj <bhardwajs at 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 at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>