Re: autogen.sh / Now really fix old typo
Derek Atkins schrieb: echo processing $dr macrodirs=`sed -n -e 's,AM_ACLOCAL_INCLUDE(\(.*\)),\1,gp' < $coin` ( cd $dr - macrodir=`find . -name macros -print` + macrodirs=`find . -name macros -print` for i in $macrodirs; do Um, why does it set macrodirs and then cd into $dr and then re-set macrodirs? The results of the sed command are clearly ignored. Should we ignore it? If so, that line should just be removed, no? True as well. Both lines lead to the same result (on the 1-8-branch), so any of the two could be removed with the same effect (probably rather the latter). Nevertheless this whole autogen.sh file is IMHO quite a mess. Personally I would now prefer a much simplified version, e.g. like this one http://cvs.sourceforge.net/viewcvs.py/ktoblzcheck/ktoblzcheck/autogen.sh?rev=1.5&view=markup (happens to be committed by myself) and if any of these commands cannot be found (which are all visible due to the -x argument), then leave it up to the developer to set a correct PATH. Our long autogen.sh script eventually doesn't do anything else than what this very short script does. In any case we won't change the 1-8-branch anymore, but we might consider something along these lines for the gnome2 branch. Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Error building gnucash 1.8.12
I'm trying to build gnucash 1.8.12 as rpm. it compiles fine, but on starting gnucash, it exits with the error ERROR: In procedure dynamic link: ERROR: file: "libgw-gnc", message: "/usr/lib/libgw-gnc.a: invalid ELF header" Gnucash 1.8.11 builds fine on the same system and works! Both in 1.8.11 and 1.8.12 the option --enable-error-on-warning=no had to be added to configure to work. The file /usr/lib/libgw-gnc.a does not exist on my system with an self-built g-wrap 1.3.4 There are the following files: libgw-gnc.la libgw-gnc.so libgw-gnc.so.0 libgw-gnc.so.0.0.0 Anyone knows why this happens? Regards, rauch ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Error building gnucash 1.8.12
Dear Christian, I guess you are building on a SuSE system? Then, according to http://linuxwiki.de/GnuCash/SourceInstall, you need to specify the following argument at ./configure: ./configure --build=i686-pc-linux-gnu This is a known problem with SuSE and won't be fixed in the gnucash-1.8.x series. The clear indication that this has been the error is that when running ./configure, you get the following output: checking dynamic linker characteristics... unknown checking if libtool supports shared libraries... no checking whether to build shared libraries... no checking whether to build static libraries... yes -- and static libraries are the WRONG THING (TM) for gnucash. Christian Rauch Christian schrieb: I'm trying to build gnucash 1.8.12 as rpm. it compiles fine, but on starting gnucash, it exits with the error ERROR: In procedure dynamic link: ERROR: file: "libgw-gnc", message: "/usr/lib/libgw-gnc.a: invalid ELF header" ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
QOF API and gnucash string cache code in G2
On Friday 14 October 2005 1:54 pm, David Hampton wrote:
> Log Message:
> ---
> Patch from Chris Shoemaker to privatize the gnucash string cache code
> and force all usage through gnc_string_cache_{remove,insert}()
> functions. This makes debugging various uses (and misuses) of the
> cache easier.
Part of this is going to need to be made backwards-compatible with the
external QOF library: (despite the name, gnc-engine-util.c|h is part of QOF
even though gnc-engine.c|h is only in gnucash - this is one of the filename
changes I want to make within libqof1. Using #include "qof.h" insures against
problems when this is changed.)
> -/** Get the gnc_string_cache. Create it if it doesn't exist already
> -
> -\todo hide the gcache as a static */
> -GCache* gnc_engine_get_string_cache(void);
I can't remove a part of the API like that, it needs to be retained and
deprecated. It won't affect gnucash, but it would break other QOF
applications.
To maintain synchronisation with external QOF, I'll reinstate the old
non-static function as a deprecated part of the API.
Something like:
> Index: gnc-engine-util.h
+/** Get the gnc_string_cache. Create it if it doesn't exist already
+
+ \deprecated Use qof_init instead. */
+GCache* gnc_engine_get_string_cache(void);
> Index: gnc-engine-util.c
>
+ /* deprecated function - to be made static */
- static GCache*
+ GCache*
gnc_engine_get_string_cache(void)
The deprecated function is not now used in gnucash and this change should not
have any effect elsewhere.
As with all other changes to QOF files, all deprecated code will be removed in
a single operation when libqof2 is ready and no parts of the API will be
removed during the life of libqof1 (which has been on pre-release for a few
weeks now).
My next patch should clarify which files are QOF files and which are gnucash
engine files.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpmjgU4bQ7Pm.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Error building gnucash 1.8.12
Christian Stimming schrieb: Dear Christian, I guess you are building on a SuSE system? Then, according to http://linuxwiki.de/GnuCash/SourceInstall, you need to specify the following argument at ./configure: ./configure --build=i686-pc-linux-gnu if building with this argument i get the following error: checking if scanf supports %lld conversions... configure: error: cannot run test program while cross compiling therefore i tried removing this one. it builds fine, but with the noticed error on starting This is a known problem with SuSE and won't be fixed in the gnucash-1.8.x series. The clear indication that this has been the error is that when running ./configure, you get the following output: checking dynamic linker characteristics... unknown checking if libtool supports shared libraries... no checking whether to build shared libraries... no checking whether to build static libraries... yes -- and static libraries are the WRONG THING (TM) for gnucash. i get the following output with and without this argument: checking dynamic linker characteristics... unknown checking if libtool supports shared libraries... no checking whether to build shared libraries... no checking whether to build static libraries... yes I am building on openSUSE 10.0 Final. Regards, Christian Rauch ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fix currency display in locale with non utf8 charset
On Wednesday 19 October 2005 10:42 pm, Didier Vidal wrote: > This should fix one of the problems that Neil reported in en_GB locale. > Do you see other pango-related problems, Neil ? Not with this patch. I get no pango errors and there's no need to fiddle with LANG or other environment settings. The currency symbols and number displays work as expected - thanks, Didier, it looks like that his fixed the pango problems. I'll commit the patch later. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpjMpp4sqkvv.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: autogen.sh / Now really fix old typo
Quoting Christian Stimming <[EMAIL PROTECTED]>: Nevertheless this whole autogen.sh file is IMHO quite a mess. Personally I would now prefer a much simplified version, e.g. like this one http://cvs.sourceforge.net/viewcvs.py/ktoblzcheck/ktoblzcheck/autogen.sh?rev=1.5&view=markup I think it would be nice if we had " || exit 1" at the end of every line. Also, it would be nice to provide env vars to set those values, so a dev could choose a particular version of autoconf by setting AUTOCONF=... But I agree that simplifying the autogen script is a worthwhile goal for g2. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: autogen.sh / Now really fix old typo
Derek Atkins schrieb: Nevertheless this whole autogen.sh file is IMHO quite a mess. Personally I would now prefer a much simplified version, e.g. like this one http://cvs.sourceforge.net/viewcvs.py/ktoblzcheck/ktoblzcheck/autogen.sh?rev=1.5&view=markup I think it would be nice if we had " || exit 1" at the end of every line. Alternatively I've added trap exit ERR in the beginning of that script, which has the same effect and is more readable. Although I'm not sure which of both possibilities are more portable. Surely bash has trap, but I'm not sure about shells elsewhere. Also, it would be nice to provide env vars to set those values, so a dev could choose a particular version of autoconf by setting AUTOCONF=... if test x$AUTOCONF = x; then AUTOCONF=autoconf; fi $AUTOCONF or similar But I agree that simplifying the autogen script is a worthwhile goal for g2. Ok. I'd revisit this once it will become easy to have extra branches for testing stuff like this. Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fix currency display in locale with non utf8 charset
On Thursday 20 October 2005 12:14 pm, Didier Vidal wrote: > I was not sure about the copy, especially if the string is already utf8 > before we call g_locale_to_utf8. I prefered to risk a small leak than a > crash. I'm testing without the g_strdup() call and it's working fine on Debian unstable. I normally test on FC3 and Mac OSX as well before the commit (later today). -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp0zlW69xKwE.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Error building gnucash 1.8.12
Dear Christian, Rauch Christian schrieb: ./configure --build=i686-pc-linux-gnu if building with this argument i get the following error: checking if scanf supports %lld conversions... configure: error: cannot run test program while cross compiling That's bad. That was the known workaround for SuSE 9.3, 9.2, and 9.1. i get the following output with and without this argument: checking dynamic linker characteristics... unknown checking if libtool supports shared libraries... no checking whether to build shared libraries... no checking whether to build static libraries... yes I am building on openSUSE 10.0 Final. As long as you get this output, gnucash won't run. You definitely *have* to get the output as described on http://linuxwiki.de/GnuCash/SourceInstall , which looks like checking dynamic linker characteristics... GNU/Linux ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no If you know a little bit of shell coding, you might want to have a look in the ./configure script at the place where the linker characteristics are decided. I'm very sure that you should be able to fix it with one or two ./configure arguments. Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Error building gnucash 1.8.12
Christian Stimming schrieb: Dear Christian, Rauch Christian schrieb: ./configure --build=i686-pc-linux-gnu if building with this argument i get the following error: checking if scanf supports %lld conversions... configure: error: cannot run test program while cross compiling That's bad. That was the known workaround for SuSE 9.3, 9.2, and 9.1. I know. i get the following output with and without this argument: checking dynamic linker characteristics... unknown checking if libtool supports shared libraries... no checking whether to build shared libraries... no checking whether to build static libraries... yes I am building on openSUSE 10.0 Final. As long as you get this output, gnucash won't run. You definitely *have* to get the output as described on http://linuxwiki.de/GnuCash/SourceInstall , which looks like checking dynamic linker characteristics... GNU/Linux ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no That's really bad. If you know a little bit of shell coding, you might want to have a look in the ./configure script at the place where the linker characteristics are decided. I'm very sure that you should be able to fix it with one or two ./configure arguments. Also my knowledge to shell scripting is close to zero ( i prefer php ;)), i will have a look at the configure script. Perhaps i can figure out, how to get over this message or even make it end successfully and see what happens. Christian Thanks, Christian Rauch ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: autogen.sh / Now really fix old typo
On Thu, Oct 20, 2005 at 10:31:18AM +0200, Christian Stimming wrote: > > Nevertheless this whole autogen.sh file is IMHO quite a mess. Personally > I would now prefer a much simplified version, e.g. like this one > http://cvs.sourceforge.net/viewcvs.py/ktoblzcheck/ktoblzcheck/autogen.sh?rev=1.5&view=markup > (happens to be committed by myself) and if any of these commands cannot > be found (which are all visible due to the -x argument), then leave it > up to the developer to set a correct PATH. Our long autogen.sh script > eventually doesn't do anything else than what this very short script > does. In any case we won't change the 1-8-branch anymore, but we might > consider something along these lines for the gnome2 branch. I agree. Another benefit of the simpler script is that it makes it easier for the developer to understand the autotools. The big autogen.sh obscures important details and, for me at least, was an impediment to actually learning what was happening. The simpler script is more informative, easier to maintain, and will probably work better, since if something goes wrong, it's much easier for the dev to see how to fix it. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: autogen.sh / Now really fix old typo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christian Stimming wrote:
| if test x$AUTOCONF = x; then AUTOCONF=autoconf; fi
| $AUTOCONF
: ${AUTOCONF=autoconf}
$AUTOCONF
etc...
Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)
iQCVAwUBQ1ehm7iDAg3OZTLPAQLeXgQAhzR064dEE35G4arG84YHv0bddo58HqeC
DRrNo1xlybTEkM28NZSIGFneDEvtHicW0/kTZf/9mC7Vbm7aLxLj4yNrkLMqmh+z
MnVd5yjMUrwQSL5AdOGdQ2QLLT6JIZ64vzJNF9tAEy9ryCCqUCq2P/rzE4Ru+EBL
cVvNpw+pH2A=
=wMc7
-END PGP SIGNATURE-
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Error building gnucash 1.8.12 on OpenSuSE 10.0
As it turns out, the described workaround is still correct, even for OpenSuSE 10.0. In this particular case, ./configure was invoked from a rpm spec file, which specified additionally the arguments ./configure --host=i686-suse-linux --build=i686-suse-linux --target=i686-suse-linux. This is the target name which is not supported by the shipped configure and needs to be overridden by the --build=i686-pc-linux-gnu. However, when Christian Rauch added --build=i686-pc-linux-gnu, then the --build and --host/target were different, so there was an error message about "cross compiling". The final workaround for this particular case where build, host, target are all given, is to use all three with the working target name: ./configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=i686-pc-linux-gnu For all normal users that do not deal with a rpm spec file, the described ./configure --build=i686-pc-linux-gnu is still sufficient. Christian Rauch Christian schrieb: Christian Stimming schrieb: Dear Christian, Rauch Christian schrieb: ./configure --build=i686-pc-linux-gnu if building with this argument i get the following error: checking if scanf supports %lld conversions... configure: error: cannot run test program while cross compiling That's bad. That was the known workaround for SuSE 9.3, 9.2, and 9.1. I know. i get the following output with and without this argument: checking dynamic linker characteristics... unknown checking if libtool supports shared libraries... no checking whether to build shared libraries... no checking whether to build static libraries... yes I am building on openSUSE 10.0 Final. As long as you get this output, gnucash won't run. You definitely *have* to get the output as described on http://linuxwiki.de/GnuCash/SourceInstall , which looks like checking dynamic linker characteristics... GNU/Linux ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Error building gnucash 1.8.12 on OpenSuSE 10.0
Christian Stimming schrieb: As it turns out, the described workaround is still correct, even for OpenSuSE 10.0. In this particular case, ./configure was invoked from a rpm spec file, which specified additionally the arguments ./configure --host=i686-suse-linux --build=i686-suse-linux --target=i686-suse-linux. This is the target name which is not supported by the shipped configure and needs to be overridden by the --build=i686-pc-linux-gnu. However, when Christian Rauch added --build=i686-pc-linux-gnu, then the --build and --host/target were different, so there was an error message about "cross compiling". The final workaround for this particular case where build, host, target are all given, is to use all three with the working target name: ./configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=i686-pc-linux-gnu For all normal users that do not deal with a rpm spec file, the described ./configure --build=i686-pc-linux-gnu is still sufficient. Christian Seems to, i have to get much more deeper into rpm-building. Thanks, Christian for helping me in this and many other cases since i started building. All others, keep up the good work and thanks for such a great piece of software! And yes, it builds fine now and starts without any error! Regards, Christian Rauch ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Error building gnucash 1.8.12 on OpenSuSE 10.0
Christian Stimming schrieb: As it turns out, the described workaround is still correct, even for OpenSuSE 10.0. In this particular case, ./configure was invoked from a rpm spec file, which specified additionally the arguments ./configure --host=i686-suse-linux --build=i686-suse-linux --target=i686-suse-linux. This is the target name which is not supported by the shipped configure and needs to be overridden by the --build=i686-pc-linux-gnu. However, when Christian Rauch added --build=i686-pc-linux-gnu, then the --build and --host/target were different, so there was an error message about "cross compiling". The final workaround for this particular case where build, host, target are all given, is to use all three with the working target name: ./configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=i686-pc-linux-gnu For all normal users that do not deal with a rpm spec file, the described ./configure --build=i686-pc-linux-gnu is still sufficient. Christian But still one question remains just for my understanding. Why is the argument --build sufficient for 1.8.11, but 1.8.12 needs all three on the same building system without any changes? Thanks, Rauch Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Changelog - (end)
Neil, I can compile gnucash with your recent changes, but the compiled program refuses to read my data file. My 83,412 line data file yields 183,810 errors in the form: namespace error : Namespace prefix on is not defined And then a final error of: element gnc-v2: Schemas validity error : Element 'gnc-v2': No matching global declaration available for the validation root. David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Updated .pot file for gnome2 branch
Hi, > > Having seen that your continuous work is driving Gnucash to 2.0 alphas, > > I thought I should start translating missing strings to spanish. > Hmm, maybe it's a tad early. Are the GUI and strings changing much yet? > > I've just checked out gnome2 branch from CVS, but it doesn't > > even ./configure on my Debian Sarge (I don't have much time, sorry). > 1. That needs to be ./autogen.sh not ./configure (See README.cvs) Done (otherwise there was no ./configure). ;) I will read README.cvs next time, thanks for the hint :) > 2. You will need updated libraries - including devel libraries - compared to > 1.8 (see http://code.neil.williamsleesmill.me.uk/gnucashlibs.html ) > > 3. You may well need Debian testing (etch) rather than stable (sarge). That > involves an 'apt-get dist-upgrade testing' I don't want to update my workstation to testing, this is the main problem. I'll use a spare machine to install Debian unstable or some Ubuntu or Red Hat, but I will need some time to do it :) > > just to start working on the translation for the first alpha? (indeed, > > I'll have to manage to build gnucash2 sooner or later to test the > > translation) > True. Currently, you may need Debian unstable to build G2. You will certainly > need goffice as the version of libgsf in etch causes problems for G2. > Maybe best to come back to this when you have more time and when a few more > things have been ironed out. I'm just getting on track, as it is some time that I don't update the spanish translation. Anyway, if you think that it is too early to start with this, I can wait (waiting is much easier than working!! ;) ). Thank a lot, Eneko. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: autogen.sh / Now really fix old typo
"Peter O'Gorman" <[EMAIL PROTECTED]> writes:
> Christian Stimming wrote:
> | if test x$AUTOCONF = x; then AUTOCONF=autoconf; fi
> | $AUTOCONF
>
> : ${AUTOCONF=autoconf}
This is portable...
--> /bin/sh
$ : ${AUTOCONF=autoconf}
$ echo $AUTOCONF
autoconf
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
[EMAIL PROTECTED]PGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Tired of the usual gnucash look ?
Just try LANG=ar_AE ./gnucash to see how it looks with an RTL layout By the way I'm not sure all of gnucash works as expected in this case... Didier. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: autogen.sh / Now really fix old typo
Christian Stimming <[EMAIL PROTECTED]> writes: > Derek Atkins schrieb: >>> Nevertheless this whole autogen.sh file is IMHO quite a >>> mess. Personally I would now prefer a much simplified version, >>> e.g. like this one >>> http://cvs.sourceforge.net/viewcvs.py/ktoblzcheck/ktoblzcheck/autogen.sh?rev=1.5&view=markup >> I think it would be nice if we had " || exit 1" at the end of every >> line. > > Alternatively I've added > > trap exit ERR Unfortunately it's not portable: --> uname -a SunOS kikki.mit.edu 5.10 Generic sun4u sparc SUNW,Sun-Blade-100 --> /bin/sh $ trap exit ERR trap: bad trap Granted, the configure script sort of already requires bash, but I'd prefer not to perpetuate that if we can avoid it. (Configure requires it because of intltool.m4, not because of us explicitly). -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Problems with accounts in gnucash/accounts
The accounts used by the gnucash druid are broken in many locales, including fr_FR, fr_FR.UTF-8, de_DE.UTF-8, de_DE... The problem is that gnucash expects them to be in UTF-8. On locale with ISO-8859-1 charset, if you run the following script, the druid works again: for i in *-xea do mv $i $i.iso cat $i.iso | iconv -f ISO-8859-1 -t UTF-8 > $i done However, I'm not sure it's a good idea, since the files will not respect the locale indicated by their directories. The problem lies more in the way these files are read. It's probably not by libxml2. Otherwise: libxml2 would certainly have handled the conversion correctly I also tried to specify the codeset in the XML header, but that didnt fix the problem. How should we handle this ? Didier. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Changelog - (end)
On Thursday 20 October 2005 8:01 pm, David Hampton wrote:
> Neil,
>
> I can compile gnucash with your recent changes, but the compiled program
> refuses to read my data file.
> namespace error : Namespace prefix on is not defined
> And then a final error of:
> element gnc-v2: Schemas validity error : Element 'gnc-v2': No matching
> global declaration available for the validation root.
>
> David
Check your /tmp/gnucash.trace - it looks like the directory being set for the
location of the gnc-backend-file library is incorrect. This is set using the
new file, gncla-dir.h.in made into gncla-dir.h by make. It should point to
the ${libdir}.
Any mention of a schema in relation to the XML means that gnucash is trying to
open the file using QSF instead.
I know you usually do a make distclean and I did set gncla-dir.h to be removed
by make distclean. Thereagain, the location of libgnc-backend-file hasn't
changed this commit - only the file setting the location.
You should find an assertion failure from stat in the trace file, followed by
an assertion failure from qof_load_backend_library. It sounds like GNC_LIBDIR
is not the correct location. How does the content of src/engine/gncla-dir.h
compare to the actual location of libgnc-backend-file.la | so etc. ?
I did a clean build (CVS checkout, applypatch, build) before committing this
patch and my gncla-dir.h contains the correct setting: #define GNC_LIBDIR
"/opt/local/g2/lib" in my case. That then gets fed to gnc-engine.c:
g_return_if_fail((qof_load_backend_library
(GNC_LIBDIR, GNC_LIB_NAME, GNC_LIB_INIT)));
(the other macros are defined in gnc-engine.c itself.)
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgprkpGJ7v9qd.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Problems with accounts in gnucash/accounts
On Thursday 20 October 2005 9:52 pm, Didier Vidal wrote: > The accounts used by the gnucash druid are broken in many locales, > including fr_FR, fr_FR.UTF-8, de_DE.UTF-8, de_DE... > > The problem is that gnucash expects them to be in UTF-8. AFAICT, gnucash still makes no assumptions about the encoding or expects any particular encoding in the file. > On locale with ISO-8859-1 charset, if you run the following script, the > druid works again: > for i in *-xea > do > mv $i $i.iso > cat $i.iso | iconv -f ISO-8859-1 -t UTF-8 > $i > done What about converting to fr_FR or de_DE ? (and putting that in the encoding as fr-fr and de-de respectively). > However, I'm not sure it's a good idea, since the files will not respect > the locale indicated by their directories. Have you tried converting each directory to the intended locale instead of UTF-8? > The problem lies more in the way these files are read. It's probably not > by libxml2. Otherwise: > libxml2 would certainly have handled the conversion correctly Maybe not if the XML doesn't state the encoding itself. libxml2 does handle XML content as UTF-8 internally (which is why we made the assumption above). > I also tried to specify the codeset in the XML header, but that didnt > fix the problem. Note that XML doesn't have the same syntax for encoding specifiers - the underscore is generally a hyphen and case is not important. Which codeset? How are you testing the files? Did you set the XML encoding attribute to the codeset for the locale directory of that file? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgprx2sBY6f0K.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Problems with accounts in gnucash/accounts
Le jeu 20/10/2005 à 23:15, Neil Williams a écrit : > On Thursday 20 October 2005 9:52 pm, Didier Vidal wrote: > > The accounts used by the gnucash druid are broken in many locales, > > including fr_FR, fr_FR.UTF-8, de_DE.UTF-8, de_DE... > > > > The problem is that gnucash expects them to be in UTF-8. > > AFAICT, gnucash still makes no assumptions about the encoding or expects any > particular encoding in the file. Lets say that the GNOME GUI expects to receive utf-8 data then. > > > On locale with ISO-8859-1 charset, if you run the following script, the > > druid works again: > > for i in *-xea > > do > > mv $i $i.iso > > cat $i.iso | iconv -f ISO-8859-1 -t UTF-8 > $i > > done > > What about converting to fr_FR or de_DE ? > (and putting that in the encoding as fr-fr and de-de respectively). I run the script on the fr_FR directory. I'm not sure to understand your question. > > > However, I'm not sure it's a good idea, since the files will not respect > > the locale indicated by their directories. > > Have you tried converting each directory to the intended locale instead of > UTF-8? No. I'm not sure it's a good idea... There is no waranty that each locale has its utf8 counterpart. > > > The problem lies more in the way these files are read. It's probably not > > by libxml2. Otherwise: > > libxml2 would certainly have handled the conversion correctly > > Maybe not if the XML doesn't state the encoding itself. libxml2 does handle > XML content as UTF-8 internally (which is why we made the assumption above). > > > I also tried to specify the codeset in the XML header, but that didnt > > fix the problem. > > Note that XML doesn't have the same syntax for encoding specifiers - the > underscore is generally a hyphen and case is not important. I'll check this. > > Which codeset? How are you testing the files? > > Did you set the XML encoding attribute to the codeset for the locale > directory > of that file? To the file header ( I'll double check I didn't make a mistake in this test and email back to the list. Didier. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Problems with accounts in gnucash/accounts
Forget my email. Adding the codeset works. I'll send a patch for the fr_FR directory, and the script I used. Didier. Le jeu 20/10/2005 à 23:27, Didier Vidal a écrit : > Le jeu 20/10/2005 à 23:15, Neil Williams a écrit : > > On Thursday 20 October 2005 9:52 pm, Didier Vidal wrote: > > > The accounts used by the gnucash druid are broken in many locales, > > > including fr_FR, fr_FR.UTF-8, de_DE.UTF-8, de_DE... > > > > > > The problem is that gnucash expects them to be in UTF-8. > > > > AFAICT, gnucash still makes no assumptions about the encoding or expects > > any > > particular encoding in the file. > Lets say that the GNOME GUI expects to receive utf-8 data then. > > > > > On locale with ISO-8859-1 charset, if you run the following script, the > > > druid works again: > > > for i in *-xea > > > do > > > mv $i $i.iso > > > cat $i.iso | iconv -f ISO-8859-1 -t UTF-8 > $i > > > done > > > > What about converting to fr_FR or de_DE ? > > (and putting that in the encoding as fr-fr and de-de respectively). > I run the script on the fr_FR directory. I'm not sure to understand your > question. > > > > > > However, I'm not sure it's a good idea, since the files will not respect > > > the locale indicated by their directories. > > > > Have you tried converting each directory to the intended locale instead of > > UTF-8? > No. I'm not sure it's a good idea... There is no waranty that each > locale has its utf8 counterpart. > > > > > > The problem lies more in the way these files are read. It's probably not > > > by libxml2. Otherwise: > > > libxml2 would certainly have handled the conversion correctly > > > > Maybe not if the XML doesn't state the encoding itself. libxml2 does handle > > XML content as UTF-8 internally (which is why we made the assumption above). > > > > > I also tried to specify the codeset in the XML header, but that didnt > > > fix the problem. > > > > Note that XML doesn't have the same syntax for encoding specifiers - the > > underscore is generally a hyphen and case is not important. > I'll check this. > > > > Which codeset? How are you testing the files? > > > > Did you set the XML encoding attribute to the codeset for the locale > > directory > > of that file? > To the file header ( > I'll double check I didn't make a mistake in this test and email back to > the list. > > Didier. > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Problems with accounts in gnucash/accounts
On Thursday 20 October 2005 10:27 pm, Didier Vidal wrote: > Lets say that the GNOME GUI expects to receive utf-8 data then. It should too, because libxml2 only works in UTF-8 internally. As gnucash doesn't change the encoding itself, libxml2 outputs UTF-8 which is passed to the GUI - as long as libxml2 is told the correct encoding in the first place. > > > However, I'm not sure it's a good idea, since the files will not > > > respect the locale indicated by their directories. > > > > Have you tried converting each directory to the intended locale instead > > of UTF-8? > > No. I'm not sure it's a good idea... There is no waranty that each > locale has its utf8 counterpart. libxml2 will deal with that, what matters is that libxml2 is told the correct encoding for the incoming file. It will assume UTF-8 if there is no encoding attribute in the XML header. Then you WILL get problems if no UTF-8 counterpart exists. As long as the encoding attribute matches the iconv converted encoding, libxml2 should sort it all out for us. If either of those is wrong, we get problems. > > Note that XML doesn't have the same syntax for encoding specifiers - the > > underscore is generally a hyphen and case is not important. > > I'll check this. Ooops. I'm thinking of not . Ignore that. > > Did you set the XML encoding attribute to the codeset for the locale > > directory of that file? > > To the file header ( That would only work if the content of that file was ISO-8859-1 - but if that is done, it should "just work". -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpvVMq5FYc0A.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Changelog - (end)
On Thu, 2005-10-20 at 21:55 +0100, Neil Williams wrote:
> Check your /tmp/gnucash.trace - it looks like the directory being set for the
> location of the gnc-backend-file library is incorrect. This is set using the
> new file, gncla-dir.h.in made into gncla-dir.h by make. It should point to
> the ${libdir}.
file qofbackend.c: line 410 (qof_load_backend_library):
assertion `(stat(fullpath, &sbuf) == 0)' failed
file gnc-engine.c: line 102 (gnc_engine_init):
assertion `(qof_load_backend_library (GNC_LIBDIR,
GNC_LIB_NAME, GNC_LIB_INIT))' failed
Oops. gncla-dir.h has
#define GNC_LIBDIR "/opt/gnucash/g2/lib/gnucash"
While the library is here:
/opt/gnucash/g2/lib/libgnc-backend-file.so
Do you use --opt-style-install? I don't.
David
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Problems with accounts in gnucash/accounts
On Thu, 2005-10-20 at 22:51 +0100, Neil Williams wrote: > On Thursday 20 October 2005 10:27 pm, Didier Vidal wrote: > > Lets say that the GNOME GUI expects to receive utf-8 data then. > > It should too, because libxml2 only works in UTF-8 internally. As gnucash > doesn't change the encoding itself, libxml2 outputs UTF-8 which is passed to > the GUI - as long as libxml2 is told the correct encoding in the first place. Libxml2 only works in utf-8 internally. Gtk-2 and Gnome-2 also only work internally in utf-8. If gnucash v2.0 doesn't work internally purely in utf-8 then that's a bug and should be reported/fixed. (Not counting the few routines that must convert to/from a user's non utf-8 locale, like the LANG parsing routines.) David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
error building 1.8.12 on gentoo
Since seemant has not gotten a new ebuild out yet, I tried building it with the 1.8.11 ebuild but it failed. quick specs: big_squirt linux-2.6.13-gentoo-r3 # emerge info Portage 2.0.53_rc5 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.5-r1, 2.6.11-gentoo-r6n i68 6) = System uname: 2.6.11-gentoo-r6n i686 AMD Athlon(tm) Gentoo Base System version 1.6.13 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.5, 2.4.2 sys-apps/sandbox:1.2.13 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O2 -pipe -w" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/ defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -O2 -pipe -w" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" LANG="en_CA.UTF-8" Unset: ASFLAGS, CTARGET, LC_ALL, LDFLAGS, LINGUAS relevant USE flags: +nls, -postgres, +ofx, -hbci, -quotes, -chipcard * some emerge output * 04 >>> emerge (1 of 1) app-office/gnucash-1.8.12 to / 05 >>> md5 files ;-) gnucash-1.8.12.ebuild 06 >>> md5 files ;-) files/digest-gnucash-1.8.12 07 >>> md5 src_uri ;-) gnucash-1.8.12.tar.gz 08 >>> md5 src_uri ;-) gnucash-docs-1.8.5.tar.gz 09 * bitmap-fonts support is enabled in virtual/x11, continuing... 10 >>> Unpacking source... 11 >>> Unpacking gnucash-1.8.12.tar.gz to /var/tmp/portage/gnucash-1.8.12/work 12 >>> Unpacking gnucash-docs-1.8.5.tar.gz to /var/tmp/portage/gnucash-1.8.12/work 13 >>> Source unpacked. 14 * Running elibtoolize in: gnucash-1.8.12 15 * Applying portage-1.4.1.patch ... 16 * Applying relink-1.4.1.patch ... 17 * Applying sed-1.4.0.patch ... 18 * Applying uclibc-conf-1.2.0.patch ... 19 * econf: updating gnucash-1.8.12/config.guess with /usr/share/gnuconfig/config.guess 20 * econf: updating gnucash-1.8.12/config.sub with /usr/share/gnuconfig/config.sub 21 * econf: updating gnucash-docs-1.8.5/config.guess with /usr/share/gnuconfig/config.guess 22 * econf: updating gnucash-docs-1.8.5/config.sub with /usr/share/gnuconfig/config.sub 23 ./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-etags --enable-ctags --enable-compile-warnings=no --disable-error-on-warning --disable-sql --enable-nls --enable-ofx --disable-hbci --build=i686-pc-linux-gnu ... 004851 make[3]: Nothing to be done for `all-am'. 004852 make[3]: Leaving directory `/var/tmp/portage/gnucash-1.8.12/work/gnucash-1.8.12/accounts' 004853 make[2]: Leaving directory `/var/tmp/portage/gnucash-1.8.12/work/gnucash-1.8.12/accounts' 004854 make[2]: Entering directory `/var/tmp/portage/gnucash-1.8.12/work/gnucash-1.8.12' 004855 rm -f make-gnucash-patch.tmp 004856 sed < make-gnucash-patch.in > make-gnucash-patch.tmp \ 004857 -e 's:@-PERL-@:/usr/bin/perl:g' 004858 chmod +x make-gnucash-patch.tmp 004859 mv make-gnucash-patch.tmp make-gnucash-patch 004860 rm -f make-gnucash-potfiles.tmp 004861 sed < make-gnucash-potfiles.in > make-gnucash-potfiles.tmp \ 004862 -e 's:@-PERL-@:/usr/bin/perl:g' 004863 chmod +x make-gnucash-potfiles.tmp 004864 mv make-gnucash-potfiles.tmp make-gnucash-potfiles 004865 make[2]: Leaving directory `/var/tmp/portage/gnucash-1.8.12/work/gnucash-1.8.12' 004866 make[1]: Leaving directory `/var/tmp/portage/gnucash-1.8.12/work/gnucash-1.8.12' 004867 make: *** No rule to make target `gnucash-design'. Stop. 004868 004869 !!! ERROR: app-office/gnucash-1.8.12 failed. 004870 !!! Function src_compile, Line 94, Exitcode 2 004871 !!! make gnucash-design failed 004872 !!! If you need support, post the topmost build error, NOT this status message. 004873 -- Brian <[EMAIL PROTECTED]> ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
