From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3924 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Progress on roadmap to 0.9.13 Date: Sat, 17 Aug 2013 12:29:57 -0400 Message-ID: <20130817162957.GB20515@brightrain.aerifal.cx> References: <20130815075912.GA705@brightrain.aerifal.cx> <20130817123913.771df1d0@vostro> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1376757009 22662 80.91.229.3 (17 Aug 2013 16:30:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Aug 2013 16:30:09 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3928-gllmg-musl=m.gmane.org@lists.openwall.com Sat Aug 17 18:30:13 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1VAjOE-0003aK-Qd for gllmg-musl@plane.gmane.org; Sat, 17 Aug 2013 18:30:10 +0200 Original-Received: (qmail 29714 invoked by uid 550); 17 Aug 2013 16:30:10 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 29706 invoked from network); 17 Aug 2013 16:30:09 -0000 Content-Disposition: inline In-Reply-To: <20130817123913.771df1d0@vostro> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3924 Archived-At: On Sat, Aug 17, 2013 at 12:39:13PM +0300, Timo Teras wrote: > On Thu, 15 Aug 2013 03:59:12 -0400 > Rich Felker 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. > /lib/ld-musl-.so.1 -> libc-arch.so. /usr/lib/libc.so -> /lib/libc.so. > /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