From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9167 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: MUSL issue while loading C++ lib Date: Thu, 21 Jan 2016 21:06:26 +0100 Message-ID: <20160121200626.GD9621@port70.net> References: <20160121171245.GC9621@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 1453406805 16450 80.91.229.3 (21 Jan 2016 20:06:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Jan 2016 20:06:45 +0000 (UTC) Cc: musl@lists.openwall.com To: N Jain Original-X-From: musl-return-9180-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jan 21 21:06:44 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 1aMLVA-0002SQ-NK for gllmg-musl@m.gmane.org; Thu, 21 Jan 2016 21:06:40 +0100 Original-Received: (qmail 18026 invoked by uid 550); 21 Jan 2016 20:06:38 -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 18004 invoked from network); 21 Jan 2016 20:06:38 -0000 Mail-Followup-To: N Jain , musl@lists.openwall.com Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Xref: news.gmane.org gmane.linux.lib.musl.general:9167 Archived-At: * N Jain [2016-01-21 14:05:41 -0500]: > > Also searching online I saw some issues with versions for > GLIBCXX but don't know how to confirm if this is not the problem with MUSL > toolchain I generated. > symbol versioning can cause problems, but gcc-5 libstdc++ and libgcc_s should work > > > echo 'int main(){}' |g++ -xc++ - > > > > I am not sure where to issue this command ? i meant you should create a minimal dynamic linked binary with your toolchain and analyze that > > > readelf -ld ./a.out > > > > INTERP 0x000114 0x00010114 0x00010114 0x00016 0x00016 R 0x1 > [Requesting program interpreter: /lib/ld-musl-arm.so.1] ... > Dynamic section at offset 0xc24 contains 26 entries: > Tag Type Name/Value > 0x00000001 (NEEDED) Shared library: [libstdc++.so.6] > 0x00000001 (NEEDED) Shared library: [libgcc_s.so.1] > 0x00000001 (NEEDED) Shared library: [libc.so] ok > > > strace /lib/ld-musl-*.so.1 ./a.out > > > > I don't have strace capability in my toolchain. > i wanted to see what paths are opened by the musl linker to make sure the right libgcc_s.so.1 is found > > > readelf -d /lib/libstdc++.so.6 > > > 0x00000001 (NEEDED) Shared library: [libc.so] > 0x00000001 (NEEDED) Shared library: [libgcc_s.so.1] > 0x0000000e (SONAME) Library soname: [libstdc++.so.6] ok > > > readelf -aW /lib/libstdc++.so.6 |grep Unwind > > > 00137330 00051c16 R_ARM_JUMP_SLOT 00000000 > _Unwind_Resume_or_Rethrow > 00137510 00083616 R_ARM_JUMP_SLOT 00000000 > _Unwind_GetLanguageSpecificData my readelf prints the @GCC_3.x version suffix here. i'm not sure what's the difference > 1308: 00000000 0 FUNC GLOBAL DEFAULT UND > _Unwind_Resume_or_Rethrow@GCC_3.3 (37) > 2102: 00000000 0 FUNC GLOBAL DEFAULT UND > _Unwind_GetLanguageSpecificData@GCC_3.0 (36) ... > 14022: 00000000 0 FUNC GLOBAL DEFAULT UND > _Unwind_Resume_or_Rethrow@@GCC_3.3 > 14816: 00000000 0 FUNC GLOBAL DEFAULT UND > _Unwind_GetLanguageSpecificData@@GCC_3.0 ok > > > readelf -aW /lib/libgcc_s.so.1 |grep Unwin > > > > 302: 0001b350 28 FUNC GLOBAL DEFAULT 10 > _Unwind_GetLanguageSpecificData@@GCC_3.0 > 620: 0001ae04 36 FUNC GLOBAL DEFAULT 10 > _Unwind_Resume_or_Rethrow@@GCC_3.3 ok (.dynsym has the symbols) > 1917: 0001b350 28 FUNC GLOBAL DEFAULT 10 > _Unwind_GetLanguageSpecificData > 2235: 0001ae04 36 FUNC GLOBAL DEFAULT 10 _Unwind_Resume_or_Rethrow this looks ok too i think the musl linker should be able to deal with this :P