On Friday 10 January 2014 17:41:15 Gary Bilkus wrote: > On 10/01/2014 15:03, John Ralls wrote: > > On Jan 9, 2014, at 11:13 PM, Gary Bilkus <m...@gary.bilkus.com> wrote: > >> Well, interestingly enough, the problem is not directly with the > >> compiler optimizer. It's with the configure test for strncasecmp. > >> This test fails on mingw in its current incarnation because guile > >> uses a standard test for the function, but on mingw strncasecmp is > >> actually a cpp definition. As a result, guile is compiled with > >> #HAVE_STRNCASECMP unset, and so guile tries to create its own > >> version in read.c Now if you compile with no optimization, the > >> compiler notices that read.c is attempting to create this with a > >> different signature and bombs out. However, with optimisation on, > >> the code compiles for some reason, and then fails to run properly. > >> > >> So there seem to be two problems: one in configure for guile and/or > >> the standard configure macros on mingw, the other in the compiler. > >> Fortunately, there's a very easy although ugly workaround, which > >> is to add an echo "#define HAVE_STRNCASECMP" >>config.h > > > > Would adding -DHAVE_STRNCASECMP to $CFLAGS work? It's a bit cleaner > > than echoing a #define into the config header. Better yet, > > sometimes there's a variable that can be defined on the configure > > command line -- perhaps $ac_have_strncasecmp -- to force configure > > to do the right thing.> > >> in install-impl.sh > >> just after the guile configure and before the make > >> > >> I've incorporated this fix into my downloadable file of fixes as > >> referred to on the wiki page I updated. More as and when I find > >> any further issues. As always, feedback or other experiences > >> welcome.> > > Regards, > > John Ralls > > I agree that the configure commandline change would be cleaner, and if > I can find out what to do I'll change my fix. > > I disagree that a CFLAGS define is cleaner. With my solution the > define is in the right file, even if it gets there for the wrong > reason. That way, it guarantees not to affect any compilation which > doesn't involve including config.h, which saves having to check for > any unexpected consequenses elsewhere. > Gary > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Gary, Thanks for all your updates. Today I found some time to check which of your fixes I should still add to my windows branch, but got lost in your patch. It looks like you are generating a patch to be applied to the current trunk branch, including all the separate commits from my branch. Unfortunately that makes it hard if not impossible to see only the changes needed on my branch. It's not the intention to apply such a large patch one day to current trunk. Instead my branch will be merged in eventually (likely after the 2.6 branch is generated and certainly not before the dist part and build server scripts are also fixed). So can you extract only the changes that still need to be applied to my branch please ? Ideally split up in small patches per topic (fix -no-undefined, fix guile's str_ncase_comp, ...). That way we generate clean and readable history in the repository. You may want to set up your own clone of the git repository [1] as git can be very helpful in generating such patches. Thanks, Geert [1] http://wiki.gnucash.org/wiki/Git#Non-Committers _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
