1) __cxa_atexit - This can be worked around (GCC is patched to avoid using it), but it's fugly and really should be fixed. Conveniently, in -current, it is (after a PR requesting it). Can be backported, though I'm not entirely sure I'm comfortable with that, given how it affects every single C++ program ever compiled.
i don't see why it would really be such a problem to backport this. 2) ftw()/nftw() - This will be going into -current in a few days (and replace the workaround jftw package). It really belongs in libc, not in a separate library, and it will be there. Backporting this should be fairly trivial, as it's completely new code that doesn't really interact iwth anything else except for calling the pts suite. APT absolutely must have this to build, however. (And it's a POSIX requirement, too.) this should definately go into the netbsd libc. 3) POSIX threads - This is a killer; tcl8.4 *must* be threaded, and is breaking horribly with GNU pthreads (both 1.x and 2.x). Python depends on TCL; a whole *lot* of things depend on python (or TCL), or on something that does. The threading changes are so extensive that it's probably more or less implausible to backport them to a 1.6 tree, since they were started on post-1.6-release code. actually the threading changes were started a couple of years ago :) you are 100% correct that attempting to backport would be a complete waste of time, however. 4) Not-really-an-issue - i386 SMP. There is a working release of the i386/SMP branch against 1.6(.1), so it's by no means crucial, but -current supports this in the core code, and it would be nice to support it where we can (but an SMP patch is probably sufficient, if staying on 1.6.1). also - sparc SMP only exists in -current. So the question is - should I/we bail on trying to build a release on 1.6.x, and do one from -current instead? If it weren't for the POSIX threads problem, I'd consider it, but that change is so invasive *and* pervasive that it affects basically every application on the system in one way or another, and it is COMPLETELY incompatible with anything compiled against GNU pth pthreads - so the transition to 1.7 would be an utter and royal pain in the arse to manage, and/or require a flag day (remove evreything in the archive, upload new stuff). I can do flag days on my archive easily enough (and have been considering it, since the build environment is currently far cleaner than it used to be), but it will be a very bad sign to the ftpmasters if we have to do it once we're in the main archive. Personally, I vote for rebuilding based on -current; however, since I'm far from the only person doing this, and I'd like to have some chance of not crossing over each other's work, I'd like to hear other opinions. the alternative is to get a modern kernel & libpthread (& libc? i'm not sure) but to leave the rest of userland alone. then again i've been running netbsd-current systems almost exclusively for nearly 10 years (i have run some work/customer machines with releases... but never my own.) -current works well nearly all of the time. if you pick a snapshot, try it out for a while and if it is good, use it. i could expand more if you want :-) .mrg.
