qca / open-ath9k-htc-firmware

The firmware for QCA AR7010/AR9271 802.11n USB NICs
Other
426 stars 181 forks source link

Building Toolchain Error: ISO C++ forbids comparison between pointer and integer #135

Closed vindicatorr closed 6 years ago

vindicatorr commented 6 years ago

https://github.com/crosstool-ng/crosstool-ng/issues/735 For curiosity sake, I thought I might try the latest versions by editing the Makefile: GMP_VER=6.1.2 MPFR_VER=3.1.5 BINUTILS_VER=2.29 GCC_VER=7.2.0 (had to point to tar.xz and unpack with tar -xaf)

I excluded all patches and the toolchain looked to build just fine... HOWEVER building the target_firmware didn't like some literal relocations:

make[3]: Entering directory '/.../open-ath9k-htc-firmware/target_firmware/build/k2'
[ 94%] Generating fw.elf
/.../open-ath9k-htc-firmware/target_firmware/build/k2/libfirmware.a(app_start.c.obj): In function `app_start':
/.../open-ath9k-htc-firmware/target_firmware/magpie_fw_dev/target/init/app_start.c:95:(.boot+0x6): dangerous relocation: l32r: literal placed after use: (.boot.literal+0x8)
...
/.../open-ath9k-htc-firmware/target_firmware/build/k2/libfirmware.a(app_start.c.obj): In function `ioread32':
/.../open-ath9k-htc-firmware/target_firmware/magpie_fw_dev/target/inc/adf_os_io.h:58:(.boot+0x5d): dangerous relocation: l32r: literal placed after use: (.boot.literal+0x24)
/.../open-ath9k-htc-firmware/target_firmware/build/k2/libfirmware.a(app_start.c.obj): In function `app_start':
/.../open-ath9k-htc-firmware/target_firmware/magpie_fw_dev/target/init/app_start.c:138:(.boot+0x67): dangerous relocation: l32r: literal placed after use: (.boot.literal+0x28)
...
/.../open-ath9k-htc-firmware/target_firmware/magpie_fw_dev/target/init/app_start.c:296:(.boot+0x222): dangerous relocation: l32r: literal placed after use: (.boot.literal+0xd0)
collect2: error: ld returned 1 exit status
make[3]: *** [CMakeFiles/gen-firmware.dir/build.make:69: fw.elf] Error 1
chaoticryptidz commented 6 years ago
--- a/gcc/ubsan.c
+++ b/gcc/ubsan.c
@@ -1471,7 +1471,7 @@ ubsan_use_new_style_p (location_t loc)

   expanded_location xloc = expand_location (loc);
   if (xloc.file == NULL || strncmp (xloc.file, "\1", 2) == 0
-      || xloc.file == '\0' || xloc.file[0] == '\xff'
+      || xloc.file[0] == '\0' || xloc.file[0] == '\xff'
       || xloc.file[1] == '\xff')
     return false;
chaoticryptidz commented 6 years ago

@vindicatorr hope that patch helps.

ghost commented 6 years ago

how do i apply this patch . i am getting same error in debian 64 bit running normally without doing any adventures

ghost commented 6 years ago

i tried copy pasting code and rename it to .patch and do git apply < file.patch it says corrupt patch at line 10.

ghost commented 6 years ago

this is the full error :

/root/Desktop/open-ath9k-htc-firmware/toolchain/dl/gcc-6.3.0/gcc/ubsan.c: In function ‘bool ubsan_use_new_style_p(location_t)’: /root/Desktop/open-ath9k-htc-firmware/toolchain/dl/gcc-6.3.0/gcc/ubsan.c:1474:23: error: ISO C++ forbids comparison between pointer and integer [-fpermissive] || xloc.file == '\0' || xloc.file[0] == '\xff' ^~~~ Makefile:1084: recipe for target 'ubsan.o' failed make[3]: [ubsan.o] Error 1 make[3]: Leaving directory '/root/Desktop/open-ath9k-htc-firmware/toolchain/build/gcc-6.3.0/gcc' Makefile:4109: recipe for target 'all-gcc' failed make[2]: [all-gcc] Error 2 make[2]: Leaving directory '/root/Desktop/open-ath9k-htc-firmware/toolchain/build/gcc-6.3.0' Makefile:856: recipe for target 'all' failed make[1]: [all] Error 2 make[1]: Leaving directory '/root/Desktop/open-ath9k-htc-firmware/toolchain/build/gcc-6.3.0' Makefile:149: recipe for target '/root/Desktop/open-ath9k-htc-firmware/toolchain/build/gcc-6.3.0/.built' failed make: [/root/Desktop/open-ath9k-htc-firmware/toolchain/build/gcc-6.3.0/.built] Error 2

nroach44 commented 6 years ago

@DukhiAatma That is roughly how you do it, make sure you copied it correctly. If it still doesn't work make the change in the file ubsan.c yourself (i.e. add the [0] in the right place)

ghost commented 6 years ago

@nroach44 thank you kind sir, build start again. at first it looked like same code and then saw zero before equals sign.

olerem commented 6 years ago

Here is the pull request for GCC 7.2.0 https://github.com/qca/open-ath9k-htc-firmware/pull/139

vindicatorr commented 6 years ago

I'm afraid it's still erring out with the same message:

make[3]: Entering directory '/.../open-ath9k-htc-firmware/target_firmware/build/k2'
[ 94%] Generating fw.elf
/.../open-ath9k-htc-firmware/target_firmware/build/k2/libfirmware.a(app_start.c.obj): In function `app_start':
/.../open-ath9k-htc-firmware/target_firmware/magpie_fw_dev/target/init/app_start.c:95:(.boot+0x6): dangerous relocation: l32r: literal placed after use: (.boot.literal+0x8)
...
/.../open-ath9k-htc-firmware/target_firmware/magpie_fw_dev/target/init/app_start.c:296:(.boot+0x222): dangerous relocation: l32r: literal placed after use: (.boot.literal+0xd0)
collect2: error: ld returned 1 exit status
make[3]: *** [CMakeFiles/gen-firmware.dir/build.make:69: fw.elf] Error 1

Although I should add that I'm doing a build with the native toolchain on my ARM device: Name : gcc Version : 7.3.1+20180312-2 Name : gmp Version : 6.1.2-1 Name : mpfr Version : 4.0.1-1 Name : binutils Version : 2.29.1-3

Would you say the binutils/gcc patches are relevant to this issue or this specific firmware in general that the native toolchain from Arch won't be enough?

olerem commented 6 years ago

what do you mean by native toolchain? this firmware is for Xtensa CPU not ARM. GCC and Binutils should be patched to be able to build any thing usable for it.

vindicatorr commented 6 years ago

Ahhhh yea! Just built and compiled using mainline sooo:

$ ./toolchain/inst/bin/xtensa-elf-gcc --version
xtensa-elf-gcc (GCC) 8.0.1 20180424 (experimental)

I will say that the master mpc failed check for tmul so I just skipped it. The rest of the built went fine. About to test it...

vindicatorr commented 6 years ago

I think this issue can be closed since I've been able to build it now. On a different note which I submitted to the kernel ML last year, the problem I had then still exists with the patch applied, but it's worse since the kernel no longer knows about the quiet failure (replying to that thread now).