Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
UserXYZ opened this issue Oct 8, 2015 · 4 comments
Open

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

UserXYZ opened this issue Oct 8, 2015 · 4 comments

Comments

@UserXYZ
Copy link

UserXYZ commented Oct 8, 2015

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.

@jcmvbkbc
Copy link
Owner

jcmvbkbc commented Oct 8, 2015

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

@UserXYZ
Copy link
Author

UserXYZ commented Oct 12, 2015

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... :)

@jcmvbkbc
Copy link
Owner

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.

@UserXYZ
Copy link
Author

UserXYZ commented Oct 14, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants