From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10214 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl ldd: swt build: Error relocating / symbol not found Date: Thu, 23 Jun 2016 13:10:08 -0400 Message-ID: <20160623171008.GY10893@brightrain.aerifal.cx> References: <576B58E6.6040400@gmail.com> <20160623042448.GX10893@brightrain.aerifal.cx> <576C02C2.7070006@gmail.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: ger.gmane.org 1466701837 8107 80.91.229.3 (23 Jun 2016 17:10:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Jun 2016 17:10:37 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-10227-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jun 23 19:10:27 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 1bG894-000876-OV for gllmg-musl@m.gmane.org; Thu, 23 Jun 2016 19:10:26 +0200 Original-Received: (qmail 9532 invoked by uid 550); 23 Jun 2016 17:10:22 -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 9510 invoked from network); 23 Jun 2016 17:10:22 -0000 Content-Disposition: inline In-Reply-To: <576C02C2.7070006@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:10214 Archived-At: On Thu, Jun 23, 2016 at 03:39:46PM +0000, Andrei Pozolotin wrote: > Rich: > > On 06/23/2016 04:24 AM, Rich Felker wrote: > > On Thu, Jun 23, 2016 at 03:35:02AM +0000, Andrei Pozolotin wrote: > >> https://github.com/random-alpiner/repository/blob/master/bugs/01/1-app.log > >> https://github.com/random-alpiner/repository/blob/master/bugs/01/2-ldd.log > >> https://github.com/random-alpiner/repository/blob/master/bugs/01/3-readelf.log > >> > >> My first guess would be that something else in the application > >> (eclipse) has already caused an older/stale version of libgobject to > >> be loaded, so that the version containing the symbol definition does > >> not get loaded. You could confirm this by running strace on the > >> program and checking what library files it loads/maps. > Thank you for the tip. > > 1) the trace shows: > https://github.com/random-alpiner/repository/blob/master/bugs/01/4-strace.log > > 2) that the proper /usr/lib/libgobject-2.0.so.0 is in fact loaded before > /usr/lib/libswt-atk-gtk-4530.so > > 3) however, the loading starts from > /home/work/space/none-4.5.0/conf/org.eclipse.osgi/748/0/.cp/libswt-gtk-4530.so, > > which is an eclipse default library bundled with the eclipse > application, and which is compiled against foreign libc.6.so: > > lddtree /home/work/space/none-4.5.0/conf/org.eclipse.osgi/748/0/.cp/libswt-gtk-4530.so > libswt-gtk-4530.so => /home/work/space/none-4.5.0/conf/org.eclipse.osgi/748/0/.cp/libswt-gtk-4530.so (interpreter => none) > libc.so.6 => not found OK so it looks like you're trying to run foreign glibc binaries with musl. That might or might not work, and in this case it seems to be not working. You really should be using a build of eclipse and all its libraries against musl rather than putting glibc-linked binaries on the system. > 4) the library loading logic of eclipse is: first try to load bundled > libraries from private paths, > and if that fails, then try to load these libraries from the public > paths, such as "/usr/lib/*", etc. > > 5) I do provide replacement libswt-* libraries built against musl on the > public path "/usr/lib/*", > and the assumption was that when private path library loading fails, > then the library will be loaded from the public path, which "sort of > almost works", > so: > * was that a wrong assumption? > * will in fact musl ld.so reject libraries linked to the libc.so.6? No, it will use them. > * if not, is there a way to tell musl ld.so to blacklist private path > libraries? No, but you could just rm (or mv) them. But I suspect you'll still run into other problems. Support for using glibc-linked programs/libraries is inherently error-prone and really only intended for use in situations where you can't get a properly-built binary (e.g. Flash plugin). Rich