Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Nov 1998 10:28:19 -0500
From:      "Kaleb S. KEITHLEY" <kaleb@ics.com>
To:        hackers@FreeBSD.ORG
Subject:   First Impression of 3.0-RELEASE
Message-ID:  <36519613.52DA940@ics.com>

next in thread | raw e-mail | index | archive | help

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36519613.52DA940>