From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3923 Path: news.gmane.org!not-for-mail From: orc Newsgroups: gmane.linux.lib.musl.general Subject: Re: Progress on roadmap to 0.9.13 Date: Sat, 17 Aug 2013 23:39:43 +0800 Message-ID: <20130817233943.6c591ddf@sibserver.ru> 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 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1376754076 25334 80.91.229.3 (17 Aug 2013 15:41:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Aug 2013 15:41:16 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3927-gllmg-musl=m.gmane.org@lists.openwall.com Sat Aug 17 17:41:19 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 1VAicx-0006CG-IU for gllmg-musl@plane.gmane.org; Sat, 17 Aug 2013 17:41:19 +0200 Original-Received: (qmail 27726 invoked by uid 550); 17 Aug 2013 15:41:18 -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 27718 invoked from network); 17 Aug 2013 15:41:18 -0000 In-Reply-To: <20130817123913.771df1d0@vostro> X-Mailer: claws-mail Xref: news.gmane.org gmane.linux.lib.musl.general:3923 Archived-At: On Sat, 17 Aug 2013 12:39:13 +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. > > - 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. > > 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. > > - Timo I generally don't like the idea of symlink change, but if it will go, I will not argue. But, how existing installs will resolve that change in one pass during install? Do I need static busybox to manually replace symlink? I even suggest making a hard link between them, so no symlink issue will be there :) It requires a bit more work without benefit. Point me please to benefits page/mail, because I lost in my imap cache.