Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 12 Jan 2003 17:30:08 -0800
From:      Marcel Moolenaar <marcel@xcllnt.net>
To:        Kris Kennaway <kris@obsecurity.org>
Cc:        ia64@FreeBSD.ORG, kuriyama@FreeBSD.ORG
Subject:   Re: ld error in ucd-snmp build
Message-ID:  <20030113013008.GA1613@dhcp01.pn.xcllnt.net>
In-Reply-To: <20030113000036.GA20935@rot13.obsecurity.org>
References:  <20030113000036.GA20935@rot13.obsecurity.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030113013008.GA1613>