[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130817162957.GB20515@brightrain.aerifal.cx>
Date: Sat, 17 Aug 2013 12:29:57 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Progress on roadmap to 0.9.13
On Sat, Aug 17, 2013 at 12:39:13PM +0300, Timo Teras wrote:
> On Thu, 15 Aug 2013 03:59:12 -0400
> Rich Felker <dalias@...ifal.cx> wrote:
>
> > One key target for 0.9.13 which I didn't cover above is improving
> > "make install" and possibly tweaking the symlink strategy for libc.so
> > and ld-musl.so. At several times in the past, I was fairly convinced
> > that it makes more sense to reverse the symlink direction and have
> > libc.so point to ld-musl.so rather than the other way around. However,
> > I keep going back to doubting that there's any good reason for it to
> > change. So if there are people who still care about this issue, I'd
> > really like to hear you speak up _now_ rather than 2 days before the
> > next release, or after the next release. If there's no progress on
> > justifying changes, I think the only changes I'm going to make in this
> > area are to fix lack-of-atomicity issues during installation.
>
> Sorry for late answer.
>
> IIRC the advantages were:
>
> - Easier to install different subarch (even compatible arch versions)
> side by side. As ld.so names are unique - libc.so is same for all so
> those would need to be renamed anyway.
I don't see how this would help. If you have multiple incompatible
ABIs present on a system, each one needs its own separate library
dirs, both for development libraries and runtime libraries. Thus each
dir can have its own libc.so without affecting the others. (libc.so is
not special in this way; the same applies to non-system libraries like
libz.so, etc. as well.)
> - libc.so and libc.a can go to /usr/lib if libc.so is just an
> optional symlink. this is desirable as the development stuff are not
> nice to keep in /lib.
Are you talking about the case where /usr is a separate partition not
mounted at first?
> So I would at least like to have the symlink direction changed.
>
> Or alternatively have something like:
> /lib/libc-arch.so.<abiver>
> /lib/ld-musl-<arch>.so.1 -> libc-arch.so.<abiver
> /usr/lib/libc.so -> /lib/libc.so.<abiver>
> /usr/lib/libc.a
>
> Allowing of course /usr/lib to be a toolchain specific prefix.
This works, but I'm unclear on how it would be better than the current
situation, except for the partitions issue. It does seem worse in one
way: that libc-arch.so.1 could get accidentally linked against and
included in DT_NEEDED. This could be avoided by varying the name
slightly, e.g. libc.arch.so.1, I think.
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.
