Problem confirmed (?) and death to lib[h]disk (!) (Re: serious libh linking problems)

The Anarcat <[email protected]> Wed, 13 Nov 2002 16:33:17 -0500
Newsgroups gmane.os.freebsd.devel.libh
Message-ID <[email protected]>
On Wed Nov 13, 2002 at 07:36:14PM +0100, Alexander Langer wrote:
> Thus spake The Anarcat ([email protected]):
> 
> > Interesting. That might be related to it. Maybe if we try to link
> > libhsysinstall directly against -lh?
> > > I might be able to take a look at this later today :)
> > Thank you. We might even get a dynamic tclh after all! :)
> 
> OK, thanks to the libdisk changes that came with GEOM, I'm not
> able to build libhdisk at the moment at all.
> 
> However, I had some old libraries of libh* floating around in /usr/lib
> (old == September/October or so), and pkg_create just linked correctly
> (and then running produced a Bus error :)
> 
> I'd suspect a local problem of yours.
> 
> Ciao
> 
> Alex
> 
> PS: libdisk in -CURRENT lacks a shutload of functions that were in
> before.  It's rather unusable nowadays :-/

Hurray.

That's pretty bad. Isn't libdisk used by sysinstall? Doesn't the
libdisk breakage break sysinstall and therefore 5.0 installs???

Anyways, I think this confirms my suspicion that I broke the library
build somehow. I'll dig up older libh versions to see how exactly,
maybe I can finally figure this one out.

But I can say with pretty much certainty that my system is "clean",
i.e. the libraries I have installed are what libh installs if you do
it from scratch.

Can't you just drop libhdisk from the build? I think it needs to die
anyways. I doubt anything really depends on it apart from the disk
editor. If you agree, I'll start getting libh free of libhdisk. We'll
have to rewrite the disk editor, but I don't see that as a problem at
all.

Honestly, I think the sysinstall2 program in itself should be
compiled, not interpreted, precisely because of such problems: I don't
want to make a libhdisk library to follow each and every change of the
local disk infrastructure.

Well, maybe *some* parts of the program could be interpreted, but the
low-level disk manipulations *will* have to be compiled, so I'd rather
interface the system libraries directly than create more TCL wrappers.

What do you think?

A.

To Unsubscribe: send mail to [email protected]
with "unsubscribe freebsd-libh" in the body of the message