Re: any one managed to compile and run xz-5.0.8 or xz-5.2.3 ?

[Po-yi Wang <player@vcn.bc.ca>]

On Wed, 24 Jan 2018, Rich Felker wrote:

> 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
gcc-3.4.5 from :
http://www.kegel.com/crosstool/crosstool-0.43/doc/crosstool-howto.html
gcc-4.1.2 version from :
http://clfs.org/view/CLFS-3.0.0-SYSVINIT/
(this one is originally gcc-4.9.3 but i downgraded it to compile with
"--with-float=soft", which i could not get working with gcc-4.9.3 -- i 
might try again later. it was quite some time ago.)

the environment for ppc and arm, are chrooted, with only /proc /dev/pts 
mounted. no /sys. (does not seem to pose problem for arm version)

gcc built with: (overwriting gcc-4.9.3) 
# for ppc # this version is known to built ok earlier
WGET_UNPACK gcc-4.1.2.tar.xz
rm -rf b; mkdir b ; cd b
../configure --prefix=/usr --with-local-prefix=/usr --enable-shared 
--with-float=soft \
  --disable-nls --enable-languages=c,c++ --disable-multilib 
--disable-bootstrap \
   --disable-threads --disable-libmudflap --disable-libssp 
--disable-libgomp --disable-decimal-float
# make BOOT_LDFLAGS="-static" bootstrap                 || INTERVENTION 
$LINENO
make                                                  || INTERVENTION 
$LINENO
make install                                          || INTERVENTION 
$LINENO

# fix for gdb # gdb compiled with new gcc-4.1.2
ln -sfvn libstdc++.so.6.0.8 /usr/lib/libstdc++.so.6

# kernel header:
MUSL_BASE=/usr/musl
mkdir -p $MUSL_BASE
WGET_UNPACK linux-2.6.32.tar.xz
sed -i "/strict/d" scripts/headers_install.pl
sed -i "/strict/d" scripts/headers_check.pl
make headers_check && make INSTALL_HDR_PATH=$MUSL_BASE headers_install || 
INTERVENTION $LINENO

# musl:
CFLAGS="$CFLAGS -Os" ; gcc --version ; ld --version ; echo $CFLAGS
MUSL_BASE=/usr/musl
WGET_UNPACK musl-1.1.18.tar.xz
./configure --prefix=$MUSL_BASE
make         || INTERVENTION $LINENO
make install || INTERVENTION $LINENO
cd $MUSL_BASE/bin
ln -sfvn $(type -path ar) musl-ar
ln -sfvn $(type -path strip) musl-strip

# xz-5.0.8:
WGET_UNPACK xz-5.0.8.tar.xz
LDFLAGS="-static"  CC=musl-gcc ./configure --prefix=/tools --disable-nls
LDFLAGS="-static"  CC=musl-gcc make || INTERVENTION $LINENO

> 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...
i remembered seeing the check when compiling musl. it must have been ok, 
othersize it refused to compile. (that is why i downgraded gcc-4.9.3)

building with gnu tools has always been a huge pain for the last 18 
years... i am using musl wrapper to compile static commands, it seems to 
work well enough. my arm board has only 256m of memory, sometimes 
configure takes longer to run then the actually compiling ... anyway, i 
have no access or information on native musl toolchain. i used to use 
uclibc wrapper, but it was too old, and the newer uclibc seem difficult 
with lots of options. i am converting glibc compiled commands to musl. i 
am about 33% done.

>
> 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
>> <http://gnu.org/licenses/gpl.html>
>> 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:
>> <http://www.gnu.org/software/gdb/bugs/>.
>> Find the GDB manual and other documentation resources online at:
>> <http://www.gnu.org/software/gdb/documentation/>.
>> 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
>