Re: [head tinderbox] failure on amd64/amd64

From: Scott Long <scottl_at_samsco.org>
Date: Thu, 12 Jan 2006 07:23:47 -0700
Harti Brandt wrote:
> 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_at_ and
> SL>> > phk_at_ 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

libdisk is an artifact of sysinstall, and has been for abut 10 years.
And no, it's quite customary for the person who created the compile
problem to fix it in a timely manner.

Scott
Received on Thu Jan 12 2006 - 13:23:50 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:50 UTC