Subject: Re: HEADS UP: migration to fully dynamic linked "base" system
To: Bill Studenmund <email@example.com>
From: Johnny Billquist <firstname.lastname@example.org>
Date: 08/26/2002 20:12:25
On Mon, 26 Aug 2002, Bill Studenmund wrote:
> On Mon, 26 Aug 2002, Johnny Billquist wrote:
> > I'm sorry. I am trying to read it all, but there is always something I
> > might miss.
> Ok. Point taken, sorry if I was snippy.
My tone have probably been very unpleasant in a few mails now as well, so
I'll try to apologize here as well. Sorry for the hallaballoo.
I'm just unhappy with this change.
> > Correct me if I'm wrong, but doesn't this imply that *all* binaries will
> > be linked static? Or are you suggesting that I should build each directory
> > separately, and set the flags by hand before running make?
> True. See note I just sent Greywolf for a suggestion on how we can easily
> let folks have /bin and /sbin static while everything else is dynamic.
Yes, I saw that. Seemed pretty okay as such.
> > Admittedly, I can go around and change Makefiles, and that will probably
> > be what I'll have to do. But I also don't want a /lib, so I'll have to dig
> > for that as well, and perhaps there is something else I'll have to address
> > too, which I don't even know about.
> I think not having a /lib would be harder, as then you're really tweaking
> the build system.
That was not what I'd like to hear. :-)
> > It *would* be nice if you had some way for people to keep thing in the old
> > way here, and that's what I asked for. :-)
> I think we can easily accomodate /bin and /sbin static. The problem over
> time will be if we keep supporting this old way and that old way that we
> have a support mess. :-|
True. And this points to an underlying problem with the system (or
perhaps Unix as a whole).
Explicitly supporting all variations on how people might want to set
things up is impossible. So why do we do it that way?
Why not instead support the possibility for people to select by themself,
and just provide a good default?
I have never cared much about the ld.so.config arguments before, but as
I'm an old time abuser of rather odd systems, I see a possible problem.
Why should binaries have hardcoded paths to where shared libraries are
Should not different system managers with different ideas on where to
place things be allowed the freedom of doing that? And then that sysadm
should have the ability to tell all binaries where they should find the
libraries they want to use.
I always felt that that was the argument for ld.so.conf, and it's an
argument I've neved seen recognized here.
And I said "odd systems", and by that I mean VMS, and even more RSX (yes,
that's a PDP-11 OS, and RSX have had shared libraries since the '70s).
These systems admittedly solves the security issues by requiring that
libraries be known to the system, and thus you have to have bits in order
to install a shared library, but the point is that the system don't meddle
with *where* you have the libraries, that can be left to the sysadm.
Sorry about these rambling, and I fear I might have really opened a can of
I really don't suffer from having paths to libraries explicitly in
binaries, I just don't want a split of /usr/lib into (also) /lib, which to
me seems rather senseless (pretty obvious since I don't want binaries in
the root system to use shared libraries).
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: email@example.com || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol