esp-idf: [TW#27526] linker script generation failed for C:/Dropbox/devs/ws/z-sdk/esp-idf/components/esp32/ld/esp32.common.ld.in
Environment
- Development Kit: none
- Module or chip used: ESP32-WROOM-32
- IDF version (run
git describe --tagsto find it): // v3.2-beta1-182-g4c881708d - Build System: Make
- Compiler version (run
xtensa-esp32-elf-gcc --versionto find it): // 1.22.0-80-g6c4433a5 - Operating System: Windows
- Power Supply: external 5V
Problem Description
Trying to build new binary after having updated to latest IDF and MSYS
Expected Behavior
Expect make to be successful
Actual Behavior
make -j9 all Toolchain path: /opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc Toolchain version: crosstool-ng-1.22.0-80-g6c4433a5 Compiler version: 5.2.0 Python requirements from C:/Dropbox/devs/ws/z-sdk/esp-idf/requirements.txt are satisfied. CC build/iMacs/x_config.o AR build/iMacs/libiMacs.a Generating libiMacs.a.sections_info Generating esp32.common.ld linker script generation failed for C:/Dropbox/devs/ws/z-sdk/esp-idf/components/esp32/ld/esp32.common.ld.in ERROR: C:/Dropbox/devs/ws/z-sdk/esp-idf/Kconfig:59: Could not open ‘/c/Dropbox/devs/ws/z-sdk/esp-idf/components/bootloader/Kconfig.projbuild’ (ENOENT: No such file or directory). Perhaps the $srctree environment variable (which was unset) is set incorrectly. Note that the current value of $srctree is saved when the Kconfig instance is created (for consistency and to cleanly separate instances). Also note that e.g. $FOO in a ‘source’ statement does not refer to the environment variable FOO, but rather to the Kconfig Symbol FOO (which would commonly have ‘option env=“FOO”’ in its definition). Traceback (most recent call last): File “C:/Dropbox/devs/ws/z-sdk/esp-idf/tools/ldgen/ldgen.py”, line 101, in <module> main() File “C:/Dropbox/devs/ws/z-sdk/esp-idf/tools/ldgen/ldgen.py”, line 98, in main os.remove(output_file.name) WindowsError: [Error 32] The process cannot access the file because it is being used by another process: ‘C:/Dropbox/devs/ws/z-appl/irmacs/build/esp32/esp32.common.ld’ make: *** [/c/Dropbox/devs/ws/z-sdk/esp-idf/components/esp32/Makefile.projbuild:51: /c/Dropbox/devs/ws/z-appl/irmacs/build/esp32/esp32.common.ld] Error 1 make: *** Waiting for unfinished jobs…
Steps to reproduce
Debug Logs
N/A
Other items if possible
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 26 (8 by maintainers)
Commits related to this issue
- cmake: fix mconf path for existing mconf Fixes https://github.com/espressif/esp-idf/issues/2771 Fixes https://github.com/espressif/esp-idf/issues/2722 — committed to espressif/esp-idf by renzbagaporo 6 years ago
This should be fixed in master as of commit 3970ea60deade62224ad227fd5f986d29b0abdfb
Thanks everyone for reporting and being patient with the fix.
Hi all,
Thanks @ulfalizer for the helpful info about kconfiglib. I agree this is not a kconfiglib problem, and that we should update our (patched) kconfiglib soon! 😃
@JOO200 @alsaleem00 You’re both using Eclipse on Windows, yes? I’m not able to reproduce any problem building in Eclipse on Windows with current master branch, my guess is this was the same issue as #2812 that was fixed in d3938c8.
If you’re not still not able to build in Eclipse with current master, please check all the settings are the same as given in the ESP-IDF Eclipse Setup guide. If it’s not working, please open a new issue and post as many details as you can about your environment, paths, build logs, etc. and we’ll continue from there.
Hello,
As a note, Kconfiglib itself doesn’t do any custom path handling. It just passes paths as given to
open(), and joins paths withos.path.join(), which uses the native format for the OS/Python installation (backslashes for plain Windows Python, etc.) If you run into problems, they might be related to whatever Python on MSYS does.Using
/instead of\as the path separator works fine on Windows too (see os.altsep).The version of Kconfiglib in Espressif is pretty old by the way. There’s lots of improvements in the latest version, like default-UTF-8 decoding, faster parsing, strict syntax checking, support for glob patterns in
source, node iteration helpers, menuconfig implementations, a Kconfig preprocessor, and more.Ask if you have any questions!
Cheers, Ulf
@detly yes, if you’re getting a linker failure on Ubuntu then a new issue with the details sounds best. Thanks.
@projectgus fyi, 964f5a9 works for me, but 3970ea6 doesn’t.