ARM Build Fail

[streamingdata]

Hoping you may be able to provide some insight, trying to compile with buildroot and getting this error. Any ideas? Thank you in advance
applets/usage.c: In function 'main':
applets/usage.c:52:8: warning: ignoring return value of 'write', declared with attribute warn_unused_result [-Wunused-result]
write(STDOUT_FILENO, usage_array[i].usage, strlen(usage_array[i].usage) + 1);
^
GEN include/usage_compressed.h
HOSTCC applets/applet_tables
applets/applet_tables.c: In function 'main':
applets/applet_tables.c:161:9: warning: ignoring return value of 'fgets', declared with attribute warn_unused_result [-Wunused-result]
fgets(line_old, sizeof(line_old), fp);
^
GEN include/applet_tables.h
CC applets/applets.o
LD applets/built-in.o
/root/armbuild/busybotnet/buildroot-2018.02.1/output/host/lib/gcc/arm-buildroot-linux-uclibcgnueabi/6.4.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: cannot find -ldl
/root/armbuild/busybotnet/buildroot-2018.02.1/output/host/lib/gcc/arm-buildroot-linux-uclibcgnueabi/6.4.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: cannot find -ldl
collect2: error: ld returned 1 exit status
make[1]: *** [applets/built-in.o] Error 1

[kernelzeroday]

You are missing -ldl in your library path, give it a shot without uclibc and a regular arm glibc toolchain, or perhaps musl. Uclibc was depricated a while back and has some odd glitches, though I have managed to build with uclibc in the past. It looks like it's failing on the regular BusyBox build, try building upstream BusyBox and you will likely get the same error.

…

On Mon, Apr 16, 2018, 8:17 PM streamingdata ***@***.***> wrote: Hoping you may be able to provide some insight, trying to compile with buildroot and getting this error. Any ideas? Thank you in advance applets/usage.c: In function 'main': applets/usage.c:52:8: warning: ignoring return value of 'write', declared with attribute warn_unused_result [-Wunused-result] write(STDOUT_FILENO, usage_array[i].usage, strlen(usage_array[i].usage) + 1); ^ GEN include/usage_compressed.h HOSTCC applets/applet_tables applets/applet_tables.c: In function 'main': applets/applet_tables.c:161:9: warning: ignoring return value of 'fgets', declared with attribute warn_unused_result [-Wunused-result] fgets(line_old, sizeof(line_old), fp); ^ GEN include/applet_tables.h CC applets/applets.o LD applets/built-in.o /root/armbuild/busybotnet/buildroot-2018.02.1/output/host/lib/gcc/arm-buildroot-linux-uclibcgnueabi/6.4.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: cannot find -ldl /root/armbuild/busybotnet/buildroot-2018.02.1/output/host/lib/gcc/arm-buildroot-linux-uclibcgnueabi/6.4.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: cannot find -ldl collect2: error: ld returned 1 exit status make[1]: *** [applets/built-in.o] Error 1 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKzyDwOaOnhwdJvfWHOPDW1w0Us-AdGAks5tpV60gaJpZM4TXkja> .

[streamingdata]

Hi @kernelzeroday,
I'm having issues building with qemu, I got the complete system setup and was compiling but my ssh connection closed and now I lost the last 9 hours of installation. Their wouldn't be any chance you had a staticly compiled arm9 binary lying around I could borrow? I'd give it back! ^-^ streamingdata@protonmail.com

[kernelzeroday]

Arm should be backwards compatible, I believe there is a precompiled arm binary in the repo somewhere, if not I can run a compilation and upload. Best wishes, let me know if you have any trouble with the binaries in the repo

…

On Wed, Apr 18, 2018, 1:44 AM streamingdata ***@***.***> wrote: Hi @kernelzeroday <https://github.com/kernelzeroday>, I'm having issues building with qemu, I got the complete system setup and was compiling but my ssh connection closed and now I lost the last 9 hours of installation. Their wouldn't be any chance you had a staticly compiled arm9 binary lying around I could borrow? I'd give it back! ^-^ ***@***.*** — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKzyD7qNABbt_0VRti4jxYVpepZytbGnks5tpvzfgaJpZM4TXkja> .

[kernelzeroday]

I tested out the copy in the binaries directory, it should be a current build with all the bells and whistles included. It is built for kernel 3.2.0 however, so if you have an older kernel you will need to build a new copy of glibc using --with-kernel configured to support your correct kernel version, and convince your toolchain to link that version of glibc when building. Additionally I fixed up the copy of libpcap in the repo, it was missing some files for some reason. If you want libssh support, the version in the repo is also configured for static linking properly aswell.

Cheers

[streamingdata]

Hi mate, I've setup qemu and am trying to compile from here. The binary gives a segmentation fault, the platform I'm building for is running on kernel 2.6.24. Currently my qemus kernel is different, I haven't done so much C Dev before only python I was under the assumption that if I stupidly *staticly compiled it would be alright. If you could compile a static binary that would work on 2.6.24 and ARM926EJ-S I would gladly pay you some btc or PayPal you some $. Thanks so much for your help bro I'm dying to get this running, praise Kek! Sent from ProtonMail mobile

…

-------- Original Message --------

On 18 Apr 2018, 23:00, kernelzeroday wrote: I tested out the copy in the binaries directory, it should be a current build with all the bells and whistles included. It is built for kernel 3.2.0 however, so if you have an older kernel you will need to build a new copy of glibc using --with-kernel configured to support your correct kernel version, and convince your toolchain to link that version of glibc when building. Additionally I fixed up the copy of libpcap in the repo, it was missing some files for some reason. If you want libssh support, the version in the repo is also configured for static linking properly aswell. Cheers — You are receiving this because you modified the open/close state. Reply to this email directly, [view it on GitHub](#9 (comment)), or [mute the thread](https://github.com/notifications/unsubscribe-auth/AkkLFb_LV2aBeI75fw1GTFJ_Qjpx06HHks5tpxzfgaJpZM4TXkja).

[kernelzeroday]

I'll take a look later today, I should be able to assist here. I've compiled for older kernels before with success, and I am pretty confident that armv9 is compatible with EABI5. I'll let you know. It would be a great help if you can post the results of the file command run against a native binary on your target system. It should look something like this:

busybotnet/binaries/busybox_arm5: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=30efdf822d2f37e4ceff60503743fe23b616da81, stripped

That will give us a bit more information, as LSB and MSB require different toolchains.

Thanks for the offer of support, donations are always gladly accepted :)

Cheers!

[streamingdata]

Thanks dude it would be a great help!
I've uploaded the original busybox that runs on the system here: https://nofile.io/f/5tBPa07OBGZ/oldbusybox
oldbusybox: ELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked,
stripped,
Thanks for your help! If we can get it working I'll donate you some!
Are you on IRC or whats the best way to chat?

[streamingdata]

/proc/cpuinfo
Processor : ARM926EJ-S rev 5 (v5l)
BogoMIPS : 219.54
Features : swp half thumb fastmult edsp java
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant : 0x0
CPU part : 0x926
CPU revision : 5
Cache type : write-back
Cache clean : cp15 c7 ops
Cache lockdown : format C
Cache format : Harvard
I size : 16384
I assoc : 4
I line length : 32
I sets : 128
D size : 16384
D assoc : 4
D line length : 32
D sets : 128

contents of /lib
ld-uClibc-0.9.28.so
ld-uClibc.so.0
libc.so.0
libcrypt-0.9.28.so
libcrypt.so.0
libdl-0.9.28.so
libdl.so.0
libgcc_s.so.1
libm-0.9.28.so
libm.so.0
libpthread-0.9.28.so
libpthread.so.0
libstdc++.so
libstdc++.so.6
libstdc++.so.6.0.3
libuClibc-0.9.28.so

[streamingdata]

QEMU can create a system for this platform with -M versatileab -cpu arm926
I've uploaded a copy of the /lib folder if it is any help https://nofile.io/f/4oxJWqvATVx/libs.tar.gz

[streamingdata]

I tested an EABI5 binary on the system and it returned "Illegal instruction (core dumped)" which leads me to believe this board doesn't support EABI5, I'm not sure what our build was compiled with but I think it needs to be compiled with arm-elf-gcc? EDIT: I've tried to run another EABI5 binary and it works but just missing headers. so EABI5 will work if it's staticly linked.
eabi5bin: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 2.6.16, not stripped
@kernelzeroday Message me when you can help with this and I'll donate you some crypto :) Again thanks for all the help!

[kernelzeroday]

Hey, sorry for the late reply. I spoke with @Shellz and we are looking into this right now. My schedule is a bit tight with work and some personal obligations but don't worry, we are happy to help make this work. I'll take a look soon and update you as to what I find.

[streamingdata]

Thanks isdrupter / shellz you guys rock!
Let me know if you get it to compile and I can test the binary. Day 3 at it, I'm going to install stock ubuntu on a fresh machine, try to setup aboriginal linux in qemu and see if I can get it to compile from a chroot, I was so close to having it working yesterday, I had a binary staticly compiled but it was against a newer kernel so it didn't work :/ Cheers again guys!

[streamingdata]

So I'm trying to get linaro working with arm-eabi, It requires glibc 2.14 so I'm compiling that,
Will export LD_LIBRARY_PATH=/path/to/custom/glibc before make etc. etc. suffice?
I'm wondering if this will work without requiring glibc on the target device, learning heaps, still confused.