Date: Tue, 17 Nov 1998 20:58:31 -0800 (PST) From: John Polstra <jdp@polstra.com> To: kaleb@ics.com Cc: hackers@FreeBSD.ORG Subject: Re: First Impression of 3.0-RELEASE Message-ID: <199811180458.UAA25364@vashon.polstra.com> In-Reply-To: <36519613.52DA940@ics.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <36519613.52DA940@ics.com>, Kaleb S. KEITHLEY <kaleb@ics.com> wrote:
>
> 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.
Glad to hear it!
> 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.
Aw, jeeze, where were you a few months ago? People left and right
were SCREAMING for an ELF ldconfig, and I was about the only guy
arguing against it. Finally I got sick of arguing and implemented the
damned thing. Go back to the archives of -current if you want a taste
of that debacle. It was not a fun time.
> 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.
Are you sure it really worked on libraries under SVR4? Every
implementation of ldd that I've ever seen just set a magic environment
variable for the dynamic linker and then "executed" the program.
I.e., I've never seen one that would work for shared libraries
standing alone.
> 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.
I don't think you should either. This is supposed to work, and
it does work at least in simple tests. If you can put together a
reasonable test case for me, I'll be happy to look at it, and fix it
if it's a bug.
John
--
John Polstra jdp@polstra.com
John D. Polstra & Co., Inc. Seattle, Washington USA
"Nobody ever went broke underestimating the taste of the American public."
-- H. L. Mencken
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?199811180458.UAA25364>