Hum... I haven't tried to build for a week or so and am now getting a error from the new duktape: ice 840 % gmake Toolchain path: /home/ice/u0/leres/bin/xtensa-esp32-elf-gcc Toolchain version: crosstool-ng-1.22.0-80-g6c4433a5 Compiler version: 5.2.0 Python requirements from /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/requirements.txt are satisfied. App "ovms3" version: 3.2.008-34-gd1a0e982-dirty CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/duktape/src/duktape.o duk_js_call.c: In function 'duk__handle_call_raw': duk_js_call.c:2268:32: error: 'func' may be used uninitialized in this function [-Werror=maybe-uninitialized] cc1: some warnings being treated as errors gmake[1]: *** [/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/make/component_wrapper.mk:290: src/duktape.o] Error 1 gmake: *** [/home/ice/u0/leres/esp/esp-idf/make/project.mk:552: component-duktape-build] Error 2 I looked at the code and don't see the problem: /* XXX: native funcptr could come out of call setup. */ if (func) { rc = ((duk_hnatfunc *) func)->func(thr); // 2268 } else { duk_tval *tv_func; My guess is my toolchain is too old? I'm using 1.22.0-80-g6c4433a5. Looking here: https://github.com/espressif/crosstool-NG Should I switch to the esp-1.23.x branch? Or am I just SOL because you're all using a binary release toolchain and espressif hasn't released the source to the crosstool-NG they're using to build it? Craig
Craig, yes, that looks like a compiler bug. It doesn't show with crosstool-ng-1.22.0-98-g4638c4f, so it seems that version does include some gcc fixes. Can you build duktape with that warning disabled? Regards, Michael Am 28.12.19 um 23:11 schrieb Craig Leres:
Hum... I haven't tried to build for a week or so and am now getting a error from the new duktape:
ice 840 % gmake Toolchain path: /home/ice/u0/leres/bin/xtensa-esp32-elf-gcc Toolchain version: crosstool-ng-1.22.0-80-g6c4433a5 Compiler version: 5.2.0 Python requirements from /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/requirements.txt are satisfied.
App "ovms3" version: 3.2.008-34-gd1a0e982-dirty CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/duktape/src/duktape.o duk_js_call.c: In function 'duk__handle_call_raw': duk_js_call.c:2268:32: error: 'func' may be used uninitialized in this function [-Werror=maybe-uninitialized] cc1: some warnings being treated as errors gmake[1]: *** [/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/make/component_wrapper.mk:290: src/duktape.o] Error 1 gmake: *** [/home/ice/u0/leres/esp/esp-idf/make/project.mk:552: component-duktape-build] Error 2
I looked at the code and don't see the problem:
/* XXX: native funcptr could come out of call setup. */ if (func) { rc = ((duk_hnatfunc *) func)->func(thr); // 2268 } else { duk_tval *tv_func;
My guess is my toolchain is too old? I'm using 1.22.0-80-g6c4433a5. Looking here:
https://github.com/espressif/crosstool-NG
Should I switch to the esp-1.23.x branch? Or am I just SOL because you're all using a binary release toolchain and espressif hasn't released the source to the crosstool-NG they're using to build it?
Craig _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On 2019-12-29 05:32, Michael Balzer wrote:
yes, that looks like a compiler bug. It doesn't show with crosstool-ng-1.22.0-98-g4638c4f, so it seems that version does include some gcc fixes.
Actually I don't think it's necessarily a compiler bug. Looking more closely I see that it isn't directly assigned between when it's declared and the error line. Examining the code shows "func" is probably being updated as a side effect of this call: if (DUK_LIKELY(duk__resolve_target_fastpath_check(thr, idx_func, &func, call_flags) != 0U)) { The error goes away if func is initialized to NULL when it is declared (confusingly in components/duktape/src/duktape.c, not components/duktape/src-input/duk_js_call.c or components/duktape/src-separate/duk_js_call.c). What toolchain version are you using? I have: ice 1238 % xtensa-esp32-elf-c++ --version xtensa-esp32-elf-c++ (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 5.2.0 Which is what is specified if I following the links: https://github.com/openvehicles/esp-idf https://docs.espressif.com/projects/esp-idf/en/stable/get-started/ https://docs.espressif.com/projects/esp-idf/en/stable/get-started/linux-setu... Toolchain Setup for 64-bit Linux: https://dl.espressif.com/dl/xtensa-esp32-elf-linux64-1.22.0-80-g6c4433a-5.2.... Of course my version is built natively for FreeBSD. I'll make a pull request for this. Meanwhile I updated again and changes committed today: commit b1789e8792197826b1cec71ad0178b879cc2d709 Author: Michael Balzer <balzer@expeedo.de> Date: Wed Jan 1 19:08:03 2020 +0100 Webserver: extend /api/execute & loadcmd() by Javascript mode breaks the compile for me, see appended. I'm currently on 9de393f4. Craig ice 439 % gmake Toolchain path: /home/ice/u0/leres/bin/xtensa-esp32-elf-gcc Toolchain version: crosstool-ng-1.22.0-80-g6c4433a5 Compiler version: 5.2.0 Python requirements from /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/requirements.txt are satisfied. App "ovms3" version: 3.2.008-54-g9de393f4-dirty CXX /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms_script/src/ovms_script.o /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp: In member function 'bool DuktapeHTTPRequest::StartRequest(duk_context*)': /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:1128:10: error: 'struct mg_connect_opts' has no member named 'ssl_ca_cert' opts.ssl_ca_cert = "*"; ^ /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp: In member function 'void DuktapeHTTPRequest::MongooseCallback(mg_connection*, int, void*)': /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:1188:20: error: 'MG_SSL_ERROR' was not declared in this scope if (err == MG_SSL_ERROR) ^ gmake[1]: *** [/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/make/component_wrapper.mk:290: src/ovms_script.o] Error 1 gmake: *** [/home/ice/u0/leres/esp/esp-idf/make/project.mk:552: component-ovms_script-build] Error 2
Craig, you're right, there is a chance of "func" being used uninitialized, the function called does not set it in all cases. The duktape modules are joined into the duktape.c file, the separate sources are only kept for reference -- same as with mongoose. My toolchain is gcc version 5.2.0 (crosstool-NG crosstool-ng-1.22.0-98-g4638c4f) for the SPIRAM fix. Regarding my latest changes, you seem to build without SSL support, and I forgot some #ifdefs, will add them now. Regards, Michael Am 02.01.20 um 08:22 schrieb Craig Leres:
On 2019-12-29 05:32, Michael Balzer wrote:
yes, that looks like a compiler bug. It doesn't show with crosstool-ng-1.22.0-98-g4638c4f, so it seems that version does include some gcc fixes.
Actually I don't think it's necessarily a compiler bug. Looking more closely I see that it isn't directly assigned between when it's declared and the error line. Examining the code shows "func" is probably being updated as a side effect of this call:
if (DUK_LIKELY(duk__resolve_target_fastpath_check(thr, idx_func, &func, call_flags) != 0U)) {
The error goes away if func is initialized to NULL when it is declared (confusingly in components/duktape/src/duktape.c, not components/duktape/src-input/duk_js_call.c or components/duktape/src-separate/duk_js_call.c).
What toolchain version are you using? I have:
ice 1238 % xtensa-esp32-elf-c++ --version xtensa-esp32-elf-c++ (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 5.2.0
Which is what is specified if I following the links:
https://github.com/openvehicles/esp-idf https://docs.espressif.com/projects/esp-idf/en/stable/get-started/
https://docs.espressif.com/projects/esp-idf/en/stable/get-started/linux-setu...
Toolchain Setup
for 64-bit Linux:
https://dl.espressif.com/dl/xtensa-esp32-elf-linux64-1.22.0-80-g6c4433a-5.2....
Of course my version is built natively for FreeBSD.
I'll make a pull request for this. Meanwhile I updated again and changes committed today:
commit b1789e8792197826b1cec71ad0178b879cc2d709 Author: Michael Balzer <balzer@expeedo.de> Date: Wed Jan 1 19:08:03 2020 +0100
Webserver: extend /api/execute & loadcmd() by Javascript mode
breaks the compile for me, see appended. I'm currently on 9de393f4.
Craig
ice 439 % gmake Toolchain path: /home/ice/u0/leres/bin/xtensa-esp32-elf-gcc Toolchain version: crosstool-ng-1.22.0-80-g6c4433a5 Compiler version: 5.2.0 Python requirements from /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/requirements.txt are satisfied.
App "ovms3" version: 3.2.008-54-g9de393f4-dirty CXX /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms_script/src/ovms_script.o /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp: In member function 'bool DuktapeHTTPRequest::StartRequest(duk_context*)': /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:1128:10: error: 'struct mg_connect_opts' has no member named 'ssl_ca_cert' opts.ssl_ca_cert = "*"; ^ /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp: In member function 'void DuktapeHTTPRequest::MongooseCallback(mg_connection*, int, void*)': /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:1188:20: error: 'MG_SSL_ERROR' was not declared in this scope if (err == MG_SSL_ERROR) ^ gmake[1]: *** [/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/make/component_wrapper.mk:290: src/ovms_script.o] Error 1 gmake: *** [/home/ice/u0/leres/esp/esp-idf/make/project.mk:552: component-ovms_script-build] Error 2
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Craig, I've added handling for the cases of missing SSL or Duktape support, please test. Regards, Michael Am 02.01.20 um 09:29 schrieb Michael Balzer:
Craig,
you're right, there is a chance of "func" being used uninitialized, the function called does not set it in all cases.
The duktape modules are joined into the duktape.c file, the separate sources are only kept for reference -- same as with mongoose.
My toolchain is gcc version 5.2.0 (crosstool-NG crosstool-ng-1.22.0-98-g4638c4f) for the SPIRAM fix.
Regarding my latest changes, you seem to build without SSL support, and I forgot some #ifdefs, will add them now.
Regards, Michael
Am 02.01.20 um 08:22 schrieb Craig Leres:
On 2019-12-29 05:32, Michael Balzer wrote:
yes, that looks like a compiler bug. It doesn't show with crosstool-ng-1.22.0-98-g4638c4f, so it seems that version does include some gcc fixes. Actually I don't think it's necessarily a compiler bug. Looking more closely I see that it isn't directly assigned between when it's declared and the error line. Examining the code shows "func" is probably being updated as a side effect of this call:
if (DUK_LIKELY(duk__resolve_target_fastpath_check(thr, idx_func, &func, call_flags) != 0U)) {
The error goes away if func is initialized to NULL when it is declared (confusingly in components/duktape/src/duktape.c, not components/duktape/src-input/duk_js_call.c or components/duktape/src-separate/duk_js_call.c).
What toolchain version are you using? I have:
ice 1238 % xtensa-esp32-elf-c++ --version xtensa-esp32-elf-c++ (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 5.2.0
Which is what is specified if I following the links:
https://github.com/openvehicles/esp-idf https://docs.espressif.com/projects/esp-idf/en/stable/get-started/
https://docs.espressif.com/projects/esp-idf/en/stable/get-started/linux-setu...
Toolchain Setup
for 64-bit Linux:
https://dl.espressif.com/dl/xtensa-esp32-elf-linux64-1.22.0-80-g6c4433a-5.2....
Of course my version is built natively for FreeBSD.
I'll make a pull request for this. Meanwhile I updated again and changes committed today:
commit b1789e8792197826b1cec71ad0178b879cc2d709 Author: Michael Balzer <balzer@expeedo.de> Date: Wed Jan 1 19:08:03 2020 +0100
Webserver: extend /api/execute & loadcmd() by Javascript mode
breaks the compile for me, see appended. I'm currently on 9de393f4.
Craig
ice 439 % gmake Toolchain path: /home/ice/u0/leres/bin/xtensa-esp32-elf-gcc Toolchain version: crosstool-ng-1.22.0-80-g6c4433a5 Compiler version: 5.2.0 Python requirements from /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/requirements.txt are satisfied.
App "ovms3" version: 3.2.008-54-g9de393f4-dirty CXX /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms_script/src/ovms_script.o /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp: In member function 'bool DuktapeHTTPRequest::StartRequest(duk_context*)': /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:1128:10: error: 'struct mg_connect_opts' has no member named 'ssl_ca_cert' opts.ssl_ca_cert = "*"; ^ /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp: In member function 'void DuktapeHTTPRequest::MongooseCallback(mg_connection*, int, void*)': /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:1188:20: error: 'MG_SSL_ERROR' was not declared in this scope if (err == MG_SSL_ERROR) ^ gmake[1]: *** [/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/make/component_wrapper.mk:290: src/ovms_script.o] Error 1 gmake: *** [/home/ice/u0/leres/esp/esp-idf/make/project.mk:552: component-ovms_script-build] Error 2
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On 2020-01-02 00:29, Michael Balzer wrote:
Regarding my latest changes, you seem to build without SSL support, and I forgot some #ifdefs, will add them now.
I didn't do anything to intentionally disable SSL... And I even did a "make clean" before building which I thought was a way to pick up new sdkconfig options. But when I diff sdkconfig with support/sdkconfig.default.hw31 I see a lot is missing including CONFIG_MG_ENABLE_SSL=y Ah, I found something. At the start of a clean build (rm -rf build && gmake -j8): ice 509 % gmake -j8 gmake: gcc: Command not found expr: syntax error GENCONFIG # # configuration written to /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/sdkconfig This seems familiar but I can't figure out where "gcc" is hardcoded. Even when I use "gmake -j8 CC=gcc9" I don't get a dialog to add missing things to my sdkconfig. It looks like even "gmake defconfig" is a noop. At this point I think I need a little more help. On 2020-01-02 01:52, Michael Balzer wrote:
I've added handling for the cases of missing SSL or Duktape support, please test.
72ae790 only fixed one of the two errors, see appended. Craig ice 1251 % gmake Toolchain path: /home/ice/u0/leres/bin/xtensa-esp32-elf-gcc Toolchain version: crosstool-ng-1.22.0-80-g6c4433a5 Compiler version: 5.2.0 Python requirements from /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/requirements.txt are satisfied. App "ovms3" version: 3.2.008-59-g051be7e4-dirty CXX /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms_script/src/ovms_script.o /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp: In member function 'void DuktapeHTTPRequest::MongooseCallback(mg_connection*, int, void*)': /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:1212:20: error: 'MG_SSL_ERROR' was not declared in this scope if (err == MG_SSL_ERROR) ^ gmake[1]: *** [/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/make/component_wrapper.mk:290: src/ovms_script.o] Error 1 gmake: *** [/home/ice/u0/leres/esp/esp-idf/make/project.mk:552: component-ovms_script-build] Error 2
Craig, sorry, missed that one, my new commit should do it. You don't get a missing config dialog when we update the default sdkconfigs, only when a Kconfig is extended. Our default sdkconfigs have no special meaning to the build system. To know about changes to the existing sdkconfig entries, you need to follow the discussions here or check the diff to your sdkconfig once in a while. The SSL change was introduced by & for the pushover component and became default. I haven't seen that make error up to now. "make -n" will only print the commands, maybe that helps locating that. Regards, Michael Am 02.01.20 um 20:13 schrieb Craig Leres:
On 2020-01-02 00:29, Michael Balzer wrote:
Regarding my latest changes, you seem to build without SSL support, and I forgot some #ifdefs, will add them now.
I didn't do anything to intentionally disable SSL... And I even did a "make clean" before building which I thought was a way to pick up new sdkconfig options. But when I diff sdkconfig with support/sdkconfig.default.hw31 I see a lot is missing including CONFIG_MG_ENABLE_SSL=y
Ah, I found something. At the start of a clean build (rm -rf build && gmake -j8):
ice 509 % gmake -j8 gmake: gcc: Command not found expr: syntax error GENCONFIG # # configuration written to /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/sdkconfig
This seems familiar but I can't figure out where "gcc" is hardcoded. Even when I use "gmake -j8 CC=gcc9" I don't get a dialog to add missing things to my sdkconfig. It looks like even "gmake defconfig" is a noop.
At this point I think I need a little more help.
On 2020-01-02 01:52, Michael Balzer wrote:
I've added handling for the cases of missing SSL or Duktape support, please test.
72ae790 only fixed one of the two errors, see appended.
Craig
ice 1251 % gmake Toolchain path: /home/ice/u0/leres/bin/xtensa-esp32-elf-gcc Toolchain version: crosstool-ng-1.22.0-80-g6c4433a5 Compiler version: 5.2.0 Python requirements from /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/requirements.txt are satisfied.
App "ovms3" version: 3.2.008-59-g051be7e4-dirty CXX /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms_script/src/ovms_script.o /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp: In member function 'void DuktapeHTTPRequest::MongooseCallback(mg_connection*, int, void*)': /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:1212:20: error: 'MG_SSL_ERROR' was not declared in this scope if (err == MG_SSL_ERROR) ^ gmake[1]: *** [/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/make/component_wrapper.mk:290: src/ovms_script.o] Error 1 gmake: *** [/home/ice/u0/leres/esp/esp-idf/make/project.mk:552: component-ovms_script-build] Error 2
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On 2020-01-02 11:13, Craig Leres wrote:
Ah, I found something. At the start of a clean build (rm -rf build && gmake -j8):
ice 509 % gmake -j8 gmake: gcc: Command not found expr: syntax error GENCONFIG # # configuration written to /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/sdkconfig
This seems familiar but I can't figure out where "gcc" is hardcoded. Even when I use "gmake -j8 CC=gcc9" I don't get a dialog to add missing things to my sdkconfig. It looks like even "gmake defconfig" is a noop.
Wow that was hard to find. The problem is esp-idf/make/project.mk has this bit of clever hardcoding: # Set target compiler. Defaults to whatever the user has # configured as prefix + ye olde gcc commands CC := $(call dequote,$(CONFIG_TOOLPREFIX))gcc If you don't have gcc, everything breaks with a warning. Here's the pull request: https://github.com/openvehicles/esp-idf/pull/5 I believe this can get called two ways. One is when building esp-idf/tools/kconfig when CONFIG_TOOLPREFIX is not set (CC is set to gcc) and the other is when we're cross compiling (CC is set to xtensa-esp32-elf-cc). I'm not in love with fixing it here but when I tried to do it in OVMS.V3/Makefile after $(IDF_PATH)/make/project.mk is included it doesn't take effect when building kconfig. Lemme know if you can think of another way to solve this. But it does prompt me for new sdkconfig options again. BTW I've verified that I can build with CONFIG_MG_ENABLE_SSL but am running with something close to support/sdkconfig.default.hw31. Craig
participants (2)
-
Craig Leres -
Michael Balzer