From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1258 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Hello Date: Fri, 6 Jul 2012 20:57:39 -0400 Message-ID: <20120707005739.GT544@brightrain.aerifal.cx> References: <4FD0D6D9.5080707@barfooze.de> <20120607161928.GE163@brightrain.aerifal.cx> <20120608011516.0b5fca7d@sibserver.ru> <20120608033141.GH163@brightrain.aerifal.cx> <20120706012417.5ae680f0@sibserver.ru> <20120705233457.GR544@brightrain.aerifal.cx> <20120706140601.252e4e83@sibserver.ru> <20120706062614.GS544@brightrain.aerifal.cx> <20120706162205.5c72cd6a@sibserver.ru> <35058.132.241.65.68.1341616457.squirrel@lavabit.com> 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: dough.gmane.org 1341622752 773 80.91.229.3 (7 Jul 2012 00:59:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 7 Jul 2012 00:59:12 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1259-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jul 07 02:59:12 2012 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 1SnJMZ-000156-9M for gllmg-musl@plane.gmane.org; Sat, 07 Jul 2012 02:59:07 +0200 Original-Received: (qmail 26103 invoked by uid 550); 7 Jul 2012 00:59:06 -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 26095 invoked from network); 7 Jul 2012 00:59:06 -0000 Content-Disposition: inline In-Reply-To: <35058.132.241.65.68.1341616457.squirrel@lavabit.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1258 Archived-At: On Fri, Jul 06, 2012 at 04:14:17PM -0700, idunham@lavabit.com wrote: > >> Have you looked into building the apps/libs natively against musl > >> except for the nvidia binary blob, to see if the blob works under that > >> usage? I think that's a usage case that's a lot more applicable to > >> real-world usage of musl, and in fact it's probably the first real > >> reason anybody would be interested in having musl work with code that > >> was built against glibc... > The first step would probably be dropping a musl-compatible (generic, not > gnu-linux) libstdc++ into the test environment. Actually, generic vs gnu-linux locale crap is not the issue here. The *ABI* support stuff in musl should make the gnu-linux code work on musl if it was already compiled using glibc headers. It's the headers that are incompatible with the gnu-linux os tree because we don't do the ugly table-based stuff (which is much more bloated and probably slower). The issue that DOES matter with libstdc++ is name mangling. musl's ABI-compat is limited to C. The type sizes and non-opaque type representations match what's used on glibc/LSB, but the struct tags and specific types for abstract opaque types like FILE and pthread_t differ, meaning the name mangling will differ... Thus while you can in theory use glibc-linked C++ programs with musl's LSB ABI support, you can't mix-and-match glibc-linked C++ program/library code and musl-linked C++ program/library code in a single program. The name mangling will fail to match and the dynamic linker will fail to resolve the C++ stuff. Rich