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.