On 28.09.2019 09:55, Thomas Mueller wrote: > from Kamil Rytarowski and my previous post: > >>>> I have managed to get light cross-toolchain producing Linux binaries. > >>>> The only dependency is musl (+gmake to build it). > >>> Is it necessary to use musl, as opposed to uClibc-ng or glibc? > > >> MUSL has good license (BSD) and is designed to work well standalone. > >> It would be also possible to add MUSL to src/ directly, but it will >> involve patching tools/. > >> However if we want to use LTP, it is already GPLv2 and some work to >> integrate into ATF, probably it would involve rewritting the tests. > > What is ATF here? But my main interest is building a cross-toolchain on NetBSD to produce Linux binaries. > > I can't see what I would use LTP for; I looked at their Github site. > My primary motivation is running LTP kernel regression tests for compat_linux and integrate them into ATF (src/tests). With musl it is posible to get cross-toolchain for the same CPU configuration as host without building customized gcc/clang. >>> Did you cross-compile from NetBSD to get the cross-toolchain, or did you need some Linux stuff already compiled? > > >> I compiled everything natively on NetBSD, from NetBSD. No Linux stuff >> precompiled. > > Did you not need Linux compat at this stage? > No. It was needed only to test hello-world example. Such musl-gcc approach to build non-trivial applications will most likely fail as we will still be detected as NetBSD and this will affect the end result. For building applications with dependencies we will need to do it at least in chroot. However.. getting this setup to build larger packages with plain musl-gcc is viable. It's a matter of cost vs benefit here. > How does the compiler at NetBSD end know what OS to compile for? Is it a matter of the appropriate tuple or triplet? > ELF is similar on NetBSD and Linux, the are few differences that are handled with musl-gcc GCC script. However it would involve some work to build non-trivial applications. >>> But I believe you would need Linux kernel headers in any case. > > >> This might be the case that the Linux kernel headers needed that are >> GPLv2. If so, it will be easier and quicker to get >> MUSL+LTP+GMAKE+LINUX_HEADERS|(+BASH+....) as a package in pkgsrc. > > I found musl, uclibc and glibc in pkgsrc/wip . One is not likely to get far building packages with pkgsrc, or FreeBSD with ports, without gmake and bash. > > Linux headers would not have to be built, but it would be necessary to configure and build the Linux kernel. > Building the Linux kernel with musl-gcc can be more tricky as there are certainly hacks assuming uname=Linux. However... it should be doable. > Perhaps, musl could be downloaded from their website and compiled. > I was wondering whether there would be a use-case for integration of MUSL into src/? >> Implementing everything as a part of src/ is possible, but needs more >> work and more GPL code around. > >>> Where do you get musl-gcc, or is it built as part of the light cross-toolchain? > It is part of the musl git repo. https://git.musl-libc.org/cgit/musl/ There is need to build musl-gcc.specs.sh and musl-gcc https://git.musl-libc.org/cgit/musl/tree/Makefile I had to run "gmake musl-gcc" "gmake musl-gcc.specs" or similar. I would need to reproduce it or package to recall the exact commands. I had to install musl into /usr/local + the ELF leader link into /lib/ld-musl*. > >> It is shipped together with mainline MUSL, but there is probably need to >> build it manually (I had to do it this way: specify few more 'gmake >> $target' calls). > >>>> It works almost out of the box (I had to manually build certain files). > >>>> The only think that is required to be tuned is to add a dummy gnu_debuglink. > > > Tom >
Attachment:
signature.asc
Description: OpenPGP digital signature