Custom Query (532 matches)
Results (31 - 33 of 532)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #938 | wontfix | musl only supports o32 hard float on MIPS | ||
| Description |
Remove other choices from MIPS build so things won't bonk. |
|||
| #939 | wontfix | Make musl ld have a common name | ||
| Description |
Currently the gcc patch used for musl defines different names for the ld program for each arch and even sub-arch (like armhf vs armeb vs arm). This is annoying and results in needing many symlinks to point the properly named ld to libc.so since musl's ld is within libc.so. I'm not sure why different names for each ld are used, possibly for multilib-like use, but when not building multilib and for a specific target this seems like extra complexity. Fix would be done within the gcc patch for musl and then updating the symlinks listed in cross-tools/common/libc.xml. |
|||
| #940 | fixed | Fix kernel build instructions | ||
| Description |
Kernel build right now is all sorts of silly. Sadly, many embedded dev kits are not able to boot mainline Linux kernels but often ship with either an evil vendor source tree or just an evil vendor binary. As long as the evil vendor's kernel is newer than the headers we install, that'll be OK. But how exactly does one instruct someone to build a kernel for an embedded board? Since there's so many damn choices in menuconfig that really do matter, let alone device tree. Would a viable path be to build for a QEMU target but say, "Do it like this, just for your board."? |
|||
