> The problem described in port-pmax/6776 is much more widespread than is
> described there, and the condition described will cause g++ to fail on ALL
> of the following ports from a "fresh" install (i.e. no libg++ left over from
> an old 1.3.x upgraded system):
> 
>   All m68k ports
>   i386
>   pmax
>   sparc
> 
> (These are the ports that use the in-tree gcc 2.7.2.2+myc*.)
> 
> Note that "c++" is NOT affected -- it is "g++" that is affected, which tries
> to link in "libg++" when called as "g++" (it checks argv[0] for this).
> 
> A pullup, missed for 1.3.3, has been submitted for the soon-upcoming 1.3.4
> patch release.  A source patch, which can be used to recompile a working
> g++, is available at:
> 
> ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-1.3.3/source/patches/patch-1.3.3-broken-g++.asc
> 
> Port maintainers, I strongly suggest that you build a new g++ binary and
> make it available in /pub/NetBSD/arch/<archname>.


I suggest g++ 2.8.[12] plus the threads exception patches in the FreeBSD
port.

I don't know how married to the idea of kernel threads as discrete
kernel schedulable entities NetBSD is, but if you plan on having
user space components to the scheduler at all, and you don't want
to have to eat the overhead for wrapped calls in the case of
unthreaded programs, then egcs doesn't cut it.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.