reed@reedmedia.net said:
> I am the maintainer for this package. 
> I updated my local pkgsrc for this a while ago, but never committed.

Sorry, didn't want to step onto your feet.
I had this in my tree for a while too, and since it worked well, and
noone else cared to update, and a "cvs update" output larger than
the terminal history isn't helpful I just committed it.

> I never committed because it requires gcc 3.x and I never figured out how
> to get it do build correctly with gcc 2.95.x

While C code just having some decalrations inside function bodies
is easy to fix, C++ code isn't worth investing lots of time into imho.
Compiling g++3 on a NetBSD-1.6 system in an investment which has to
be done only once. If that saves temporary hacks to a lot of pkgs
it is worth the effort.

> And if using gcc 3.x, then
> some of the dependency libraries must be build with gcc 3 also.

The sad fact is that while C code is requred to meet well-defined
ABI standards, C++ code is not. C++ code compiled by gcc2 and gcc3
is not compatible. And because there is no mechanism to distinguish
gcc2 and gcc3 compiled C++ libraries at (dynamic) link time we have to
make sure all C++ code upwards and downwards the dependency tree is
compiled with the same compiler.

For me, this means that USE_LANGUAGES=c++ should imply GCC_REQD=3.3,
except perhaps for singular pkgs without any ABI interactions.

(This remembers me of pre-2.0 times when we had a mix of GNUpth and
native-pthread using pkgs in the tree in the hope that the two worlds
could be kept separate. This didn't work at all -- Python extensions
in particular, loaded dynamically, caused both thread libraries loaded
into one process.)

> It also needs:
> BUILDLINK_DEPENDS.boehm-gc+=	boehm-gc>=6.4

Thanks, I'll care about it in a minute.

best regards
Matthias