> On Aug 18, 2016, at 9:43 AM, Khem Raj <raj.k...@gmail.com> wrote: > > >> On Aug 18, 2016, at 6:46 AM, Richard Purdie >> <richard.pur...@linuxfoundation.org> wrote: >> >> Building libunwind, then gcc-runtime causes build failures. This is hard >> to fix since gcc-runtime wants the internal gcc unwind.h header but libunwind >> wants to provide this. There are differences in include behaviour between gcc >> and glibc which are by design. > > based upon C library being musl or glibc > >> >> This patch hacks around the issue by looking for a define used during >> gcc-runtime's >> build and skipping to the internal header in that case. The patch is only >> enabled >> on musl and is the best workaround I could come up with to unblock failing >> builds >> on our auto builder. > > I also saw gcc build failures not only gcc-runtime. I am not able to find the > logs > once I have a reproducer, I will check if it was in libstdc++ as well or > elsewhere > nevertheless this is ok to go in.
It was compiling gcc itself for arm/musl target see http://errors.yoctoproject.org/Errors/Details/73163/ thats why I disabled it on world builds on arm. Real fix would be for gcc to get its act together. > >> >> [YOCTO #10129] >> >> Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org> >> >> diff --git >> a/meta/recipes-support/libunwind/libunwind/musl-header-conflict.patch >> b/meta/recipes-support/libunwind/libunwind/musl-header-conflict.patch >> new file mode 100644 >> index 0000000..79f63fd >> --- /dev/null >> +++ b/meta/recipes-support/libunwind/libunwind/musl-header-conflict.patch >> @@ -0,0 +1,37 @@ >> +If you: >> + >> +TCLIBC=musl bitbake unwind >> +TCLIBC=musl bitbake gcc-runtime -c cleansstate >> +TCLIBC=musl bitbake gcc-runtime >> + >> +you will see libstdc++ fail to build due to finding libunwind's header file. >> + >> +Khem: "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 )." >> + >> +This patch hacks around the issue by looking for a define used during >> gcc-runtime's >> +build and skipping to the internal header in that case. >> + >> +[YOCTO #10129] >> + >> +RP 2016/8/18 >> + >> +Upstream-Status: Inappropriate [really need to fix gcc] >> + >> +Index: git/include/unwind.h >> +=================================================================== >> +--- git.orig/include/unwind.h >> ++++ git/include/unwind.h >> +@@ -23,6 +23,10 @@ LIABLE FOR ANY CLAIM, DAMAGES OR OTHER L >> + OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION >> + WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */ >> + >> ++#ifdef _GLIBCXX_SHARED >> ++#include_next <unwind.h> >> ++#endif > > This is a solution we can live with since _GLIBCXX_SHARED is gcc internal > define, it wont > be visible to other packages. > >> ++ >> + #ifndef _UNWIND_H >> + #define _UNWIND_H >> + >> diff --git a/meta/recipes-support/libunwind/libunwind_git.bb >> b/meta/recipes-support/libunwind/libunwind_git.bb >> index 6d1d9fb..cd4cb89 100644 >> --- a/meta/recipes-support/libunwind/libunwind_git.bb >> +++ b/meta/recipes-support/libunwind/libunwind_git.bb >> @@ -13,6 +13,7 @@ SRC_URI = "git://git.sv.gnu.org/libunwind.git \ >> >> file://0001-ppc32-Consider-ucontext-mismatches-between-glibc-and.patch \ >> " >> >> +SRC_URI_append_libc-musl = " file://musl-header-conflict.patch” > > It should be fine to use it in general too. > >> EXTRA_OECONF_append_libc-musl = " --disable-documentation --disable-tests " >> >> # http://errors.yoctoproject.org/Errors/Details/20487/ >> >> >
signature.asc
Description: Message signed with OpenPGP using GPGMail
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core