From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12393 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: any one managed to compile and run xz-5.0.8 or xz-5.2.3 ? Date: Wed, 24 Jan 2018 19:29:31 -0500 Message-ID: <20180125002931.GB1627@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1516840077 8739 195.159.176.226 (25 Jan 2018 00:27:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 25 Jan 2018 00:27:57 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Po-yi Wang To: musl@lists.openwall.com Original-X-From: musl-return-12409-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jan 25 01:27:53 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1eeVOH-0001Gp-TA for gllmg-musl@m.gmane.org; Thu, 25 Jan 2018 01:27:41 +0100 Original-Received: (qmail 7928 invoked by uid 550); 25 Jan 2018 00:29:44 -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 7905 invoked from network); 25 Jan 2018 00:29:43 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12393 Archived-At: On Wed, Jan 24, 2018 at 04:18:59PM -0800, Po-yi Wang wrote: > hi > > any one managed to compile and run xz with musl on ppc target ? > i've managed to compile and run "xz --version" on i486 and arm > targets, but not on ppc target. i've tried gcc-3.4.5 and gcc-4.1.2. > gcc-3.4.5 version simply hangs, while gcc-4.1.2 version seg faults -- > with seg fault, i can at least use gdb to get some info out. i do > not know how to use gdb to trace a hanged program. anyway, this is > the output for gcc-4.1.2 compiled version. (xz-5.0.8): Where did you get gcc 3.4.5 or 4.1.2 toolchains for musl ppc? Is any other software working when compiled with them? If you're not using a real cross or native musl toolchain but the musl-gcc wrapper, it probably lacks a lot of stuff it needs to work on ppc. In particular a ppc toolchain that will be used for dynamic-linking needs to be configured to always use "secure-plt", and whether static or dynamic, it needs to be using 64-bit long double. You should have hit an error configuring musl here if the compiler doesn't match: checking whether compiler's long double definition matches float.h... Please provide more details. > gdb src/xz/xz > > GNU gdb (GDB) 7.12.1 > Copyright (C) 2017 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "powerpc-unknown-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > . > Find the GDB manual and other documentation resources online at: > . > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from src/xz/xz...done. > (gdb) run --version > Starting program: /tmp/build/xz-5.0.8/src/xz/xz --version > > Program received signal SIGSEGV, Segmentation fault. > 0x4806fab8 in _dlstart_c (sp=0xbffff4a0, dynv=0x480b2ae4) at > ldso/dlstart.c:146 > 146 GETFUNCSYM(&dls2, __dls2, base+dyn[DT_PLTGOT]); > (gdb) bt > #0 0x4806fab8 in _dlstart_c (sp=0xbffff4a0, dynv=0x480b2ae4) > at ldso/dlstart.c:146 > #1 0x480778ec in _dlstart () from /lib/ld-musl-powerpc-sf.so.1 > (gdb) quit > A debugging session is active. > > Inferior 1 [process 22188] will be killed. > > Quit anyway? (y or n) y This is an odd place to crash, and if it's crashing here it's almost surely crashing for all programs, not just xz, since it hasn't gotten to the point of looking at the program being run. It could be an issue with very-outdated binutils doing something funny at link time linking libc.so. Rich