Date: Mon, 20 Feb 95 9:42:52 MST From: terry@cs.weber.edu (Terry Lambert) To: ljo@po.CWRU.Edu Cc: nate@trout.sri.MT.net, rgrimes@gndrsh.aac.dev.com, current@freefall.cdrom.com Subject: Re: libcompat and shlib conflict Message-ID: <9502201642.AA03124@cs.weber.edu> In-Reply-To: <199502201233.HAA01665@amcell2.caisr.cwru.edu> from "L Jonas Olsson" at Feb 20, 95 07:33:36 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Isn't the idea not to have a shared libcompat? This library is > supposed to disappear (at least some functions in it) and we don't > want binaries to depend on having these functions in new releases. > This also gives an extra incentive to fix programs that use it as > their binaries will be larger :) A program compiled with a static libcompat as opposed to a dynamic libcompat is more likely to correctly match another platforms ABI in any case. Not only are we not guaranteed that the external globals linked into your program and referenced by the libcompat routines will be the same on another platform (causing their shared libcompat to fail), but the cruft in libcompat is likely as not going to be different from vendor to vendor anyway. Specifically, the libcompat is cruft to act as glue between an old program that everyone is too lazy to rewrite, and new interfaces for which specifications are available. The cost of the cruft should be bourne by the crufty program. As someone else noted, think of it as incentive to do what should have been done instead of using libcompat in the first place. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9502201642.AA03124>