From owner-freebsd-current@FreeBSD.ORG Thu Jan 12 11:35:01 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D44CB16A41F for ; Thu, 12 Jan 2006 11:35:01 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id F216B43D48 for ; Thu, 12 Jan 2006 11:35:00 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 Jan 2006 12:34:59 +0100 Date: Thu, 12 Jan 2006 12:35:33 +0100 (CET) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Peter Carah In-Reply-To: <43C625C2.2030208@altadena.net> Message-ID: <20060112123435.B35349@beagle.kn.op.dlr.de> References: <43C60A57.3040405@altadena.net> <20060112085736.L34596@beagle.kn.op.dlr.de> <43C625C2.2030208@altadena.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 12 Jan 2006 11:34:59.0242 (UTC) FILETIME=[3823E0A0:01C6176C] Cc: current@freebsd.org Subject: Re: Problem building new bsnmpd import on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2006 11:35:01 -0000 On Thu, 12 Jan 2006, Peter Carah wrote: PC>Harti Brandt wrote: PC>> This should been fixed now (by building a shareable libdisk). PC>> PC>> harti PC>> PC> PC>I waited several days before sending this query, just in case a fix came in. PC>It didn't until late today (I cvsup'd this morning and it didn't come yet). PC> PC>Then why did it build just fine on i386, and fail (on my only 2 samples) only PC>on amd64. (I have a sparc64 but at the moment it doesn't run fbsd so I can't PC>tell if it matters there or not...) Perhaps the 32-bit arch only supports PC>relocations that are common between shared and not? Or that gcc doesn't try to PC>get too fancy? PC> PC>I do understand the fix and all, just curious as to why it didn't PC>matter on i386. It seems that amd64 relocation is different from, for example, sparc64 and doesn't allow to link non-pic static libraries into a shared object. harti