More toolchain issues

[John Klos <john%ziaspace.com@localhost>]

Hi,

Here's my latest problem with compiling (or trying to compile) nmap:

c++ -c -Iliblua -Ilibdnet-stripped/include -I/usr/local/include -I/usr/local/include -I/usr/local/include 
-I/usr/local/include -I/usr/include -I/usr/include -Inbase -Insock/include -O2 -I/usr/local/include -I/usr/include 
-Wall  -fno-strict-aliasing   -DHAVE_CONFIG_H -DNMAP_NAME=\"Nmap\" -DNMAP_URL=\"http://nmap.org\"; 
-DNMAP_PLATFORM=\"m68k--netbsdelf\" -DNMAPDATADIR=\"/usr/local/share/nmap\" -D_FORTIFY_SOURCE=2 
scan_engine.cc -o scan_engine.o
scan_engine.cc: In function 'bool get_pcap_result(UltraScanInfo*, timeval*)':
scan_engine.cc:3937: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.NetBSD.org/Misc/send-pr.html> for instructions.
gmake[1]: *** [scan_engine.o] Error 1
gmake[1]: Leaving directory `/usr/pkgsrc/net/nmap/work/nmap-5.00'
gmake: *** [all] Error 2
*** Error code 2

Stop.
make: stopped in /usr/pkgsrc/net/nmap
*** Error code 1

Stop.
make: stopped in /usr/pkgsrc/net/nmap


After about two and a half minutes of CPU time and after growing to more 
than 60 megs, cc1plus stops and complains. Between this and the last 
problem, I'm confused - isn't our unlimited datasize 128 megs? Why are 
these dying after reaching 64 megs?

I've tried Frank's libc with phk-allocator in place of jemalloc, and the 
compilation (at least of scan_engine.o) is still running after two hours 
(60 MHz m68060), and the size went above 64 megs (up to 69, at least).

So what's broken with jemalloc that doesn't allow more than 64 megs to be 
used? Is this an m68k problem, or are different allocators used by 
different ports?

This'll be good to get fixed before resuming a bulk package build...

Thanks,
John