From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4514 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: dlopen'ing glibc linked libraries Date: Thu, 23 Jan 2014 11:07:55 +0100 Message-ID: <20140123100755.GM1685@port70.net> References: <52DE84BF.2090001@barfooze.de> <20140121181726.GL1685@port70.net> 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 1390471681 23336 80.91.229.3 (23 Jan 2014 10:08:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Jan 2014 10:08:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4518-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jan 23 11:08:10 2014 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 1W6HCi-0005Uk-SM for gllmg-musl@plane.gmane.org; Thu, 23 Jan 2014 11:08:08 +0100 Original-Received: (qmail 26570 invoked by uid 550); 23 Jan 2014 10:08:07 -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 26561 invoked from network); 23 Jan 2014 10:08:07 -0000 Content-Disposition: inline In-Reply-To: <20140121181726.GL1685@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4514 Archived-At: * Szabolcs Nagy [2014-01-21 19:17:27 +0100]: > it may be possible to solve a lot of compatibility issues with > preloading an extra lib next to musl, i experimented with running > applications with > > export LD_LIBRARY_PATH=/usr/lib:/usr/lib/i386-linux-gnu:/lib/i386-linux-gnu > export LD_PRELOAD=./libcompat.so > /lib/ld-musl-i386.so /usr/bin/something i did further experiments, the issues i found so far: - brk pointer is sometimes at the wrong place at start up so malloc fails (kernel bug, rarely happens here) - some applications read /proc/self/exe to determine the path to their binary (to start other instances with different arguments) but that will point to the loader - some applications use gcc's closure extension so they need executable stack (the kernel maps the loader with non-executable stack) these are all rare and can be worked around by modifying the interpreter in the binary using patchelf (or setting up a namespace where /lib/ld-linux.so.2 points to musl) - binaries compiled without _FILE_OFFSET_BITS=64 are not compatible with musl on i386 (on my debian stable system there are more than 200 binaries and libraries which use readdir, __[fl]xstat instead of readdir64, __[fl]xstat64) (this is probably the biggest obstacle for compatibility) - programs using sbrk fail (affects programs that try to implement their own malloc (eg bash) or programs using the boehm gc) (this will go away when musl's alloc is updated) - i had to add many symbols (>300) most of them are trivial wrappers, but some of them would be hard to do correctly (the implementation internals like __pthread_register_cancel and the messy nss/nscd/rpc apis are the most painful ones)