Bugzilla Bug 48523

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 an attachment (id=30296) [details]
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.