[irrtoolset]Re: Porting RAToolSet 4.7.1 to the NetBSD package system
Havard Eidnes he at uninett.no
Wed Jan 21 16:46:09 CET 2004
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
-------------- next part --------------
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)