Re: gnucash master: Multiple changes pushed
> > On Mon, Jul 7, 2014 at 11:38 AM, John Ralls wrote: > > On Jul 7, 2014, at 4:03 PM, Sumit Bhardwaj 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-literal-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. 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 > Cheers, Sumit ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash master: Multiple changes pushed
On Jul 8, 2014, at 4:43 PM, Sumit Bhardwaj wrote: > On Mon, Jul 7, 2014 at 11:38 AM, John Ralls wrote: > > On Jul 7, 2014, at 4:03 PM, Sumit Bhardwaj 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
french translation for gnucash ?
Hello I don't know if there is a French or French-speaking team, in charge of translating or internationalizing gnucash. If yes, I can give this link http://www.framasoft.net/article4886.html to a tutorial for gnucash in French, which seems a good starter. regards -- François TROMPAT 24 rue Guynemer 38100 GRENOBLE FRANCE tel +33480389016 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: french translation for gnucash ?
On Jul 8, 2014, at 8:54 PM, François Trompat wrote: > Hello > > I don't know if there is a French or French-speaking team, in charge of > translating or internationalizing gnucash. > If yes, I can give this link > http://www.framasoft.net/article4886.html > to a tutorial for gnucash in French, which seems a good starter. > Thanks. GnuCash itself is pretty well localized for French, but we don't have a translation for the Tutorial and Concepts Guide or the online Help. That would be most welcome if you or someone you know would like to contribute it. I've added the link to http://wiki.gnucash.org/wiki/Documentation on our wiki. Feel free to add more such links there if you find any. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash master: Multiple changes pushed
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 wrote:
>
> On Jul 8, 2014, at 4:43 PM, Sumit Bhardwaj wrote:
>
> > On Mon, Jul 7, 2014 at 11:38 AM, John Ralls wrote:
> >
> > On Jul 7, 2014, at 4:03 PM, Sumit Bhardwaj wrote:
> >> Hi John,
> >>
> >> Sumit,
> >>
> >> I don't understand how you concluded that the AM_CXXFLAGS are being
> included when make builds gfec.c,
