Has anyone had success building from source on AArch64? I'm running Debian 12 in UTM on M1 Mac - haven't had issues building stable or snapshot from several months ago, but am now running into issues on the latest builds.
Maybe you are in wrong thread.
OK, so I'm moving along using @_FailSafe's build environment. Just to start with, I've done exactly as those instructions say with no modifications, to establish a baseline.
I'm getting an error:
**make[1]: *** [package/Makefile:173: /home/user/openwrt/staging_dir/target-aarch64_cortex-a53_musl/stamp/.package_compile] Error** 2
**make: *** [/home/user/openwrt/include/toplevel.mk:248: world] Error** 2
I have a buildlog, but it's 31Mb. Here it is.
I did read the docs on space constraints but I don't think that's the issue here:
$ df -h
Filesystem Size Used Avail Use% Mounted on
overlay 915G 327G 542G 38% /
tmpfs 64M 0 64M 0% /dev
shm 64M 0 64M 0% /dev/shm
/dev/nvme0n1p2 915G 327G 542G 38% /home/user
tmpfs 16G 0 16G 0% /proc/asound
tmpfs 16G 0 16G 0% /proc/acpi
tmpfs 16G 0 16G 0% /proc/scsi
tmpfs 16G 0 16G 0% /sys/firmware
tmpfs 16G 0 16G 0% /sys/devices/virtual/powercap
What can I do or provide to help resolve this?
SOLVED: this was resolved here.
I had similar issue, MT6000 custom build with LuCi and some optimization - kernel 6.6.x - #902 by di_Niko and excluding bridger & qosify fixed it
1 Like
Yup, excluding bridger and qosifysolves it. Anyone working on solving the issue, however?
1 Like
Question, did you check your .config? I found that the CONFIG_BPF_TOOLCHAIN_HOST_PATH line in mine, which is supposed to be generated automatically by /tmp/setup_pesa1234_repo.sh, was malformed. When I corrected it, bridger and qosify seem to compile correctly.
At least on my system, editing .config and setting CONFIG_BPF_TOOLCHAIN_HOST_PATH=/usr/lib/llvm-18 makes everything compile correctly.
2 Likes
@jeff47 and @di_Niko: This was indeed a bug with the container image--I apologize. It should be fixed now. Details here:
4 Likes
Great, looks good! Glad I was able to help track this down. Thanks for your responsiveness.
Now I've got an image made from the builder, I just need the courage to flash it. 
With my luck I somehow left out the ethernet and Wifi drivers...
1 Like
Just remember, the MT6000 is extremely forgiving given its awesome OEM bootloader I'm sure you'll be good, though!
If you want an extra vote of confidence, you can always diff your .config against Pesa's to make sure you got the essentials in place. But as long as you selected the right target when you first started setting up your image in menuconfig, you should be set!
I'm currently on 23.05.5. I need to flash
/bin/targets/mediatek/filogic/openwrt-mediatek-filogic-glinet_gl-mt6000-squashfs-sysupgrade.bin, right? And all the ipk packages are contained within that?
You can run make defconfig to make sure you have all essential drivers etc in your .config.
You only need to flash the .bin file.
1 Like
Is that true even for items compiled as modules? I'm confused because of the following statement from https://openwrt.org/docs/guide-developer/toolchain/use-buildsystem:
For most packages and features, you have three options: y, m, n which are represented as follows:
pressing y sets the <*> built-in label
This package will be compiled and included in the firmware image file.
pressing m sets the <M> package label
This package will be compiled, but **not included in the firmware image file**, e.g. to be installed with opkg after flashing the firmware image file to the device.
(emphasis added)
does anyone know if enabling ibf on the 2.4g interface has a positive impact on esp32 / esp8266 (mainly iot) devices?
Hmm - shouldn't matter...
AFAIK - there were some issues with Espressif devices/firmware with Broadcom for ESP32/ESP8266 -- There is many different flavors of firmware - device and upstream code from Espressif..
Worst case - for 2.4 - go HT mode, enable Legacy 80211b rate, and use 20MHz channels down there... for WiFi - either WPA2 or perhaps WPA2/3 - see what the devices accept.
Only if one keeps the GL-Inet uboot - sysupgrade from their platform is ok, but if one goes the full monty and replaces the bootloader with the factory build - well, that is what that is...
GL-Inet's bootloader is a development of the pepe4k uboot efforts...
1 Like
Will this custom build continue to follow master branch or upcoming 24.10 stable?
What do you prefer?
it also confused me, maybe someone can correct me, but you can exclude everything which has M, if you don't need it on the final sysupgrade build.
"m" means build it as a separate opkg package and don't bundle it in the sysupgrade image. You can later install it, but it isn't necessary. When I'm building my own images, I don't use "m" at all, because I either want something in the image now, or I can build a new image when I'm missing some software.
3 Likes
My vote goes for the master branch. 
3 Likes