From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10322 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Regarding whole-archive linking libc.a into a shared lib Date: Thu, 14 Jul 2016 11:07:28 -0400 Message-ID: <20160714150728.GN15995@brightrain.aerifal.cx> References: 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 1468508869 27535 80.91.229.3 (14 Jul 2016 15:07:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Jul 2016 15:07:49 +0000 (UTC) Cc: musl@lists.openwall.com To: Jason Ramapuram Original-X-From: musl-return-10335-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jul 14 17:07:49 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1bNiEu-0000jx-H3 for gllmg-musl@m.gmane.org; Thu, 14 Jul 2016 17:07:48 +0200 Original-Received: (qmail 29887 invoked by uid 550); 14 Jul 2016 15:07:46 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 29863 invoked from network); 14 Jul 2016 15:07:45 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:10322 Archived-At: On Thu, Jul 14, 2016 at 12:49:31PM +0200, Jason Ramapuram wrote: > Thanks for the link. Just went through the entire thread. I think we can > solve the problems as such though: > > 1. Have some form of linker that mangles all the symbols internally in > the newly linked shared library, eg: FILE* --> FILE_mangled* so that > internally it has it's own libc calls that are independent from anything > that a binary might require. This is already trivially possible via the --exclude-libs ld option, which is confusingly named but converts all symbols in particular (or all) static libs being linked into hidden symbols. That is sufficient for safely linking some dependency libs statically into a shared library without the risk of breaking things in the program that loads the shared library (I suspect it would work well for something like zlib), but it depends on there being no additional hidden interface surfaces that interact with the rest of the program. For libc those would include (some as noted by others): - the thread structure pointed to by the thread pointer - signal dispositions used internally - assumptions about what actions are excluded by locks - possible leaks of pointers to allocated memory from one libc's malloc to the other one's free. In addition, libc initialization (including the thread structure/pointer for the main thread) is performed as part of the call to __libc_start_main from the crt1 entry point. This will never happen for a copy embedded inside your shared library, and thus you would be running with a libc in uninitialized state. In practice the thread pointer, which is the main thing that needs initialization, would already have been initialized by the "real" libc, so things might "happen to work" with an exact-same-version musl libc.so matching the libc.a you linked with, but on the opposite end of the spectrum things would horribly blow up when your linked-in musl finds a glibc-format thread structure at that address. This is probably only the tip of the iceberg as to what can go wrong with your idea. On the flip side, I don't see what advantages you could get by static linking libc.a into a shared library. If your library is shared, then it necessarily already has a shared libc.so available at runtime (simply because it's being used in a dynamic-linked program). If your intent is to produce a shared library that works with both musl and glibc, that's a nice idea, but a different approach is probably needed, and it would be an interesting discussion to spin off of this thread. Rich