crosstool-NG icon indicating copy to clipboard operation
crosstool-NG copied to clipboard

Timeouts for download, isl-0.12.2 not where it's looked for

Open UserXYZ opened this issue 8 years ago • 4 comments

isl-0.12.2 that needs to be downloaded is not at the given urls, and so configure/download/build script fails numerous times to download it. ftp.linux.student.kuleuven.be is offline, only working copy is http://mirrors.kernel.org/sources.redhat.com/gcc/infrastructure/isl-0.12.2.tar.bz2

Can you fix the sources to ensure availability of all files and avoid timeouts?

Thanks.

UserXYZ avatar Oct 08 '15 13:10 UserXYZ

There's a branch lx106-g++-1.21.0 in this repository, based on newer version of the crosstool-NG. Can you try it?

jcmvbkbc avatar Oct 08 '15 14:10 jcmvbkbc

Hi Max, I've tried it, and it's not being able to compile firmware for esp8266, unlike the previous version.

Here are all the results:

  • still having trouble downloading certain packages, a lot of retries due to "file not found", I think mostly for gcc
  • I've put the copy of the new crosstools-NG-1.21 in esp-open-sdk, replacing the version there, and let the whole package build - it went without the problems
  • when I tried to compile the firmware, it fails almost instantly:

make[1]: Entering directory '/opt/nodemcu/nodemcu-firmware-dev/app' make[2]: Entering directory '/opt/nodemcu/nodemcu-firmware-dev/app/user' DEPEND: xtensa-lx106-elf-gcc -M -Os -Os -ffunction-sections -fno-jump-tables -fdata-sections -g -Wpointer-arith -Wundef -Werror -Wl,-EL -fno-inline-functions -nostdlib -mlongcalls -mtext-section-literals -D__ets__ -DICACHE_FLASH -DLWIP_OPEN_SRC -DPBUF_RSV_FOR_WLAN -DEBUF_LWIP -I include -I ./ -I ../../include/ets -I ../libc -I ../platform -I ../lua -I ../wofs -I ../spiffs -I ../include -I ./ -I ../../include -I ../../include/eagle user_exceptions.c DEPEND: xtensa-lx106-elf-gcc -M -Os -Os -ffunction-sections -fno-jump-tables -fdata-sections -g -Wpointer-arith -Wundef -Werror -Wl,-EL -fno-inline-functions -nostdlib -mlongcalls -mtext-section-literals -D__ets__ -DICACHE_FLASH -DLWIP_OPEN_SRC -DPBUF_RSV_FOR_WLAN -DEBUF_LWIP -I include -I ./ -I ../../include/ets -I ../libc -I ../platform -I ../lua -I ../wofs -I ../spiffs -I ../include -I ./ -I ../../include -I ../../include/eagle user_main.c xtensa-lx106-elf-gcc -Os -Os -ffunction-sections -fno-jump-tables -fdata-sections -g -Wpointer-arith -Wundef -Werror -Wl,-EL -fno-inline-functions -nostdlib -mlongcalls -mtext-section-literals -D__ets__ -DICACHE_FLASH -DLWIP_OPEN_SRC -DPBUF_RSV_FOR_WLAN -DEBUF_LWIP -I include -I ./ -I ../../include/ets -I ../libc -I ../platform -I ../lua -I ../wofs -I ../spiffs -I ../include -I ./ -I ../../include -I ../../include/eagle -o .output/eagle/debug/obj/user_main.o -c user_main.c In file included from user_main.c:14:0: ../libc/c_stdlib.h:16:0: error: "INT_MAX" redefined [-Werror] #define INT_MAX 2147483647 ^ : note: this is the location of the previous definition user_main.c: In function 'user_start_trampoline': user_main.c:41:4: error: implicit declaration of function '__real__xtos_set_exception_handler' [-Werror=implicit-function-declaration] __real__xtos_set_exception_handler ( ^ user_main.c:49:3: error: implicit declaration of function 'call_user_start' [-Werror=implicit-function-declaration] call_user_start (); ^ In file included from ../libc/c_stdlib.h:11:0, from user_main.c:14: user_main.c: In function 'task_init': ../../include/mem.h:8:21: error: implicit declaration of function 'pvPortMalloc' [-Werror=implicit-function-declaration] #define os_malloc pvPortMalloc ^ user_main.c:67:31: note: in expansion of macro 'os_malloc' taskQueue = (os_event_t )os_malloc(sizeof(os_event_t) * TASK_QUEUE_LEN); ^ In file included from user_main.c:17:0: user_main.c: In function 'nodemcu_init': ../platform/flash_fs.h:69:19: error: implicit declaration of function 'myspiffs_format' [-Werror=implicit-function-declaration] #define fs_format myspiffs_format ^ user_main.c:96:14: note: in expansion of macro 'fs_format' if( !fs_format() ) ^ cc1: all warnings being treated as errors ../../Makefile:197: recipe for target '.output/eagle/debug/obj/user_main.o' failed make[2]: ** [.output/eagle/debug/obj/user_main.o] Error 1 make[2]: Leaving directory '/opt/nodemcu/nodemcu-firmware-dev/app/user' ../Makefile:183: recipe for target '.subdirs' failed make[1]: *** [.subdirs] Error 2 make[1]: Leaving directory '/opt/nodemcu/nodemcu-firmware-dev/app' Makefile:183: recipe for target '.subdirs' failed make: *** [.subdirs] Error 2

  • when I return to the original esp-open-sdk with the old crosstools-NG, it works without a hitch

I see you've put gcc-5.1.1...isn't it too fresh for this? I think no Linux distro is using it yet (except maybe the latest dev versions), and I suppose that's the reason the firmware compilation fails with such errors. Guess esp-open-sdk or crosstools-NG-1.21 should be updated with some ifdefines and maybe .h files, but then again, I'm not expert on that... :)

UserXYZ avatar Oct 12 '15 11:10 UserXYZ

still having trouble downloading certain packages, a lot of retries due to "file not found", I think mostly for gcc

Ok, that's latest mainline crosstool-NG release, I'm not really into fixing download locations unless all of them fail breaking the build. Feel free to propose a fix to scripts or configuration.

Regarding build errors, adding -std=gnu90 to CFLAGS/CXXFLAGS should fix them, at least calls to implicitly defined functions.

I see you've put gcc-5.1.1...isn't it too fresh for this? ... I suppose that's the reason the firmware compilation fails with such errors.

I think it's just fine. Maybe 5.2 is better. The reason for failing is the newer default language standard, I guess it won't be downgraded in the future.

jcmvbkbc avatar Oct 13 '15 18:10 jcmvbkbc

Well, I just thought that you should put in the first place the default (original software based) location and then parse http errors for "not found" or similar before switching to the next url (if you already aren't doing that). I know locations can change in time due to packages getting obsoleted by newer versions, but it's hard to see what's going on unless you look at build.log - screen session does not output anything about download problems, and I think it should so you'd know which package at which location is failing.

Regarding the new gcc...if adding what you propose to CFLAGS/CXXFLAGS fixes things, how about adding them in configure/Makefile so they determine automatically what version of gcc someone has installed, and add appropriate flags Or at least, having something written in README about that (even better would be INSTALL because everyone should read that anyhow) so people wouldknow if they get error X they should add flag Y manually to Makefile....something along that line...

Cheers.

UserXYZ avatar Oct 14 '15 08:10 UserXYZ