Bug 10129 - gcc-runtime fails to build if libunwind in sysroot with musl
Summary: gcc-runtime fails to build if libunwind in sysroot with musl
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: devtools / tool chain (show other bugs)
Version: 2.2
Hardware: All Multiple
: High major
Target Milestone: 2.2 M3
Assignee: Richard Purdie
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2016-08-11 21:54 UTC by Leonardo Sandoval Gonzalez
Modified: 2016-08-24 15:35 UTC (History)
7 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Leonardo Sandoval Gonzalez 2016-08-11 21:54:50 UTC
Full log on [1] and also attached. musl toolchain is failing when compiling gcc-runtime:

| Makefile:653: recipe for target 'eh_type.lo' failed
| make[2]: *** [eh_type.lo] Error 1
| make[2]: Leaving directory '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-musl/build/build/tmp/work/i586-poky-linux-musl/gcc-runtime/6.1.1-r0/gcc-6.1.1/build.i586-poky-linux-musl.i586-poky-linux-musl/i586-poky-linux-musl/libstdc++-v3/libsupc++'
| Makefile:507: recipe for target 'all-recursive' failed
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-musl/build/build/tmp/work/i586-poky-linux-musl/gcc-runtime/6.1.1-r0/gcc-6.1.1/build.i586-poky-linux-musl.i586-poky-linux-musl/i586-poky-linux-musl/libstdc++-v3'
| Makefile:414: recipe for target 'all' failed
| make: *** [all] Error 2
| ERROR: Function failed: do_compile (log file is located at /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-musl/build/build/tmp/work/i586-poky-linux-musl/gcc-runtime/6.1.1-r0/temp/log.do_compile.6101)
NOTE: recipe gcc-runtime-6.1.1-r0: task do_compile: Failed
ERROR: Task /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-musl/build/meta/recipes-devtools/gcc/gcc-runtime_6.1.bb:do_compile (/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-musl/build/meta/recipes-devtools/gcc/gcc-runtime_6.1.bb:do_compile) failed with exit code '1'
NOTE: recipe gdb-cross-i586-7.11-r0: task do_fetch: Succeeded

[1] https://autobuilder.yoctoproject.org/main/builders/nightly-musl/builds/212
Comment 1 Ross Burton 2016-08-15 15:06:04 UTC
Log wasn't attached.  I think http://errors.yoctoproject.org/Errors/Details/74601/ is the right one.
Comment 2 Ross Burton 2016-08-15 15:24:20 UTC
You can replicate this on demand:

TCLIBC=musl
bitbake libunwind
bitbake gcc-runtime -C configure
Comment 3 Khem Raj 2016-08-15 17:45:48 UTC
(In reply to comment #2)
> You can replicate this on demand:
> 
> TCLIBC=musl
> bitbake libunwind
> bitbake gcc-runtime -C configure

It sounds to similar build issue we have had while compiling gcc for target on musl.
Issue here is that there are two unwind.h files. One coming from libunwind which is staged into /usr/include and another one is from gcc itself, which is also staged under gcc's include and fixed-include directories. When we build any of gcc components they expect to use internal version and that works with glibc based gcc since the search headers first look into gcc headers, however with musl the gcc headers are searched after the standard headers ( which is by design the right thing )

The problem however, then becomes that as soon as libunwind it staged it starts getting the wrong header where as it has been configured to use gcc's header

This should be fixed in gcc sources itself, where it ensures that right header is included when its building itself and does not rely on compiler's paths to do the right thing.

A short term solution could be to add a build time gcc-runtime dep to libunwind recipe
so we are sure that gcc-runtime is built and staged before libunwind is built.
Comment 4 Richard Purdie 2016-08-18 11:04:29 UTC
Sadly, a dependency isn't enough. The system can install libunwind from sstate before gcc-runtime builds since there is no target do_populate_sysroot interdependency, nor should their be.