From owner-freebsd-amd64@FreeBSD.ORG Thu Jan 12 07:36:28 2006 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAA5D16A41F; Thu, 12 Jan 2006 07:36:28 +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 F191843D48; Thu, 12 Jan 2006 07:36:27 +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 08:36:11 +0100 Date: Thu, 12 Jan 2006 08:36:10 +0100 (CET) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Scott Long In-Reply-To: <43C5B463.5020505@samsco.org> Message-ID: <20060112083224.U34596@beagle.kn.op.dlr.de> References: <20060111073859.457C37302F@freebsd-current.sentex.ca> <20060111090039.N760@beagle.kn.op.dlr.de> <200601110853.19622.jhb@freebsd.org> <20060111150808.P760@beagle.kn.op.dlr.de> <20060111142302.GA34661@ip.net.ua> <20060111142622.GB34661@ip.net.ua> <43C5B463.5020505@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 12 Jan 2006 07:36:12.0021 (UTC) FILETIME=[DC737250:01C6174A] Cc: amd64@freebsd.org, Poul-Henning Kamp , Peter Wemm , current@freebsd.org Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2006 07:36:29 -0000 On Wed, 11 Jan 2006, Scott Long wrote: SL>Ruslan Ermilov wrote: SL>> On Wed, Jan 11, 2006 at 04:23:02PM +0200, Ruslan Ermilov wrote: SL>> SL>> > > Wouldn't it then make sense just to build a shared libdisk? Is there a SL>> > > reason not to have one? SL>> > > SL>> > SL>> > Here's the original reason. I'm not sure if it still holds. peter@ and SL>> > phk@ Cc:ed. SL>> > SL>> > : RCS file: /home/ncvs/src/lib/libdisk/Makefile,v SL>> > : Working file: Makefile SL>> > : head: 1.44 SL>> > : branch: SL>> > : locks: strict SL>> > : access list: SL>> > : keyword substitution: kv SL>> > : total revisions: 65; selected revisions: 1 SL>> > : description: SL>> > : ---------------------------- SL>> > : revision 1.12 SL>> > : date: 1996/03/17 19:02:07; author: peter; state: Exp; lines: +1 -0 SL>> > : Repository copy src/release/libdisk to src/lib/libdisk as per recent SL>> > : discussion on -core about disk partitioning tools etc. SL>> > : : Add NOPIC=yes to Makefile to prevent any possibility of version SL>> > mismatch SL>> > : because of the potential grave consequences. (as suggested by phk) SL>> > : : Note that this is also on RELENG_2_1_0, since the sysinstall stuff is SL>> > : hopefully going to remain in sync. SL>> > SL>> SL>> As a safe measure, we can build and install a special PIC archive, SL>> similar to libc_pic.a and libgcc_pic.a, and use it here. This is SL>> all in an assumption that it's still unsafe to produce the libdisk.so. SL>> SL>> SL>> Cheers, SL> SL>One way or another, please fix it. Why is bsnmp linking to libdisk anyways? SL>It's an absolutely horrible library. Then either remove it, put a 'don't use this horrible library' into the man page or whatever. How is one supposed to know that it shouldn't be used if it is there? I suppose that this library is currently the easiest way to enumerate all the partitions and slices. The hostres MIB needs this to populate the hrPartitionTable. I would also say, that everybody is free to 'fix' this. harti