On Sat, Jun 18, 2016 at 6:27 AM, Otavio Salvador <[email protected]> wrote: > Hello, > > At O.S. Systems we are involved in some projects which uses musl as > libC. For those, we are doing the SDK for faster development and found > that it is currently broken on Krogoth. > > Master branch has the need fixes. The fixes needed are > OE-Core:2b9ae0ab and OE-Core:fcaaabb4 > > commit 2b9ae0ab056e62290f2328aa0d4dd70e6f138759 > Author: Khem Raj <[email protected]> > Date: Wed May 11 10:35:40 2016 -0700 > > musl: Create symlinks for stub libraries > > Some libraries e.g. libm.so are needed to be > created so that SDKs built with distros which > disable static librararies can have the stubs > and since default linker script requires -lm > this helps in compiling applications with SDK > > there are .a equivalents for these libraries > but they do not land in SDKs when static libs > are disabled distrowide > > Signed-off-by: Khem Raj <[email protected]> > Signed-off-by: Richard Purdie <[email protected]> > > commit fcaaabb401fffcda4db9a7d1f927a2a404e4776d > Author: Khem Raj <[email protected]> > Date: Wed May 11 10:35:45 2016 -0700 > > gcc-runtime, libgcc: Symlink c++ header and startup files in > target_triplet for SDK use > > We build SDKs such that gcc-cross-candian is built for only one > target *-*-linux and then use -muclibc or -mmusl to let it compile > code for other libc variants. This works fine when libc = glibc > however it does not work for c++ programs when libc != glibc since > there are c++ headers installed under > ${includedir}/c++/${BINV}/${TARGET_SYS} > which is fine when gcc-runtime and gcc-cross-candian uses same > --target options > gxx includedir searches in right triplet, but it fails with musl/uclibc > since gcc will look for glibc based triplet but gcc-runtime will install > them under musl/uclibc triplet. > > This patch symlinks the musl/uclibc triplet to glibc triplet when > libc != glibc > > This fixes SDKs for musl/uclibc > > Signed-off-by: Khem Raj <[email protected]> > Signed-off-by: Richard Purdie <[email protected]> > > Backporting those, on top of current Krogoth branch, fixes the SDK > issues we had at the moment. > > Could those be reviewed and queued for the next backport?
They look fine for backport to krogoth. Please submit pull requests > > -- > Otavio Salvador O.S. Systems > http://www.ossystems.com.br http://code.ossystems.com.br > Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
