From owner-freebsd-hackers Tue Nov 17 07:28:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA24955 for freebsd-hackers-outgoing; Tue, 17 Nov 1998 07:28:54 -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 HAA24941 for ; Tue, 17 Nov 1998 07:28:45 -0800 (PST) (envelope-from kaleb@ics.com) Received: from ics.com (sunoco.ics.com [140.186.40.142]) by ics.com (8.9.0.Beta5/8.9.0.Beta5) with ESMTP id KAA00139 Tue, 17 Nov 1998 10:28:19 -0500 (EST) Message-ID: <36519613.52DA940@ics.com> Date: Tue, 17 Nov 1998 10:28:19 -0500 From: "Kaleb S. KEITHLEY" Organization: Integrated Computer Solutions X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: hackers@FreeBSD.ORG Subject: First Impression of 3.0-RELEASE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'll start by saying that the upgrade/install went flawlessly and kudos for that. I'm also happy that FreeBSD is finally using ELF. Generally I'm a happy guy (except for the rock solid system wedge my system gets after every second file copy to an MSDOS filesystem on a floppy.) But there are a few flies in the ELF ointment I've noticed while working on the X11 Sample Implementation: First, the ELF ld.so.cache. I've noticed somewhere else that NetBSD (their Alpha FAQ maybe?) acknowledges the correctness of using the RUNPATH in each program rather than having a global ld.so.cache; thus there's no ld.so.cache on NetBSD. Linux's continued use of the same ld.so.cache for both a.out and ELF is plenty bad, but their old loader never had support for a runpath, so in a way it's sort of justifiable that they still have it. But given that FreeBSD has had runpaths in a.out (broken as it is/was) for a long time now I think it's time FreeBSD dumped this archaic piece of cruft. Someone will undoubtedly try to defend this old hack by saying that "no one but the system admin really knows where things are going to go, yada, yada"; but in truth, if that were true, why doesn't NetBSD, and all the commercial SVR4 not need it too! Indeed, because it's just not true. When I, or XFree86, or someone else build and package software that expects libraries and other things to be in, e.g. /usr/X11R6/lib, then that's really where they ought to go. I think the system admins around the world realize that and plan their systems accordingly. Two, ldd works on ELF programs but not on ELF libraries? This is just strange. I suppose I can always ship my libraries over to an SVR4 or Linux system in order to {ldd,dump,odump} them. I know, I can always step up to the task of fixing it, or writing odump, myself. I'll get right on it after I've finished all the other stuff I'm working on. Really. Any day now. :-) Third, transitive linking doesn't work. I.e if I link libXt with -lSM -lICE, and then link a program with -lXt, I get unresolved externals for libSM and libICE. Should I? The program does not make any calls to libSM or libICE, so I don't think I should. Leastways I don't get them on all the other systems that use ELF, and I'd wager that if I looked, I could find something in the ELF specification (a.k.a. the SystemV ABI) that speaks to this. Of the three things, I think this is far and away the most serious shortcoming. Nothing's going to fix this for 3.0, so some sort of kludgie work-around will have to be employed. I hope someone will fix this for the next release. For all the agonizing about companies that will port their product to Linux but not to FreeBSD, I have to say that I do sympathise with them. These sorts of niggling inconsistencies are a bane to software developers. I hope you'll consider the changes I'm suggesting. If you don't agree with them, that's okay with me. Please don't send me email telling me I'm wrong about the ld.so.cache or the transitive linking. These are the way I think they should work -- I'm not going to change my mind -- and if they don't change, I'll live with them. I want to register my opinion about the way I think things ought to be. (Feel free to ignore my opinions, almost everyone else does. :-) -- Kaleb S. KEITHLEY To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message