Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 498114 - sys-libs/musl: headers-only build fails for arm targets
Summary: sys-libs/musl: headers-only build fails for arm targets
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Anthony Basile
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: musl-porting
  Show dependency tree
 
Reported: 2014-01-15 00:09 UTC by myoung008
Modified: 2014-10-11 11:44 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
musl-info.log (cross-arm-armv6j-linux-musl-info.log,16.29 KB, text/x-log)
2014-01-15 00:09 UTC, myoung008
Details
musl-headers.log (cross-arm-armv6j-linux-musl-musl-headers.log.xz,1.57 KB, application/x-xz)
2014-01-15 00:11 UTC, myoung008
Details
Patch to make musl work with crossdev (musl-cross.patch,277 bytes, patch)
2014-10-11 11:34 UTC, Felix Janda
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description myoung008 2014-01-15 00:09:56 UTC
Created attachment 367862 [details]
musl-info.log

* crossdev version:      20131011
 * Host Portage ARCH:     x86
 * Target Portage ARCH:   arm
 * Target System:         arm-armv6j-linux-musl
 * Stage:                 4 (C/C++ compiler)
 * ABIs:                  default

 * binutils:              binutils-[latest]
 * gcc:                   gcc-[latest]
 * headers:               linux-headers-[latest]
 * libc:                  musl-[latest]

 * CROSSDEV_OVERLAY:      /usr/local/portage
 * PORT_LOGDIR:           /var/log/portage
 * PORTAGE_CONFIGROOT:    
 * Portage flags:         

!!! WARNING - Cannot auto-configure CHOST arm-armv6j-linux-musl
!!! You should edit /usr/arm-armv6j-linux-musl/etc/portage/make.conf
!!! by hand to complete your configuration
 * Log: /var/log/portage/cross-arm-armv6j-linux-musl-binutils.log
 * Emerging cross-binutils ...                                                                                                 [ ok ]
 * Log: /var/log/portage/cross-arm-armv6j-linux-musl-linux-headers-quick.log
 * Emerging cross-linux-headers-quick ...                                                                                      [ ok ]
 * Log: /var/log/portage/cross-arm-armv6j-linux-musl-musl-headers.log
 * Emerging cross-musl-headers ...

 * musl failed :(
 * If you file a bug, please attach the following logfiles:
 * /var/log/portage/cross-arm-armv6j-linux-musl-info.log
 * /var/log/portage/cross-arm-armv6j-linux-musl-musl-headers.log.xz
 * /var/tmp/portage/cross-arm-armv6j-linux-musl/musl*/temp/musl-config.logs.tar.xz
Comment 1 myoung008 2014-01-15 00:11:09 UTC
Created attachment 367864 [details]
musl-headers.log
Comment 2 myoung008 2014-01-15 00:21:38 UTC
This attempt was on a x86_64 host, chrooted base x86/i486 stage3 image and crossdev emerged.  I also tried on the main system install which is x86_64.
# crossdev --target arm-armv6j-linux-musl
There is a symlink made (by configure I think) in %workpath%/include/bits:
on x86 chroot it points to ../arch/x86 which doesn't exist, but ../arch/i386 does
on native x86_64 it points to ../arch/amd64, also doesn't exist, but ../arch/x86_64 does

I'm fairly new to cross compiling (second target arch) so I really have no idea what/where to patch, but am willing to test any proposed solutions.

Thanks in advance!



Portage 2.2.7 (default/linux/x86/13.0, gcc-4.7.3, glibc-2.16.0, 3.12.7-gentoo x86_64)
=================================================================
System uname: Linux-3.12.7-gentoo-x86_64-Intel-R-_Core-TM-2_Duo_CPU_P8400_@_2.26GHz-with-gentoo-2.2
KiB Mem:    12273100 total,   8929432 free
KiB Swap:          0 total,         0 free
Timestamp of tree: Tue, 14 Jan 2014 19:30:01 +0000
ld GNU ld (GNU Binutils) 2.23.1
app-shells/bash:          4.2_p45
dev-lang/python:          2.7.5-r3, 3.3.2-r2
dev-util/pkgconfig:       0.28
sys-apps/baselayout:      2.2
sys-apps/openrc:          0.12.4
sys-apps/sandbox:         2.6-r1
sys-devel/autoconf:       2.69
sys-devel/automake:       1.13.4
sys-devel/binutils:       2.23.1
sys-devel/gcc:            4.7.3-r1
sys-devel/gcc-config:     1.7.3
sys-devel/libtool:        2.4.2
sys-devel/make:           3.82-r4
sys-kernel/linux-headers: 3.9 (virtual/os-headers)
sys-libs/glibc:           2.16.0
Repositories: gentoo x-portage
ACCEPT_KEYWORDS="x86"
ACCEPT_LICENSE="* -@EULA"
CBUILD="i486-pc-linux-gnu"
CFLAGS="-O2 -march=i486 -pipe"
CHOST="i486-pc-linux-gnu"
CONFIG_PROTECT="/boot/cmdline.txt /boot/config.txt /etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/themes/oxygen-gtk/gtk-2.0"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/apache2-php5.5/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cgi-php5.5/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/php/cli-php5.5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-O2 -march=i486 -pipe"
DISTDIR="/usr/portage/distfiles"
FCFLAGS="-O2 -march=i686 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync"
FFLAGS="-O2 -march=i686 -pipe"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
PKGDIR="/usr/portage/packages/x86"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
USE="acl berkdb bindist bzip2 cli cracklib crypt cxx dri fortran gdbm iconv ipv6 modules mudflap ncurses nls nptl openmp pam pcre readline session ssl tcpd unicode x86 zlib" ABI_X86="32" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, MAKEOPTS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, SYNC, USE_PYTHON
Comment 3 SpanKY gentoo-dev 2014-01-15 00:26:11 UTC
please do not cc people yourself.  the CBUILD is irrelevant.

also, your CTARGET makes no sense.  it most likely should be:
  armv6j-linux-musl
Comment 4 myoung008 2014-01-15 17:31:07 UTC
(In reply to SpanKY from comment #3)
> please do not cc people yourself.  the CBUILD is irrelevant.
> 
> also, your CTARGET makes no sense.  it most likely should be:
>   armv6j-linux-musl

Sorry for the CCs.  I tried again with the CTARGET you suggested and got an error merging binutils, said that armv6j machine is unknown.  Checking the target for the original RPi build, I think the target I am looking for is armv6j-hardfloat-linux-musl.  With this target I'm back to the original error that caused me to report the bug in the first place.

I also tried the new target directly on the RPi, which is one of the original models with 256M ram.  I need to track down a larger SD card and give it some swap.  After several hours it ran out of memory merging binutils.  I don't know if crossdev is the efficient way to go when only changing the libc.  I figure it should work given enough memory and time.  I would prefer getting x86 or x86_64 CHOST so I don't go gray waiting for it.

I don't understand why you mention CBUILD, probably due to my own ignorance.  Are you suggesting that the symlink that is made should point to the arm arch instead of the host arch?  In a non-cross environment I could figure out how to patch the ebuild, but where would I experiment with that type of patch when using crossdev?

Thanks.

Marc
Comment 5 SpanKY gentoo-dev 2014-01-16 02:52:14 UTC
the build host (CBUILD) is irrelevant (x86/amd64).  this is most likely an issue that needs sorting in the musl ebuild itself.  we have similar header hacks in all the other C lib ebuilds (newlib/glibc/uclibc/etc...).

i haven't messed with musl so i don't know anything about its build system.
Comment 6 myoung008 2014-01-16 17:12:08 UTC
(In reply to SpanKY from comment #5)
> the build host (CBUILD) is irrelevant (x86/amd64).  this is most likely an
> issue that needs sorting in the musl ebuild itself.  we have similar header
> hacks in all the other C lib ebuilds (newlib/glibc/uclibc/etc...).
> 
> i haven't messed with musl so i don't know anything about its build system.

That gives me a starting place.  I'll look into the other libc ebuilds and see what I can figure out.  If I come up with a workable patch i'll post it here.

Thanks.

Marc
Comment 7 Anthony Basile gentoo-dev 2014-02-20 23:35:13 UTC
(In reply to myoung008 from comment #6)
> (In reply to SpanKY from comment #5)
> > the build host (CBUILD) is irrelevant (x86/amd64).  this is most likely an
> > issue that needs sorting in the musl ebuild itself.  we have similar header
> > hacks in all the other C lib ebuilds (newlib/glibc/uclibc/etc...).
> > 
> > i haven't messed with musl so i don't know anything about its build system.
> 
> That gives me a starting place.  I'll look into the other libc ebuilds and
> see what I can figure out.  If I come up with a workable patch i'll post it
> here.
> 
> Thanks.
> 
> Marc

Its because the configure file takes --target="${CTARGET}" which is arm-gentoo-linux-musl (in my case at least).  In configure, this gets parsed and sets ARCH=arm but that gets overridden by ARCH=amd64 (in my case) when running Makefile in src_compile().  The sym link gets created include/bits -> ../arch/amd64 which is wrong. In fact, very wrong because it should be ../arch/arm and also because musl calls amd64 x86_64 so the sym link points to nowhere.

You can "hack" this by forcing export ARCH=arm at the top of src_compile(), but I need to fix it correctly.
Comment 8 Anthony Basile gentoo-dev 2014-02-21 17:42:57 UTC
(In reply to Anthony Basile from comment #7)
> (In reply to myoung008 from comment #6)
> > (In reply to SpanKY from comment #5)
> > > the build host (CBUILD) is irrelevant (x86/amd64).  this is most likely an
> > > issue that needs sorting in the musl ebuild itself.  we have similar header
> > > hacks in all the other C lib ebuilds (newlib/glibc/uclibc/etc...).
> > > 
> > > i haven't messed with musl so i don't know anything about its build system.
> > 
> > That gives me a starting place.  I'll look into the other libc ebuilds and
> > see what I can figure out.  If I come up with a workable patch i'll post it
> > here.
> > 
> > Thanks.
> > 
> > Marc
> 
> Its because the configure file takes --target="${CTARGET}" which is
> arm-gentoo-linux-musl (in my case at least).  In configure, this gets parsed
> and sets ARCH=arm but that gets overridden by ARCH=amd64 (in my case) when
> running Makefile in src_compile().  The sym link gets created include/bits
> -> ../arch/amd64 which is wrong. In fact, very wrong because it should be
> ../arch/arm and also because musl calls amd64 x86_64 so the sym link points
> to nowhere.
> 
> You can "hack" this by forcing export ARCH=arm at the top of src_compile(),
> but I need to fix it correctly.

Okay mostly ignore this (apparently crack is bad for the brain).  Its because of the following test failing in configure:

printf "checking whether compiler's long double definition matches float.h... "
echo '#include <float.h>' > "$tmpc"
echo '#if LDBL_MANT_DIG == 53' >> "$tmpc"
echo 'typedef char ldcheck[9-(int)sizeof(long double)];' >> "$tmpc"
echo '#endif' >> "$tmpc"
if $CC $CFLAGS_C99FSE -I./arch/$ARCH -I./include $CPPFLAGS $CFLAGS \
  -c -o /dev/null "$tmpc" >/dev/null 2>&1 ; then
printf "yes\n"
else
printf "no\n"
fail "$0: error: unsupported long double type"
fi

which means configure doesn't finish running and ARCH is not set etc.

There is a further issue at stage with wchar_t being defined by musl's bits/alltypes.h as unsigned and by gcc as int, but that's a different issue.
Comment 9 Anthony Basile gentoo-dev 2014-02-23 13:18:57 UTC
I've completed an armv7a-hardfloat-linux-musleabi cross on x86_64-pc-linux-gnu, and I'm working on a stage4-armv7a-hardfloat-linux-musleabi which I'll add to the tree once I'm happy with it.  But there was a problem at stage3 when building musl for sys-root.  The build used the CBUILD and not the CHOST while still setting ARCH=arm.  Of course, all the asm barfed.  I have to still figure out how to get crossdev and musl's build system to play nice.

On the positive side, native musl compiling is fine.
Comment 10 myoung008 2014-02-25 00:06:13 UTC
Thanks for your time on this.  I'm still very new to cross compiling, let alone an alternate libc.  I think I'll get my odroid-U3 (quad armv7a) out tonight and use crossdev to make a musl environment and see how that goes.  I don't remember how far it's rootfs is set up yet (started from scratch using crossdev) so I may have some work to do before I get there.  From your description it sounds like I'll be able to crossdev musleabi on the native arch.

Not quite as efficient as my x86_64, but this is the bleeding edge, right?  :)

Thanks again.

Marc
Comment 11 Felix Janda 2014-10-10 18:28:55 UTC
A CC=true seems to make the configure script happy.
Comment 12 Felix Janda 2014-10-11 11:34:31 UTC
Created attachment 386426 [details, diff]
Patch to make musl work with crossdev

Tested with i686 and powerpc on am64.
There is likely a nicer way to export the right CC.
Comment 13 Anthony Basile gentoo-dev 2014-10-11 11:44:24 UTC
(In reply to Felix Janda from comment #12)
> Created attachment 386426 [details, diff] [details, diff]
> Patch to make musl work with crossdev
> 
> Tested with i686 and powerpc on am64.
> There is likely a nicer way to export the right CC.

Committed thanks.