Closed engrziarehman closed 4 years ago
I don't see a 1.8 version
I found that builds with stm32/1.8.0 will fail, whereas changing to stm32/1.7.0 will succeed. This is with building a simple 'Blink' sketch for a BluePill board.
Which json file do you use? I do not have 1.8
The current json from stm32duino has 1.8.0: https://raw.githubusercontent.com/stm32duino/BoardManagerFiles/master/STM32/package_stm_index.json
indeed doesn't seem to work. No clue why. Someone knowing the stm32 should take a look and see what is wrong.
It looks like the ArduinoIDE using stm32 is on v1.8.0 and is able successfully do builds. Seems like the problem is specific to Sloeber-Eclipse.
Hi, Issue has been reported on stm32duino forum: https://www.stm32duino.com/viewtopic.php?f=18&t=173&p=1268#p1268
It seems Sloeber doesn't handle properly the prebuild recipe from the platform.txt. https://github.com/stm32duino/Arduino_Core_STM32/blob/f1d475a7ce9a73464bcf41b57d22803af8bc371a/platform.txt#L117-L120
@fpistm Thanks for the investigation. I see 2 problems with the hooks right now. The first command fails due to a / \ problem. Strangely enough the command works fine from the command line. So workaround : run the command from the command line. This is only needed once (and after removal of the release folder. The second is more confusing to me. The platform.txt contains recipe.hooks.prebuild.3.pattern.windows=cmd /c echo #include ^<SrcWrapper.h^> > "{build.src_wrapper.path}" As we are on windows Sloeber should create the key value environment variable A.RECIPE.HOOKS.PREBUILD.3.PATTERN=cmd /c echo #include ^<SrcWrapper.h^> > "{build.src_wrapper.path}" But on my system it is A.RECIPE.HOOKS.PREBUILD.3.PATTERN=cmd /c echo If found that this is caused because sloeber considers everything after # as a comment where only lines starting with # should be seen as comment lines https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5-3rd-party-Hardware-specification
This should be 2 relatively easy fixes.
the # comment problem only existed in non-boards related files like platform.txt. The other fix is pretty low-level so I'm running the CreateAndCompileDefaultInoOnAllBoardsTest before releasing.
welcome @jantje I know how it is hard to maintain such project so when we can help π
As I expected the test failed
I'm hitting a CDT issue that I see as very unlikely to be fixed. https://bugs.eclipse.org/bugs/show_bug.cgi?id=560330 I fear I'll have to come up with another way to fix this.
Now the 2 issues in Sloeber are fixed there seems to be a remaining issue.
The platform.txt contains
recipe.hooks.prebuild.3.pattern.windows=cmd /c echo #include ^<SrcWrapper.h^> > "{build.src_wrapper.path}"
I guess the ^is some kind of escaping for the < and > which are redirecting thingies. I really don't understand what they are trying to do nor why they are doing it the way they do (I think they are kind of stoned) but changing the line to below makes it work in the latest nightly in sloeber
recipe.hooks.prebuild.3.pattern.windows=cmd /c echo #include "SrcWrapper.h" > "{build.src_wrapper.path}"
@jantje
I guess the ^is some kind of escaping for the < and > which are redirecting thingies. I really don't understand what they are trying to do nor why they are doing it the way they do (I think they are kind of stoned) but changing the line to below makes it work in the latest nightly in sloeber
recipe.hooks.prebuild.3.pattern.windows=cmd /c echo #include "SrcWrapper.h" > "{build.src_wrapper.path}"
Unfortunately, this is not possible else this not produce the correct output with Arduino IDE:
sketch\SrcWrapper.cpp:1:10: error: #include expects "FILENAME" or <FILENAME>
1 | #include SrcWrapper.h
| ^~~~~~~~~~
exit status 1
I've tested a lot of combination, the only one working is using the '^' escape character.
The problem is that -on windows- arduino uses java to run windows commands via cygwin (a linux emulator) where Sloeber uses java to run a windows command that starts a make (there are several makes each with their pro's and con's) which currently starts a windows sh (again their are several sh's each with their pro's and con's).
This means the more unusual a command; the more it is likely to behave differently. I have never before seen ^ as a escape character before, so to me this command is a extremely unusual command.
Googling didn't tell me much about using ^as a escape character.
I wouldn't be surprised that this works because there is a bug somewhere or it is a arduino ide behaviour.
Anyway: have you tried?
recipe.hooks.prebuild.3.pattern.windows=cmd /c echo "#include <SrcWrapper.h>" > "{build.src_wrapper.path}"
What I'm most curiously about is: Why do you need to create 2 static files (one empty header :astonished: ) during the build process? Why can't they just be part of the core or variant?
Googling didn't tell me much about using ^as a escape character.
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/echo#remarks
To display a pipe (|) or redirection character (< or >) when you are using echo, use a caret (^) immediately before the pipe or redirection character (for example, ^|, ^>, or ^<). To display a caret, type two carets in succession (^^).
Anyway: have you tried?
recipe.hooks.prebuild.3.pattern.windows=cmd /c echo "#include <SrcWrapper.h>" > "{build.src_wrapper.path}"
As said I've tried several syntax, with this one:
sketch\SrcWrapper.cpp:1:1: error: expected unqualified-id before string constant
1 | "#include <SrcWrapper.h>"
| ^~~~~~~~~~~~~~~~~~~~~~~~~
exit status 1
Why do you need to create 2 static files (one empty header π² ) during the build process? Why can't they just be part of the core or variant?
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/echo#remarks
Seems like a windows specific thing. Strange as this goes against my understanding arduino IDE uses cygwin and not native windows.
1 | "#include
"
Again this is native windows behaviour and goes against the idea arduino IDE uses cygwin. And yes.....cygwin is removed from arduino IDE in 2015 :sweat_smile: my knowledge of arduio IDE seems pretty outdated.
But then I do not understand why
recipe.hooks.prebuild.3.pattern.windows=cmd /c echo #include "SrcWrapper.h" > "{build.src_wrapper.path}"
doesn't work. Does the arduino IDE removes the "'s? If so Why?
This is due also to cmd /c
usage which implies to protect args of the echo command to execute
I have been investigating these prebuild commands and now I understand the complexities you face and how it works. However ... these prebuild commands are purely aiming at the arduino IDE build process. It is very unlikely that any other tool will work properly with these prebuild commands.
Problem 1: The fact the scrWrapper library gets picked up by sloeber is (in my eyes) a bug in CDT https://bugs.eclipse.org/bugs/show_bug.cgi?id=560405
Problem2: As soon as sloeber processes these prebuild commands properly and you would start using build_opt.h sloeber fails. This because you assume build_opt.h is copied during the build process. Something Sloeber doesn't do.
Alternative idea 1: Why not creating build_opt.h and src_wrapper.cpp in the sketch folder. Some people need build_opt.h to be there. This doesn't make any assumptions about the build process.
Alternative idea 2: Why not have 2 source files build_opt.h.org and src_wrapper.cpp.org and copyrename them. This way you can put content in the files explaining what they are about and how (not) to use them. The pre build commands become lots easier as you only need to copy (don't overwrite) the files. Linux : cp -n myoldfile.txt mycopiedfile.txt windows: echo n | copy /-y
This is due also to
cmd /c
usage which implies to protect args of the echo command to execute
Well, copy can be an option. Comment in build_opt.h not as this will not be accepted by gcc. The best way is you try on your side then give me the one which work and then I could test also with Arduino Ide.
This works in windows in sloeber nightly because {build.source.path} was not yet defined
# Pre and post build hooks
extra.path={runtime.platform.path}/extra
build.opt.path={build.source.path}/build_opt.h
build.opt.org.path={extra.path}/build_opt.h
build.src_wrapper.path={build.source.path}/SrcWrapper.cpp
build.src_wrapper.org.path={extra.path}/SrcWrapper.cpp
# Create empty {build.opt} if not exists in the sketch dir
recipe.hooks.prebuild.1.pattern= cp -n "{build.opt.org.path}" "{build.opt.path}"
recipe.hooks.prebuild.1.pattern.windows=robocopy "{extra.path}" "{build.source.path}" build_opt.h /XC /njh /njs /ndl &
# Force include of SrcWrapper library
recipe.hooks.prebuild.2.pattern= cp -n "{build.src_wrapper.org.path}" "{build.src_wrapper.path}"
recipe.hooks.prebuild.2.pattern.windows=robocopy "{extra.path}" "{build.source.path}" SrcWrapper.cpp /XC /njh /njs /ndl &
I put the files in a extra folder
I'm not agree with this as you copy the build_opt.h in the original sketch folder (default Arduino or Library examples) and I do not want do that.
Why not?
If user change core then it will not build because SrcWrapper.h will not exists for this target. Also the default sketch folder should not be changed. Also, if user have a sketch using a custom build_opt.h then with the copy it will be replaced because the empty build_opt.h will be newer than his one.
Ah and also, with Arduino IDE, this is not stable, I had to launch build several time before having the prebuild pass successfully. Exactly 3 times, 1st time, it copy the build_opt.h. 2nd one to copy the SrcWrapper.cpp. Then a 3rd time to pass the build as all files already copied.
Also, if user have a sketch using a custom build_opt.h then with the copy it will be replaced because the empty build_opt.h will be newer than his one.
I tested this and this is not how it works. The only case I could see this to be a problem is: a user has a modded build_opt.h, installs a new version of the platform and the date of the local build_opt.h is older than the one of the new platform version. Which is very unlikely. (x)copy would have done a better job but unfortunately xcopy has a problem with mixed / in the path and I could not get it to work
Ah and also, with Arduino IDE, this is not stable, I had to launch build several time before having the prebuild pass successfully. Exactly 3 times, 1st time, it copy the build_opt.h. 2nd one to copy the SrcWrapper.cpp. Then a 3rd time to pass the build as all files already copied.
Strange. did you include the & at the end of the command? I'll give this a try in arduino IDE myself.
Also the default sketch folder should not be changed.
I think this is the place to change things.
The only case I could see this to be a problem is: a user has a modded build_opt.h, installs a new version of the platform and the date of the local build_opt.h is older than the one of the new platform version. Which is very unlikely.
This is exactly, what I said and this can happen.
Strange. did you include the & at the end of the command?
Yes, exactly the same line than you.
I think this is the place to change things.
No, we could not change the original sketch folder. As I said if user change to another core then this will not build. We have to not modify the original sketch folder, that's why current version add the needed file to the build folder. I guess the copy should do this and avoid all those risks.
given how stm32 tries to do things the pre-build commands will never work in sloeber. This makes that stm32 will not work out of the box since version 1.8. Work around: after installation remove the prebuild hook stuff from platform.txt delete -"@{build.opt.path}" from compiler.extra_flags in platform.txt or replace platform.txt with this one platform.txt
For each project: Add the scrWrapper lib to your project
EDIT mthumb must not be deleted
@jantje I don't really understand. I never told I will not change the prebuild. I have to do some test based on your first experimentation. I would like simply copy the build_opt.h and SrcWrapper.cpp in the output folder instead of creating them. Is this will be ok for Sloeber?
Sloeber will never work out of the box with V1.8. Maybe in a later version it will work out of the box again but V1.8 will always need a workaround. So from a sloeber point of view this issue is a "known limitation" with a "workaround" and "closed"
As for later versions I tested my script in arduino IDE and -as you noticed- it simply doesn't work. Arduino IDE seems to insist on capturing the exit code of robobcopy. Arduino IDE doesn't pick up the new files in the project folder. So basically -when accepting you need to add those files on the fly to the build process- Arduino IDE implementation enforces the solution "copy the files to {build folder}/sketch" which should not work in Sloeber (CDT people agree with me on this one)
Which makes me believe there are 3 options left 1)challenge the "add those files on the fly to the build process" solution 2)Make a different copy process between Sloeber and Arduino IDE 3)Forget about out of the box compatibility between Sloeber and arduino IDE
I'm agreed this will never work out of the box with 1.8.0 and we know the workaround. But I didn't understand why it is not possible to find a generic way. ~I'm already used several time Eclipse and creating some prebuild command to copy some files in the output directory was possible.~ Edit: OK I think I understood your point. Eclipse is able to copy file in the output folder but will not be considered to the build as not in the project workspace, Right?
Forget about out of the box compatibility between Sloeber and arduino IDE
Seems obvious to told that while we can try to solve the issue. π’
Edit: OK I think I understood your point. Eclipse is able to copy file in the output folder but will not be considered to the build as not in the project workspace, Right?
it is complicated. But basically Right.
Forget about out of the box compatibility between Sloeber and arduino IDE
Seems obvious to told that while we can try to solve the issue. π’
This is one of the 3 options.
PS: it seems to me we have a language/culture problem here. Where are you from?
France :wink: No worries, I have lot of support in // and sometimes I answer too quickly π
It is complicated. one of the complications is that build_opt and scrWrapper are 2 different solutions to 2 different problems.
If we focus on build_opt The prebuild copying solution will not work when a user creates a build_opt file in the project.
This because the solution assumes that build_opt in the sketch folder is copied to {build.path}/sketch/{build.opt.name} by the build process itself. Sloeber does not copy source files like Arduino IDE
Issue 1 Therefore when a user creates build_opt sloeber will not copy it to {build.path}/sketch/{build.opt.name} and a old build_opt will be used (sloeber will not delete {build.path}/sketch/{build.opt.name} ).
The user will not understand why the compilation options are not taken into account. The first thing to do is to delete the target folder. This will delete {build.path}/sketch/{build.opt.name}
issue 2 After that the build will fail because build_opt is not being copied by sloeber nor by the prebuild command.
France π No worries, I have lot of support in // and sometimes I answer too quickly π
I'm from belgium so internet wise we are close ;-)
Right we are close π» At this time I'm agreed with you. I will keep this is mind and if I can found a proper way I will get back.
build_opt.h
#include "SrcWrapper.h"
to the sketch (.ino)@fpistm try the workaround you propose. build->remove the release folder->build will fail.
@jantje I've just tested and it works. The workaround proposed is functional as expected.
'Finished building: MyBlink.hex'
' '
'Building target: MyBlink'
'Printing size:'
"C:\IDE\Sloeber\arduinoPlugin\packages\STM32\tools\xpack-arm-none-eabi-gcc\9.2.1-1.1/bin/arm-none-eabi-size" -A "C:/IDE/workspace/.metadata/MyBlink/Release/MyBlink.elf"
C:/IDE/workspace/.metadata/MyBlink/Release/MyBlink.elf :
section size addr
.isr_vector 268 134217728
.text 8956 134217996
.rodata 1024 134226952
.init_array 12 134227976
.fini_array 8 134227988
.data 136 536870912
.bss 452 536871048
._user_heap_stack 1536 536871500
.ARM.attributes 41 0
.debug_info 226431 0
.debug_abbrev 28946 0
.debug_aranges 4784 0
.debug_ranges 5304 0
.debug_line 93791 0
.debug_str 39909 0
.comment 102 0
.debug_frame 13300 0
.debug_loc 66966 0
Total 491966
'Finished building target: MyBlink'
' '
@fpistm I followed the workaround you suggested, but combiner failed, ' ' 'Starting combiner' "D:\sloeber431\sloeber\arduinoPlugin\packages\STM32\tools\xpack-arm-none-eabi-gcc\9.2.1-1.1/bin/arm-none-eabi-gcc" -mcpu=cortex-m3 -mthumb -Os --specs=nano.specs -Wl,--defsym=LD_FLASH_OFFSET=0x2000 -Wl,--defsym=LD_MAX_SIZE=65536 -Wl,--defsym=LD_MAX_DATA_SIZE=20480 -Wl,--cref -Wl,--check-sections -Wl,--gc-sections -Wl,--entry=Reset_Handler -Wl,--unresolved-symbols=report-all -Wl,--warn-common "-TD:\sloeber431\sloeber\arduinoPlugin\packages\STM32\hardware\stm32\1.8.0\variants\PILL_F103XX/ldscript.ld" "-Wl,-Map,Z:/Arduino/EclipseWorkspace/blink/Release/blink.map" "-LD:\sloeber431\sloeber\arduinoPlugin\packages\STM32\tools\CMSIS\5.5.1/CMSIS/DSP/Lib/GCC/" -larm_cortexM3l_math -o "Z:/Arduino/EclipseWorkspace/blink/Release/blink.elf" "-LZ:/Arduino/EclipseWorkspace/blink/Release" -Wl,--start-group .\sloeber.ino.cpp.o .\libraries\SrcWrapper\src\stm32\PortNames.c.o .\libraries\SrcWrapper\src\stm32\analog.cpp.o .\libraries\SrcWrapper\src\stm32\bootloader.c.o .\libraries\SrcWrapper\src\stm32\clock.c.o .\libraries\SrcWrapper\src\stm32\core_callback.c.o .\libraries\SrcWrapper\src\stm32\dwt.c.o .\libraries\SrcWrapper\src\stm32\hw_config.c.o .\libraries\SrcWrapper\src\stm32\interrupt.cpp.o .\libraries\SrcWrapper\src\stm32\lock_resource.c.o .\libraries\SrcWrapper\src\stm32\low_power.c.o .\libraries\SrcWrapper\src\stm32\pinmap.c.o .\libraries\SrcWrapper\src\stm32\rtc.c.o .\libraries\SrcWrapper\src\stm32\stm32_def.c.o .\libraries\SrcWrapper\src\stm32\stm32_eeprom.c.o .\libraries\SrcWrapper\src\stm32\system_stm32yyxx.c.o .\libraries\SrcWrapper\src\stm32\timer.c.o .\libraries\SrcWrapper\src\stm32\uart.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_adc.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_bdma.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_comp.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_cordic.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_crc.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_crs.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_dac.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_delayblock.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_dma.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_dma2d.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_exti.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_fmac.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_fmc.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_fsmc.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_gpio.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_hrtim.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_i2c.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_lptim.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_lpuart.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_mdma.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_opamp.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_pka.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_pwr.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_rcc.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_rng.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_rtc.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_sdmmc.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_spi.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_swpmi.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_tim.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_ucpd.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_usart.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_usb.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_utils.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_adc.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_adc_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_can.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_cec.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_comp.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_comp_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_cordic.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_cortex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_crc.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_crc_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_cryp.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_cryp_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_dac.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_dac_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_dcmi.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_dcmi_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_dfsdm.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_dfsdm_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_dma.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_dma2d.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_dma_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_dsi.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_eth.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_eth_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_exti.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_fdcan.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_firewall.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_flash.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_flash_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_flash_ramfunc.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_fmac.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_fmpi2c.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_fmpi2c_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_gfxmmu.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_gpio.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_gpio_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_hash.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_hash_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_hcd.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_hrtim.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_hsem.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_i2c.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_i2c_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_i2s.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_i2s_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_ipcc.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_irda.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_iwdg.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_jpeg.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_lcd.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_lptim.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_ltdc.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_ltdc_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_mdios.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_mdma.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_mmc.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_mmc_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_msp_template.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_nand.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_nor.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_opamp.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_opamp_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_ospi.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_pccard.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_pcd.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_pcd_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_pka.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_pwr.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_pwr_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_qspi.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_ramecc.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_rcc.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_rcc_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_rng.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_rtc.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_rtc_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sai.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sai_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sd.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sd_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sdadc.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sdram.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_smartcard.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_smartcard_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_smbus.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_spdifrx.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_spi.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_spi_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sram.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_swpmi.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_tim.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_tim_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_timebase_rtc_alarm_template.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_timebase_rtc_wakeup_template.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_timebase_tim_template.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_tsc.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_uart.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_uart_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_usart.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_usart_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_wwdg.c.o .\libraries\SrcWrapper\src\syscalls.c.o .\core\variant\PeripheralPins.c.o .\core\variant\variant.cpp.o Z:/Arduino/EclipseWorkspace/blink/Release/arduino.ar -lc -Wl,--end-group -lm -lgcc -lstdc++ arm-none-eabi-gcc: error: .\libraries\SrcWrapper\src\HAL\stm32yyx_hal_spi_ex.c.o: No such file or directory makefile:94: recipe for target 'blink.elf' failed make[1]: [blink.elf] Error 1 makefile:73: recipe for target 'all' failed make: [all] Error 2
@engrziarehman does my workaround work for you? https://github.com/Sloeber/arduino-eclipse-plugin/issues/1143#issuecomment-590008788
I've tried the various workarounds (use new 'platform.txt', add SrcWrapper lib to project, add #include "SrcWrapper.h", add empty 'build_opt.h') but with stm32 v1.8.0 I get a similar "No such file or directory" error on the combiner that @engrziarehman is reporting. (See here for full build-log output.)
arm-none-eabi-gcc: error: \libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sram.c.o: No such file or directory
It looks like arm-none-eabi-gcc is not specified with its full qualifying path. This error is typically caused by not installing the platform via the boards manager.
I see full paths in the build-log output I posted; the build succeeds with stm32 v1.7.0.
Strange in the log you can see
'Building file: D:\Programs\Sloeber\arduinoPlugin\packages\STM32\hardware\stm32\1.8.0\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sram.c'
'Starting C compile'
"D:\Programs\Sloeber\arduinoPlugin\packages\STM32\tools\xpack-arm-none-eabi-gcc\9.2.1-1.1/bin/arm-none-eabi-gcc" -mcpu=cortex-m3 -c -Os -Wall -Wextra -std=gnu11 -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -MMD "-I" "-ID:\Programs\Sloeber\arduinoPlugin\packages\STM32\hardware\stm32\1.8.0\cores\arduino/avr" "-ID:\Programs\Sloeber\arduinoPlugin\packages\STM32\hardware\stm32\1.8.0\cores\arduino/stm32" "-ID:\Programs\Sloeber\arduinoPlugin\packages\STM32\hardware\stm32\1.8.0\cores\arduino/stm32/LL" "-ID:\Programs\Sloeber\arduinoPlugin\packages\STM32\hardware\stm32\1.8.0\cores\arduino/stm32/usb" "-ID:\Programs\Sloeber\arduinoPlugin\packages\STM32\hardware\stm32\1.8.0\cores\arduino/stm32/usb/hid" "-ID:\Programs\Sloeber\arduinoPlugin\packages\STM32\hardware\stm32\1.8.0\cores\arduino/stm32/usb/cdc" "-ID:\Programs\Sloeber\/arduinoPlugin/packages/STM32/hardware/stm32/1.8.0/system/Drivers/STM32F1xx_HAL_Driver/Inc" "-ID:\Programs\Sloeber\/arduinoPlugin/packages/STM32/hardware/stm32/1.8.0/system/Drivers/STM32F1xx_HAL_Driver/Src" "-ID:\Programs\Sloeber\/arduinoPlugin/packages/STM32/hardware/stm32/1.8.0/system/STM32F1xx" "-ID:\Programs\Sloeber\/arduinoPlugin/packages/STM32/hardware/stm32/1.8.0/system/Middlewares/ST/STM32_USB_Device_Library/Core/Inc" "-ID:\Programs\Sloeber\/arduinoPlugin/packages/STM32/hardware/stm32/1.8.0/system/Middlewares/ST/STM32_USB_Device_Library/Core/Src" -DSTM32F1xx -DARDUINO=10802 -DARDUINO_BLUEPILL_F103C8 -DARDUINO_ARCH_STM32 -DBOARD_NAME="BLUEPILL_F103C8" -DSTM32F103xB "-ID:\Programs\Sloeber\arduinoPlugin\packages\STM32\tools\CMSIS\5.5.1/CMSIS/Core/Include/" "-ID:\Programs\Sloeber\/arduinoPlugin/packages/STM32/hardware/stm32/1.8.0/system/Drivers/CMSIS/Device/ST/STM32F1xx/Include/" "-ID:\Programs\Sloeber\/arduinoPlugin/packages/STM32/hardware/stm32/1.8.0/system/Drivers/CMSIS/Device/ST/STM32F1xx/Source/Templates/gcc/" "-ID:\Programs\Sloeber\arduinoPlugin\packages\STM32\tools\CMSIS\5.5.1/CMSIS/DSP/Include" -I"D:\Programs\Sloeber\arduinoPlugin\packages\STM32\hardware\stm32\1.8.0\libraries\SrcWrapper\src" -I"D:\Programs\Sloeber\arduinoPlugin\packages\STM32\hardware\stm32\1.8.0\cores\arduino" -I"D:\Programs\Sloeber\arduinoPlugin\packages\STM32\hardware\stm32\1.8.0\variants\PILL_F103XX" -MMD -MP -MF"libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sram.c.d" -MT"libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sram.c.o" -D__IN_ECLIPSE__=1 "D:\Programs\Sloeber\arduinoPlugin\packages\STM32\hardware\stm32\1.8.0\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sram.c" -o "libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sram.c.o"
'Finished building: D:\Programs\Sloeber\arduinoPlugin\packages\STM32\hardware\stm32\1.8.0\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sram.c'
"libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sram.c.o"
in the linking it is
.\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sram.c.o
so there is a .\ difference. Can you check the release folder and see if release\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sram.c.o exists?
Yes, it's in there:
D:\Programs\Sloeber\workspace\test2158>dir release\libraries\SrcWrapper\src\HAL\
stm32yyxx_hal_sram*
Volume in drive D has no label.
Volume Serial Number is C2DB-3F38
Directory of D:\Programs\Sloeber\workspace\test2158\release\libraries\SrcWrappe
r\src\HAL
02/29/2020 04:45 PM 8,424 stm32yyxx_hal_sram.c.d
02/29/2020 04:45 PM 772 stm32yyxx_hal_sram.c.o
I do not really understand what is going on on your system. It has nothing to do with the prebuild commands what this issue is about. To me it looks like some side effect of something else going on on your system (virus check, disk full, ....)
@ethomas997 Looking at your log again it seems the linking command is wrong. It ends with " D:/Programs/Sloeber/workspace/test2158/Release/arduino.ar -lc -Wl,--end-group -lm -lgcc -lstdc++'
I have 4.3.1 sloeber installed, all other repositories are compiling fine, except Arduino_Core_STM32, its 1.8.0 version installed. I have created empty arduino project and selected Bluepill as controller, then after compilation it is giving error in the end while 'starting combiner' appears.
D:/sloeber431/sloeber/arduinoPlugin/tools/make/make --no-print-directory main-build 'Starting combiner' "D:\sloeber431\sloeber\arduinoPlugin\packages\STM32\tools\xpack-arm-none-eabi-gcc\9.2.1-1.1/bin/arm-none-eabi-gcc" -mcpu=cortex-m3 -mthumb -Os --specs=nano.specs -Wl,--defsym=LD_FLASH_OFFSET=0x2000 -Wl,--defsym=LD_MAX_SIZE=65536 -Wl,--defsym=LD_MAX_DATA_SIZE=20480 -Wl,--cref -Wl,--check-sections -Wl,--gc-sections -Wl,--entry=Reset_Handler -Wl,--unresolved-symbols=report-all -Wl,--warn-common "-TD:\sloeber431\sloeber\arduinoPlugin\packages\STM32\hardware\stm32\1.8.0\variants\PILL_F103XX/ldscript.ld" "-Wl,-Map,Z:/Arduino/EclipseWorkspace/ArduinoCoreSTM32_test/Release/ArduinoCoreSTM32_test.map" "-LD:\sloeber431\sloeber\arduinoPlugin\packages\STM32\tools\CMSIS\5.5.1/CMSIS/DSP/Lib/GCC/" -larm_cortexM3l_math -o "Z:/Arduino/EclipseWorkspace/ArduinoCoreSTM32_test/Release/ArduinoCoreSTM32_test.elf" "-LZ:/Arduino/EclipseWorkspace/ArduinoCoreSTM32_test/Release" -Wl,--start-group .\ArduinoCoreSTM32_test.cpp.o .\core\variant\PeripheralPins.c.o .\core\variant\variant.cpp.o Z:/Arduino/EclipseWorkspace/ArduinoCoreSTM32_test/Release/arduino.ar -lc -Wl,--end-group -lm -lgcc -lstdc++ d:/sloeber431/sloeber/arduinoplugin/packages/stm32/tools/xpack-arm-none-eabi-gcc/9.2.1-1.1/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: Z:/Arduino/EclipseWorkspace/ArduinoCoreSTM32_test/Release/arduino.ar(startup_stm32yyxx.S.o): in function
LoopFillZerobss': makefile:90: recipe for target 'ArduinoCoreSTM32_test.elf' failed (.text.Reset_Handler+0x26): undefined reference to
SystemInit' makefile:69: recipe for target 'all' failed d:/sloeber431/sloeber/arduinoplugin/packages/stm32/tools/xpack-arm-none-eabi-gcc/9.2.1-1.1/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: Z:/Arduino/EclipseWorkspace/ArduinoCoreSTM32_test/Release/arduino.ar(main.cpp.o): in functionpremain()': main.cpp:(.text.startup._Z7premainv+0x4): undefined reference to
HAL_NVIC_SetPriorityGrouping' d:/sloeber431/sloeber/arduinoplugin/packages/stm32/tools/xpack-arm-none-eabi-gcc/9.2.1-1.1/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: Z:/Arduino/EclipseWorkspace/ArduinoCoreSTM32_test/Release/arduino.ar(board.c.o): in functioninit': board.c:(.text.init+0x0): undefined reference to
hw_config_init' collect2.exe: error: ld returned 1 exit status make[1]: [ArduinoCoreSTM32_test.elf] Error 1 make: [all] Error 2