security/nmap & gcc3.3?

[Charles Swiger]

On Jan 29, 2004, at 10:17 AM, Simon Barner wrote:
[ ... ]
>> [ Other ports I've tried which use g++33 link fine; this problem seems
>> specific to security/nmap... ]
>
> This is very strange. g++ is supposed to link against lstdc++ without
> any additional options.

Agreed-- I was hoping someone else would also feel this way.  :-)

> I tried to compile nmap with my older version of g++33, and it compiled
> and linked just fine:
[ ... ]
> I'd suggest that you make sure that you have the very latest version of
> the gcc33 port installed, and if the problem continues to exist, IMO  
> you
> should contact the gcc maintainer (gerald@).

I am using the very latest version of the gcc33 port (from three days  
ago, 2004/1/26).

Adding "-v" confirms that -lstdc++ is added to the linking stage  
automaticly and as expected, as is the  
-L/usr/local/lib/gcc-lib/i386-portbld-freebsd4.9/3.3.3 reference.   
However:

62-sec# /usr/local/bin/g++33 -v -L/usr/local/lib   
-rpath=/usr/lib:/usr/local/lib -L/usr/lib -Lnbase -Lnsock/src/  -o nmap  
main.o nmap.o targets.o tcpip.o nmap_error.o utils.o idle_scan.o  
osscan.o output.o scan_engine.o timing.o charpool.o services.o  
protocols.o nmap_rpc.o portlist.o NmapOps.o TargetGroup.o Target.o  
FingerPrintResults.o service_scan.o NmapOutputTable.o -lm  -lssl  
-lcrypto -lnbase -lnsock -lpcre -lpcap
Reading specs from  
/usr/local/lib/gcc-lib/i386-portbld-freebsd4.9/3.3.3/specs
Configured with: ./..//gcc-3.3-20040126/configure --disable-nls  
--with-system-zlib --program-suffix=33  
--with-gxx-include-dir=/usr/local/lib/gcc-lib/i386-portbld-freebsd4.9/ 
3.3.3/include/c++/ --disable-shared --prefix=/usr/local  
i386-portbld-freebsd4.9
Thread model: posix
gcc version 3.3.3 20040126 (prerelease) [FreeBSD]
  /usr/local/lib/gcc-lib/i386-portbld-freebsd4.9/3.3.3/collect2 -V  
-rpath=/usr/lib:/usr/local/lib -dynamic-linker /usr/libexec/ld-elf.so.1  
-o nmap /usr/lib/crt1.o /usr/lib/crti.o  
/usr/local/lib/gcc-lib/i386-portbld-freebsd4.9/3.3.3/crtbegin.o  
-L/usr/local/lib -L/usr/lib -Lnbase -Lnsock/src/  
-L/usr/local/lib/gcc-lib/i386-portbld-freebsd4.9/3.3.3  
-L/usr/local/lib/gcc-lib/i386-portbld-freebsd4.9/3.3.3/../../.. main.o  
nmap.o targets.o tcpip.o nmap_error.o utils.o idle_scan.o osscan.o  
output.o scan_engine.o timing.o charpool.o services.o protocols.o  
nmap_rpc.o portlist.o NmapOps.o TargetGroup.o Target.o  
FingerPrintResults.o service_scan.o NmapOutputTable.o -lssl -lcrypto  
-lnbase -lnsock -lpcre -lpcap -lstdc++ -lm -lgcc -lc -lgcc  
/usr/local/lib/gcc-lib/i386-portbld-freebsd4.9/3.3.3/crtend.o  
/usr/lib/crtn.o
main.o(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
nmap.o: In function `nmap_main(int, char**)':
nmap.o(.text+0x1a18): undefined reference to `operator new(unsigned)'
nmap.o(.text+0x1f7a): undefined reference to `operator delete(void*)'
nmap.o(.text+0x1f8f): undefined reference to `operator delete(void*)'
nmap.o(.text+0x2ba5): undefined reference to `operator delete(void*)'
nmap.o(.text+0x2bad): undefined reference to `_Unwind_Resume'
[ ... ]

This results in the same linking problems from my original message.   
Editting the link line and moving the -L reference earlier causes the  
link to succeed:

/usr/local/lib/gcc-lib/i386-portbld-freebsd4.9/3.3.3/collect2  
-rpath=/usr/lib:/usr/local/lib -dynamic-linker /usr/libexec/ld-elf.so.1  
-o nmap /usr/lib/crt1.o /usr/lib/crti.o  
/usr/local/lib/gcc-lib/i386-portbld-freebsd4.9/3.3.3/crtbegin.o  
-L/usr/local/lib/gcc-lib/i386-portbld-freebsd4.9/3.3.3 -L/usr/local/lib  
-L/usr/lib -Lnbase -Lnsock/src/  
-L/usr/local/lib/gcc-lib/i386-portbld-freebsd4.9/3.3.3/../../.. main.o  
nmap.o targets.o tcpip.o nmap_error.o utils.o idle_scan.o osscan.o  
output.o scan_engine.o timing.o charpool.o services.o protocols.o  
nmap_rpc.o portlist.o NmapOps.o TargetGroup.o Target.o  
FingerPrintResults.o service_scan.o NmapOutputTable.o -lssl -lcrypto  
-lnbase -lnsock -lpcre -lpcap -lstdc++ -lm -lgcc -lc -lgcc  
/usr/local/lib/gcc-lib/i386-portbld-freebsd4.9/3.3.3/crtend.o  
/usr/lib/crtn.o

Why that makes the difference is a question for a GCC wizard.  :-)  [  
gerard@ CC'ed. ]
Thanks Simon, Oliver, and Matthias, for your responses and suggestions.

-- 
-Chuck