From owner-freebsd-ia64 Sun Jan 12 17:30:12 2003 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 01E2137B401; Sun, 12 Jan 2003 17:30:10 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9A0C43F6B; Sun, 12 Jan 2003 17:30:08 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0D1U32G038597; Sun, 12 Jan 2003 17:30:03 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0D1UACv001762; Sun, 12 Jan 2003 17:30:10 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0D1U9vR001761; Sun, 12 Jan 2003 17:30:09 -0800 (PST) (envelope-from marcel) Date: Sun, 12 Jan 2003 17:30:08 -0800 From: Marcel Moolenaar To: Kris Kennaway Cc: ia64@FreeBSD.ORG, kuriyama@FreeBSD.ORG Subject: Re: ld error in ucd-snmp build Message-ID: <20030113013008.GA1613@dhcp01.pn.xcllnt.net> References: <20030113000036.GA20935@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030113000036.GA20935@rot13.obsecurity.org> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Jan 12, 2003 at 04:00:36PM -0800, Kris Kennaway wrote: > http://bento.freebsd.org/errorlogs/ia64-5-latest/ucd-snmp-4.2.5_2.log > > ld -Bshareable -soname libsnmp.so.4 -o libsnmp.so snmp_client.o mib.o parse.o snmp_api.o snmp.o snmp_auth.o asn1.o md5.o snmp_parse_args.o system.o vacm.o int64.o read_config.o snmp_debug.o tools.o snmp_logging.o snmpv3.o snmpusm.o lcd_time.o keytools.o scapi.o callback.o default_store.o snmp_alarm.o mt_support.o snprintf.o strtol.o strtoul.o > ld: parse.o: @gprel relocation against dynamic symbol tree_head > ld: parse.o: @gprel relocation against dynamic symbol mibLine > ld: parse.o: @gprel relocation against dynamic symbol File > ld: parse.o: @gprel relocation against dynamic symbol mibLine > ld: parse.o: @gprel relocation against dynamic symbol File > ld: parse.o: @gprel relocation against dynamic symbol mibLine > ld: parse.o: @gprel relocation against dynamic symbol File > ld: parse.o: @gprel relocation against dynamic symbol File > ld: parse.o: @gprel relocation against dynamic symbol mibLin > ... > This appears to be a bug in the port. It creates a shared library under .libs first with the PIC objects and then creates a shared library in the current directory with the non-PIC object. The latter obviously can not work in the general case. I cc'd kuriyama (maintainer). Details of the failure follows: Data objects with a size less than 8 bytes (by default) are placed in the short data section. The short data can be accessed by using a relative address calculation based on GP (hence the @gprel). The sequence looks like (for an int; ia64 syntax): add symaddr=@gprel(symbol),GP ;; ld4 symval=[symaddr] This sequence is not relocatable and therefore unsuitable for use in shared libraries. The non-relocatable property is caused by having a compile/link time fixed offset from GP. The obvious solution is to compile with -fpic. The non-obvious solution is to disable the short data section. In both cases, the access sequence will contain a linkage table load, as in: add tblofs=@ltoff(symbol),GP ;; ld8 symaddr=[tblofs] ;; ld4 symval=[symaddr] The is fully runtime relocatable, but is less efficient. The port compiles both PIC and non-PIC object files, but ends up trying to use the non-PIC object files to build a shared library. This fails. The fix is to prevent the creation of the shared library a second time (the one with the wrong object files), or to have it use the right object files (ie the PIC versions). Beware the creation of the archive library. Two versions are created: One with non-PIC code for use in executables (shared or static), and one with the PIC code for use in shared libraries (ie the shared library is created by linking in (parts of) the archive library. HTH, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message