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