Hi, while trying to make RAToolSet 4.7.1 go on NetBSD, I have found a few problems: o The programs now compile and link OK on the netbsd-1-6 branch, where GCC version 2.95.3 is used. However, the "roe" program segfaults briefly after startup, as can be seen in the first attachment below. o Minor annoyance: The --enable-debug switch to configure does not work; if you specify it, the compiles are still done -O2 and with no debug info generation. However, passing the environment variables CFLAGS and CXXFLAGS set to "-g -O2" to configure doesn't really give any more information than what's shown in the attachment below. o Nitpick: The documentation for roe says "roe [flags] [<as-no>]". However, as far as I can see from later examples, it does not expect an AS number as argument, but rather a string which starts with the two letters AS immediately followed by the AS number. Whether it works to just pass the AS number I can't tell due to the problem above. o The good news is that on netbsd-1-6, of the other programs, at least peval works. I've so far not tested the other programs. o I tried compiling RAToolSet on the current development version of NetBSD which uses GCC 3.3.2. It immediately becomes apparent that the code as it stands today will not compile on that environment. There are several portability problems: 1) The source uses deprecated headers, e.g. <iostream.h> instead of <iostream> etc., resulting in warnings of this type: /usr/include/g++/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the <X> header for the <X.h> header for C++ includes, or <sstream> instead of the deprecated header <strstream.h>. To disable this warning use -Wno-deprecated. 2) The source uses implementation-specific headers and identifiers from the implementation-reserved name space, in that several headers include <_G_config.h> and make use of _G_uint32_t, for apparently no good reason at all. It looks like someone was let loose in the code without supervision. The example cited here is easily fixed by using <stdint.h> and using e.g. uint32_t etc. 3) There are however more serious portability-related problems with the code of a nature where my inadequate C++ knowledge is unable to point me in the right direction. Some of this appears to be related to the standard C++ library. So far I've not even managed to compile the first C++ file. In short, I have the following two questions: o Does anyone maintain RAToolSet at the moment? o Is anyone working on getting it ported to a more modern C++ environment? Regards, - Håvard nsa: {108} gdb /usr/pkg/bin/roe GNU gdb 5.0nb1 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386--netbsdelf"...(no debugging symbols found)... (gdb) run AS224 Starting program: /usr/pkg/bin/roe AS224 (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x804c8dd in basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> >::Rep::clone () (gdb) where #0 0x804c8dd in basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> >::Rep::clone () #1 0x804b2ab in dladdr () #2 0x804ac60 in free () (gdb)