From owner-freebsd-ports@FreeBSD.ORG Thu Jan 29 10:30:52 2004 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 900C816A4CE; Thu, 29 Jan 2004 10:30:52 -0800 (PST) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50C2743D5D; Thu, 29 Jan 2004 10:30:37 -0800 (PST) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i0TIUX3h018999; Thu, 29 Jan 2004 10:30:33 -0800 (PST) Received: from [10.1.1.193] (nfw2.codefab.com [66.234.138.66]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 3.0) with ESMTP id i0TIUVIr026142; Thu, 29 Jan 2004 10:30:32 -0800 (PST) In-Reply-To: <20040129151711.GA1416@zi025.glhnet.mhn.de> References: <1E5E3622-51D2-11D8-96D6-003065A20588@mac.com> <20040129151711.GA1416@zi025.glhnet.mhn.de> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <383EB36E-5289-11D8-A032-003065ABFD92@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Thu, 29 Jan 2004 13:30:31 -0500 To: gerard@freebsd.org, ports@freebsd.org X-Mailer: Apple Mail (2.609) cc: Simon Barner cc: Oliver Eikemeier Subject: Re: security/nmap & gcc3.3? X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2004 18:30:52 -0000 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