I'm putting this up as a reminder. I know what the problem is: http://gcc.gnu.org/onlinedocs/gcc/Name-lookup.html but I haven't gotten around to fixing it yet. g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DUSE_AUTOTOOLS -DUNIX -DSWICU_DATA=\"/usr/lib/sword/1.5.7_icu_2.8\" -D_ICU_ -O3 -march=pentium4 -funroll-loops -pipe -ftemplate-depth-25 -DCURLAVAILABLE -MT treekey.lo -MD -MP -MF .deps/treekey.Tpo -c ../src/keys/treekey.cpp >/dev/null 2>&1 distcc[8083] ERROR: compile on localhost failed In file included from ../include/swconfig.h:31, from ../include/localemgr.h:28, from ../src/keys/versekey.cpp:21: ../include/multimapwdef.h: In member function `T& sword::multimapwithdefault<Key, T, Compare>::getWithDefault(const Key&, const T&)': ../include/multimapwdef.h:15: error: there are no arguments to `end' that depend on a template parameter, so a declaration of `end' must be available ../include/multimapwdef.h:15: error: (if you use `-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated) ../include/multimapwdef.h: In member function `T& sword::multimapwithdefault<Key, T, Compare>::operator[](const Key&)': ../include/multimapwdef.h:22: error: there are no arguments to `end' that depend on a template parameter, so a declaration of `end' must be available make[2]: *** [versekey.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... mv -f .libs/treekey.lo treekey.lo make[2]: Leaving directory `/var/tmp/portage/sword-1.5.7/work/sword-1.5.7/lib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/sword-1.5.7/work/sword-1.5.7' make: *** [all] Error 2 If you do use -fpermissive, any applications compiled against the sword libraries will segfault or return errors.
also this may have something to do with: http://gcc.gnu.org/ml/gcc-bugs/2003-07/msg01815.html
try append-flags -fno-unit-at-a-time -fpermissive maybe?
append-flags -fno-unit-at-a-time -fpermissive programs still segfault though they will build; programs built with the libraries will fail to run.
Created attachment 30296 [details, diff] Patch to fix compilation error This fixes compilation under GCC 3.4.0, and things don't segfault. This is good :-)
And of course bibletime and gnomesword fail when sword is compiled with this patch. So does diatheke with certain params. We're definitely on the right track now though, thanks :).
Seeing as this patch is tested and working (even though bibletime and gnomesword are seperately broken) shouldn't this be in portage by now? Not wanting to be pushy, just wondering what the reason is. Still working on gnomesword, it's my last bastion of hopelessness!
I'm having some compiler trouble here. Tomorrow I'll test the patch with gcc-3.3.3 and if bibletime/gnomesword/diatheke work correctly, your patch will be put in. If bibletime/gnomesword/diatheke do not work, there's really no point in applying this patch, as it'll just break everything. It's a temporary fix for *compiling* on gcc-3.4. The programs themselves are still totally botched. There has to be some other thing we're missing in the sword package that's causing mass breakage, and I'd like to try to find that first.
If we get a working patch send it upstream to the sword developers I know that gcc3.4 issues plague cvs too.
The gcc-3.4 compile-time patch is now in portage BUT I don't want to close this bug. Getting a program to compile and getting a program to run correctly are two different things. SWORD programs provided by this package are still totally b0rked, and we need to try to get them fixed.
Jon, this patch will allow compilation on GCC 3.4.0. Further to that, gnomesword will compile, link against and run nicely if you use GCC 3.3.3 for it, even if you use 3.4.0 for sword itself. So the patch is valid, unless I'm missing something big; the broken packages are gnomesword, bibletime and diatheke, not sword itself. Am I right?
I think you're right. None of the applications would compile against a gcc-3.4 compiled sword on my computer because....I had bad ram! I'm now on a working computer and everything seems to be going good. Thanks for the patch, sorry for all the confusion, and if anyone offers you a cheap compaq laptop, check the ram because gcc will do funny things with b0rked ram ;).
For what it's worth, I've moved hell and high water to try to get gnomesword to compile and not segfault using GCC 3.4.0. I can get it to compile with no problems, but running it is a different matter entirely. And yet, when I drop back to 3.3.3 (this is the only reason I still have 3.3.3 on my system - in case I make another botched attempt at a gnomesword patch and need to recompile vanilla gnomesword) it works flawlessly. How annoying!
Reopening bug- there is still a problem with the sword library itself under gcc 3.4. The other programs fail because of the sword header files being messed up. EDIT: CFLAGS > -O0 seem to mess it up; can you tell me if compiling sword without any -O optimiazations causes things to magically work correctly?
Weird! Certainly, I'll take a look.
Well bugger me with a spade. Compiling both sword and gnomesword with -O0 allows the programme to run. I'll investigate further and see if I can find out which flag is killing things.
Well I have no idea. How strange. I'm using a CVS ebuild for both SWORD and GnomeSWORD and all is well! I'm not sure whether this is due to updated GCC or update SWORD/GnomeSWORD - all I know is that it works! The current "stable" versions still don't work, however. The ebuilds are available in my overlay - if you want to use CVS rather than making your own snapshot and bumping the version, you'll have to get sword-cvs, gnomesword-cvs and sword-modules. Enjoy... http://home.jesus.ox.ac.uk/~rmoss/portage/local/app-text/
we'll have to wait for the sword-1.5.8 release and frontend updates for this one. Bibletime does not compile with a cvs snapshot of sword.
*** Bug 51226 has been marked as a duplicate of this bug. ***
Finally fixed in portage.
