🚀 go-pugleaf

    So then, how does one get around an error like this from g++
    (gcc version 2.96 20000731 (Linux-Mandrake 8.0 2.96-0.48mdk)

g++ -c -I/usr/include/X11 -I/usr/X11R6/LessTif/Motif1.2/include -I/usr/include -I../../include/base -I../../include/x -fwritable-strings -fno-strict-prototype -Dwx_motif -ggdb -DDEBUG='0' -w  -o objects_motif/wb_utils.o wb_utils.cpp

wb_utils.cpp:168: declaration of `int strcasecmp (const char *, const char *)' throws different exceptions
/usr/include/string.h:273: than previous declaration `int strcasecmp 
(const char *, const char *) throw ()'
wb_utils.cpp:169: declaration of `int strncasecmp (const char *, const char *, unsigned int)' throws different exceptions
/usr/include/string.h:277: than previous declaration `int strncasecmp 
(const char *, const char *, unsigned int) throw ()'

    This is from an attempt to compile wxwin version 1.68e on
    Mandrake 8.0 with g++ 2.96.  This package used to compile
    without any problems whatsoever on Mandrake 7.02 with g++
    2.95.3.

    I really am after help getting this to complile, I'm not just
    trying to complain about the compliler.

    Thanks....



In article <8T4u7.32632$2H2.2584657@e3500-atl1.usenetserver.com>,
 s <srlinuxx@linuxfreemail.com> writes:
> What a timely question as Civileme just posted an answer to a
> very similar question.  I will quote it here for you:
> 
> "Well, gcc 2.95.3 won't compile Python and Perl where they can
> pass all their own regression tests.
>
> 2.96 (ours) is a much later pruning from the development tree
> than RH, and not the same compiler at all.  Since gcc team
> had abandoned the number we took it for the thing we made of
> about 350 patches that just compiles reliable code.  It is very
> strict so it does not compile junk code or where the programmer
> made assumptions about the loading of standard headers by
> default, but we have used it and patched it for more than 9
> months and we trust it.
>
> gcc 3.01 we have been testing.  The results were hopeful,
> but not yet up to 95% of the performance of 2.96, which is
> basically our performance bar, so we included it in the distro
> as well.  We are even using 2.96 (our version) to compile
> the kernel, and the kernel is passing the stress suite on
> big and little machines.  (We use a souped-up version of
> Cerberus).  We won switch until we find another compiler in
> the gcc series that performs almost as well as 2.96.  C source
> will be compatible, of course, C++ source has been changing
> with every new release, so we are no more incompatible with
> that source than the others using 2.95.2 or 2.95.3.  Binaries
> between the 2.9x and 3.xx series are incompatible, of course,
> bt again we are not in any worse situation than anyone else.
> Also, Perl and Python pass all their regression tests under
> 2.96.
> 
> Civileme"

--
Unless otherwise noted, the statements herein reflect my personal
opinions and not those of any organization with which I may be affiliated.