Njamd v0.7 Release Notes (Euphemism for "BUGS and Which OS's Suck" :)

The front end is ncurses-only and pretty sloppy. If anyone wants to write a
better one, or a GTK version, be my guest! The groundwork is already layed for
you. Have a look at docs/DESIGN for an overview of the system.

Portability chart:

Platform		Ver		Features
~~~~~~~~		~~~		~~~~~~~~	
Linux/x86		2.0		All
Linux/x86		2.2		All
Linux/MIPS		2.2		FAIL :(
Solaris/Sparc		2.6		No static code stack trace
Solaris/Ultra64		2.7		          "
FreeBSD/x86		3.3		No MT
FreeBSD/x86		4.0		No MT
NetBSD/x86		1.4P		No MT      
OpenBSD/x86		2.6     	  " + No PRELOAD  
OpenBSD/Sparc		2.6  		  " +   " + No static code stack trace

Linux/MIPS is going to have to be filed under unsupported. I broke something
MIPS-related and the MIPS system I have access to is horribly out of date and 
is missing key development tools (gdb, g++), so it's a big pain in the ass to 
perform any debugging. If anyone has an up-to-date Linux/MIPS system and would
like to give me an temporary account, I'd be happy to fix it. Same goes for 
any other platform.

When programs are compiled with -fomit-frame-pointer they will not have any
return address information in them (and will segfault in return_address in
util.c). The gcc manpages explicitly warn not to define this flag if you are
planning on debugging, unfortunately at least one library (libfftw) defines
this optimization. If you want to debug programs using libfftw, either take
-fomit-frame-pointers from the Makefile and rebuild libfftw, or export
NJAMD_NO_RETADDRS=1.

The framework for *BSD MT support is in place, and libnjamd_r.so gets built, 
but for some reason, our malloc is only used by the pthread routines. Once 
main is entered, libc malloc is used. I thought it had something to do with 
libtool insisting on linking against libc and libc_r. But I forced it to only
link with libc_r, and it still doesn't work.. What's worse is that in the MT
libs, writing to stderr seems to not have any effect before main, so it's hard
to trace. Lookin to you F/OBSD guru's to shed some light on the subject :)

FreeBSD is also very dumb about dumping core. Use ulimit to stop it from
dumping a really huge corefile. 

For Solaris 2.6 and gdb 4.17, programs being debugged with LD_PRELOAD halt
somewhere in the init code complaining about unable to find fd 8 in /proc.
This is obviously not our problem, and appears to be harmless. Simply issue 
'cont' to continue. 

For OpenBSD and other a.out systems, you will have to link with the library at
compile time.

Possible issues with globally initialized classes in C++ may exist.

I also suspect that there is a bug(s) in the gnome-libs and in the gimp,
but I haven't proven it yet. When I get around to upgrading my system, I'll
have a go at it with the latest versions of them.

netscape crashes mysteriously, and as far as I can tell, before it even enters
our code. They're probably doing something unsane with their own threads
implementation.

Features to expect by 1.0:
See TODO

Mail mikepery@fscked.org with questions, bugs, suggestions, patches and news
of of new architecture's sucess rates.
