[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130409171911.GZ20323@brightrain.aerifal.cx>
Date: Tue, 9 Apr 2013 13:19:12 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Pending issues for next release
On Thu, Apr 04, 2013 at 07:04:04PM -0400, Rich Felker wrote:
> On Wed, Apr 03, 2013 at 09:00:00PM -0700, Isaac Dunham wrote:
> > On Mon, 1 Apr 2013 19:31:44 -0400
> > Rich Felker <dalias@...ifal.cx> wrote:
> >
> > > Here's a quick list of open issues that we might want to take care of
> > > before another release:
> > >
> > (snipping several interesting improvements)
> > > - switching libc.so/ld-musl.so symlink direction
> >
> > Does this patch look suitable?
> > I know it does work, including in the DESTDIR=./.../ case.
>
> I can't say it's wrong, but seeing this patch reminds me why I didn't
> do it before...
>
> > diff --git a/Makefile b/Makefile
> > index 997c5bb..478e698 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -118,7 +118,10 @@ tools/musl-gcc: config.mak
> > $(DESTDIR)$(bindir)/%: tools/%
> > install -D $< $@
> >
> > -$(DESTDIR)$(libdir)/%.so: lib/%.so
> > +$(DESTDIR)$(libdir)/libc.so: $(DESTDIR)$(LDSO_PATHNAME)
> > + ln -sf $(LDSO_PATHNAME) $@
> > +
> > +$(DESTDIR)$(LDSO_PATHNAME): lib/libc.so
> > install -D -m 755 $< $@
> >
> > $(DESTDIR)$(libdir)/%: lib/%
> > @@ -127,12 +130,6 @@ $(DESTDIR)$(libdir)/%: lib/%
> > $(DESTDIR)$(includedir)/%: include/%
> > install -D -m 644 $< $@
> >
> > -$(DESTDIR)$(LDSO_PATHNAME): $(DESTDIR)$(syslibdir)
> > - ln -sf $(libdir)/libc.so $@ || true
> > -
> > -$(DESTDIR)$(syslibdir):
> > - install -d -m 755 $(DESTDIR)$(syslibdir)
> > -
>
> Unfortunately, this makes it impossible to run "make install" without
> a DESTDIR unless you're root. Before, the ||true in the dynamic-linker
> installation allowed you to "make install" without root as long as you
> have permissions to the prefix, and the resulting install could be
> used for everything except _running_ dynamic-linked programs. (Also,
> if root added a single symlink for you, it would be fully functional.)
>
> I don't want to reject the patch, because I think this change is
> mostly correct, but I would like to discuss and see if there's any way
> we can get back the old level of functionality while making this
> change. In particular, users should be able to install musl with
> --prefix=$HOME/musl and build binaries which will run on any system
> with the musl loader in /lib.
Do you have any good ideas for what we should do here? Some folks on
IRC have also been asking about the motivations for the change. The
ones I recall are:
1. (not a valid reason) Debian policy. As long as a Debian package for
musl is making its own lib dir (e.g. /usr/musl/lib or whatever) I
think it's exempt from policy on library versioning, just like firefox
or something that has package-local .so files.
2. Versioning. It's impossible to have multiple versions installed
simultaneously. However, I don't see how the proposed change would
help. /lib/ld-musl-$(ARCH).so.1 is not versioned either. The ".1" is
not a version that will change (unless we had a major new ABI) but
rather a silly convention. So I don't think this is a valid reason for
the change anyway, though it could be a valid reason for _alternate_
changes.
3. Performance. Having the PT_INTERP be a symbolic link adds a
symbolic link dereference in each exec() syscall for a dynamic linked
program. In theory, avoiding that should shave some time off exec().
4. Allowing $(libdir) on non-root partition.
The alternate change I came up with that would address issue 2, but
not 3 or 4, is making the real file be $(libdir)/musl-$(VERSION).so or
similar, and having both libc.so and ld-musl be symlinks to it.
However this also has the negative aspect of requiring the symlink in
$(syslibdir) to change with each upgrade, which is frustrating if
you're trying to allow a single user to upgrade musl without write
permission to /lib.
If there are no good solutions right now, I think it may be best to
leave this issue alone for the time being. But if a change is going to
be made, I want it to happen as far away from 1.0 as possible, so
please start thinking about good ideas for how this should work! :)
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
