wkz
how to crosscompile
Hi,
have anyone tried to crosscompile it?
tried this way from the kernel-dir of this repo:
KDIR=/media/data_ext/git/kernel/BPI-Router-Linux ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make all
after building my kernel to have necessary files there, then i have the kernel-module,
but how to proceed with autoconf and the configure-script?
regards Frank
It's been part of Buildroot for a while now, so yes:
https://lists.buildroot.org/pipermail/buildroot/2022-October/716305.html
i already use buildroot as standalone initrd with own kernel and i see that the package depends on BR2_LINUX_KERNEL...this looks tricky as i cannot set a kernel dir, it looks like i can only select version and patches and needs defconfig where it seems i cannot use the arch/arm64/configs/defconfig as it requires to be set and appends _defconfig
with empty defconfig linux/linux.mk:668: *** No kernel defconfig name specified, check your BR2_LINUX_KERNEL_DEFCONFIG setting.
BR2_LINUX_KERNEL_DEFCONFIG="defconfig" Can't find default configuration "arch/arm64/configs/defconfig_defconfig
how is crosscompile done in buildroot, do not see it in the patch (prev message to link above)
i try to compile in an arm64 chroot in parallel, if this is not working too i'm out of ideas
Try building a plain Buildroot without your kernel or whatnot first. The configure script follows the standard autotools build, nothing fancy.
i already have buildroot separately from kernel but the mdio-tools buildroot package requires BR2_LINUX_KERNEL set...and here a defconfig needs to be set :(
i already use buildroot as standalone initrd with own kernel and i see that the package depends on BR2_LINUX_KERNEL...this looks tricky as i cannot set a kernel dir, it looks like i can only select version and patches and needs defconfig where it seems i cannot use the arch/arm64/configs/defconfig as it requires to be set and appends _defconfig
Buildroot supports fetching the kernel from a custom GIT tree, which might suit you. Also, for development purposes, look into local.mk and setting LINUX_OVERRIDE_SRCDIR to build from a local tree. Supplying the defconfig from a custom file is also supported (BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG). If you go this route, you should be able to just select the package and have Buildroot take care of everything for you. I would highly recommend this, especially if you do not have lots of experience with things like this.
how is crosscompile done in buildroot, do not see it in the patch (prev message to link above)
If you want to build the userspace part outside of Buildroot, the steps should be:
./configure --host=aarch64-linux-gnu && make
If you are doing this from a GIT clone and not from an extracted release tarball, you first have to create the configure script with:
./autogen.sh
second way looks more matching to my needs as i have a more complex buildchain for kernel to build a fit image with devicetree overlays...cloning and building kernel to only build the kernel-module sounds a bit strange...and i already figured out how to build the module itself with passing the KDIR. so i only need to build the userspace binary
seems i got it
apt install autoconf pkg-config libmnl-dev # in ubuntu 24.4 build machine and also in arm64 chroot
and needed to run the autogen.sh afterwards, else some strange pkg-config errors appear
in chroot
LDFLAGS=-static ./configure --prefix=$(pwd)/install/usr
and seems to work
/usr/src/mdio-tools# file src/mdio/mdio src/mdio/mdio: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=60d14bfaae9c5c7fbfc148040e57963dea6576c6, for GNU/Linux 3.7.0, with debug_info, not stripped
on x86 build-machine:
LDFLAGS=-static ./configure --host=aarch64-linux-gnu --prefix=$(pwd)/install/usr && make
here i got
/usr/lib/gcc-cross/aarch64-linux-gnu/13/../../../../aarch64-linux-gnu/bin/ld: -lmnl kann nicht gefunden werden: Datei oder Verzeichnis nicht gefunden
(file not found - LANG=C does not prevent translating it)
also tried this:
apt install libmnl0:arm64
any hint here?
second way looks more matching to my needs as i have a more complex buildchain for kernel to build a fit image with devicetree overlays
If you want to stick with your custom setup, by all means to that. Just let me assure you that the argument you lay out here is not a good reason to do so. Buildroot is very flexible in letting you run your own hooks at various points in the build process, e.g., running mkimage or whatever you need.
cloning and building kernel to only build the kernel-module sounds a bit strange...and i already figured out how to build the module itself with passing the KDIR. so i only need to build the userspace binary
What I was trying to suggest was that you consolidate your entire kernel+initrd build to be managed by Buildroot. That way once you get everything working, you also have a chance of being able to reproduce your work.
I have also used setups like the one you describe. Bluntly: you are building on quicksand. As the number of dependencies grow, this will be very hard to maintain. I am sure that if you keep at this, you will get it working - no doubt. But can you easily get there again? Is it possible for a friend or colleague to reuse your work?
Again: whatever floats your boat. This is just some advise from someone who has been down that road.
any hint here?
Since configure runs fine, I guess it manages to locate the .pc-file for libmnl, but then ld does not find it in any of its search paths. Have a look at mnl_LIBS in your generated Makefile and see if the included path matches where you have installed libmnl.
thanks for trying to help.
i'm linux kernel developer since 7 years and everytime building buildroot when i want to try new kernel version is very much time...mostly i test kernel,build new,test again with tftp boot in a few minutes.
mostly i use debian and use buildroot only when mmc support not yet working, i have kernel-crashes or testing things that potentially causing them :)
so i did simple tests
$ ls -l /usr/lib/aarch64-linux-gnu/*libmnl*
lrwxrwxrwx 1 root root 15 Apr 8 2024 /usr/lib/aarch64-linux-gnu/libmnl.so.0 -> libmnl.so.0.2.0
-rw-r--r-- 1 root root 67512 Apr 8 2024 /usr/lib/aarch64-linux-gnu/libmnl.so.0.2.0
$ ARCH=arm64 pkg-config --cflags --libs libmnl
-lmnl
Makefile related to mnl:
mnl_CFLAGS =
mnl_LIBS = -lmnl
it looks that the right linker is called (but not defined in the makefile, only CC), and it looks like the mnl_LIBS is interpreted as a filename not a LDFLAG. it seems to be used for
src/mdio/Makefile:267:mdio_LDADD = $(mnl_LIBS)
and then used here:
mdio$(EXEEXT): $(mdio_OBJECTS) $(mdio_DEPENDENCIES) $(EXTRA_mdio_DEPENDENCIES) @rm -f mdio$(EXEEXT) $(AM_V_CCLD)$(mdio_LINK) $(mdio_OBJECTS) $(mdio_LDADD) $(LIBS)
not digged further how AM_V_CCLD is defined
nevertheless i was able to compile via arm64 chroot and binary works so far...had expected that there was an easier way to crosscompile
i'm linux kernel developer since 7 years and everytime building buildroot when i want to try new kernel version is very much time...mostly i test kernel,build new,test again with tftp boot in a few minutes.
You have a setup that works for you, great!
🤐
had expected that there was an easier way to crosscompile
Sorry to disappoint. autotools is pretty much the standard way of distributing C-based system software, so is using pkg-config to locate dependencies. Given that, I feel pretty confident in saying that this is likely a more generic issue with your build environment, rather than something mdio-tools-specific.
Among other things, Buildroot sets PKG_CONFIG_PATH to match the cross compile environment (sysroot or staging) which you need to set to not get the system path (built-in default) and other parameters from pkg-config when cross compiling.
The mdio-tools project is cross compiled in other settings too (think I even saw a Yocto layer?) not just Buildroot so it's likely your setup @frank-w that is at issue here. Sorry.