From owner-freebsd-hackers Thu Feb 4 03:58:06 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA01555 for freebsd-hackers-outgoing; Thu, 4 Feb 1999 03:58:06 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ics.com (ics.com [140.186.40.192]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA01550 for ; Thu, 4 Feb 1999 03:58:02 -0800 (PST) (envelope-from kaleb@ics.com) Received: from kaleb.keithley.belmont.ma.us (ics.com [140.186.40.192]) by ics.com (8.9.0.Beta5/8.9.0.Beta5) with SMTP id GAA27816 Thu, 4 Feb 1999 06:58:00 -0500 (EST) Message-ID: <36B99FD3.41C67EA6@ics.com> Date: Thu, 04 Feb 1999 08:25:40 -0500 From: "Kaleb S. KEITHLEY" Organization: Integrated Computer Solutions X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 3.0-RELEASE i386) MIME-Version: 1.0 To: hackers@FreeBSD.ORG Subject: Re: ldconfig and libraries References: <199901311851.KAA07228@vashon.polstra.com> <199902040322.TAA18413@vashon.polstra.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Polstra wrote: > > In article <36B700D2.41C67EA6@ics.com>, > Kaleb S. KEITHLEY wrote: > > > > ldconfig for ELF should just go away. > > Feel free to remove it from your system. Wrong solution to the problem. > It's not going to go away in > FreeBSD any time soon. You witnessed the outcry when I tried to argue > against it months ago. Non sequitur. ldconfig is redundant at best, presents a minor security risk, and the last time I tried it allowed for demonstrably incorrect or unexpected behavior. System admins who think they know better be damned -- they're not supporting the products they're breaking. If someone calls up and tells me they installed my product somewhere other than where the install was supposed to put it, tried to kludge it with ldconfig, and now the product doesn't work correctly, the first thing I'm going to tell them is to reinstall it in the correct, supported, location and let the program's RPATH and ld.so do what they're supposed to do. > There's no point in your bringing it up over > and over again. It's here to stay. Just get over it. I did. :-) You seem to be under the delusion that you're signing my paycheck or something. I'll lobby for its removal as long as it stays in the release. You may not see the point, and I don't care if you do or don't see the point. Put me in your killfile if you don't want to see me lobby for fixing a serious bug. And you give up too easily too. > > > an ELF shared library must have a name > > > that ends with ".so." followed by exactly one version number, like > > > this: > > > > > > libfoo.so.12 > > > > > > > On other ELF systems (since I haven't looked that closely at FreeBSD's > > ELF implementation) the version is a string. The string may have any > > value, e.g. "foo", "a-really-long-and-silly-string" or "3". > > > > The linker doesn't care, it merely records the fully qualified name of > > the library, including the version string, in the program's NEEDED. The > > run-time loader doesn't care, it loads the exact library by name, as > > recorded in the program's NEEDED. > > That is the case for FreeBSD too. The question was about ldconfig, > not about the dynamic linker. I think you miss the point. In ELF the "version" is a string with no semantics. You said it had to be a single number. That's wrong. And it's wrong whether we're talking about ldconfig, ld, or ld.so. -- Kaleb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message