From octave-maintainers-request at bevo dot che dot wisc dot edu Fri Nov 22 15:35:42 2002
Subject: Require gcc 3.2 (or similar)?
From: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
To: octave-maintainers mailing list <octave-maintainers at bevo dot che dot wisc dot edu>
Date: Fri, 22 Nov 2002 15:35:35 -0600

How much trouble would it cause to assume that people have gcc 3.2 (or
some other compiler) that can handle the STL in a reasonable way?

I just tried adding something as simple as

  std::set <std::string>

and gcc 2.95.4 complained at link time with some very long error
messages like:

../src/liboctinterp.a(variables.o)(.text+0x10ef): In function `Fmark_as_text_function(octave_value_list const &, int)':
/usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3/stl_set.h:133: undefined reference to `_Rb_tree<basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >, basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >, _Identity<basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> > >, less<basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> > >, allocator<basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> > > >::insert_unique(basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> > const &)'

which doesn't help me much.  I think life is too short to waste time
trying to decipher something like that and then try to guess how I
might coerce the compiler to instantiate the proper methods, but if
someone can tell me that there is a simple way to avoid this problem
that will work on all platforms, I'd be willing to continue trying to
support 2.95.x.  Otherwise, unless there are other serious problems
with requiring 3.2 (or a similarly capable compiler) then I think it's
time we switch.

If we can't switch, then I'll have to find some other way to do what I
want without using the std::set template, and that will probably mean
dredging up some obsolete libg++ code (or similar) which we will
eventually want to replace with STL containers anyway.

Comments?

Thanks,

jwe