Sysprogs forums › Forums › VisualGDB › Problem with Building STM32 Project
- This topic has 6 replies, 2 voices, and was last updated 2 years, 1 month ago by support.
-
AuthorPosts
-
September 27, 2022 at 07:21 #33254hartmutParticipant
Hi all,
It worked fine some months ago, but today a rebuild of an existing project failed with a lot of errors like “cannot execute ‘cc1’:CreateProecess: No such file or directory”. Also since it has c++ components the ‘cc1plus” equivalent.
The only change was the update from the 2021.8 to current 2022.x BSP.
Regeneration of MCU files did not change anything.Reverting the project and downloading the original BSP however produced the same problems.What i have found out so far:
In the visualGDB Project Properties I tried “Rebuild MSBuild & IntelliSense files for this toolchain”, which produced a similar error:
>> Run “cmd /c type nul | c:\sysgcc\arm-eabi\bin\arm-none-eabi-gcc.exe -x c -dM -v -E – ” in directory “” on local computer
>> ————————–
>> Using built-in specs.
>> COLLECT_GCC=c:\sysgcc\arm-eabi\bin\arm-none-eabi-gcc.exe
>> Target: arm-none-eabi
>> Configured with: /opt/arm/gcc-arm-none-eabi-10.3-2021.07/src/gcc/configure –build=x86_64-linux-gnu –host=i686-w64-mingw32 –target=arm-none-eabi –prefix=/opt/arm/gcc-arm-none-eabi-10.3-2021.07/install-mingw –libexecdir=/opt/arm/gcc-arm-none-eabi-10.3-2021.07/install-mingw/lib –infodir=/opt/arm/gcc-arm-none-eabi-10.3-2021.07/install-mingw/share/doc/gcc-arm-none-eabi/info –mandir=/opt/arm/gcc-arm-none-eabi-10.3-2021.07/install-mingw/share/doc/gcc-arm-none-eabi/man –htmldir=/opt/arm/gcc-arm-none-eabi-10.3-2021.07/install-mingw/share/doc/gcc-arm-none-eabi/html –pdfdir=/opt/arm/gcc-arm-none-eabi-10.3-2021.07/install-mingw/share/doc/gcc-arm-none-eabi/pdf –enable-languages=c,c++ –enable-mingw-wildcard –disable-decimal-float –disable-libffi –disable-libgomp –disable-libmudflap –disable-libquadmath –disable-libssp –disable-libstdcxx-pch –disable-nls –disable-shared –disable-threads –disable-tls –with-gnu-as –with-gnu-ld –with-headers=yes –with-newlib –with-python-dir=share/gcc-arm-none-eabi –with-sysroot=/opt/arm/gcc-arm-none-eabi-10.3-2021.07/install-mingw/arm-none-eabi –with-libiconv-prefix=/opt/arm/gcc-arm-none-eabi-10.3-2021.07/build-mingw/host-libs/usr –with-gmp=/opt/arm/gcc-arm-none-eabi-10.3-2021.07/build-mingw/host-libs/usr –with-mpfr=/opt/arm/gcc-arm-none-eabi-10.3-2021.07/build-mingw/host-libs/usr –with-mpc=/opt/arm/gcc-arm-none-eabi-10.3-2021.07/build-mingw/host-libs/usr –with-isl=/opt/arm/gcc-arm-none-eabi-10.3-2021.07/build-mingw/host-libs/usr –with-libelf=/opt/arm/gcc-arm-none-eabi-10.3-2021.07/build-mingw/host-libs/usr –with-host-libstdcxx=’-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm’ –with-pkgversion=’GNU Arm Embedded Toolchain 10.3-2021.08′ –with-multilib-list=rmprofile,aprofile
>> Thread model: single
>> Supported LTO compression algorithms: zlib
>> gcc version 10.3.1 20210621 (release) (GNU Arm Embedded Toolchain 10.3-2021.08)
>> COLLECT_GCC_OPTIONS=’-dM’ ‘-v’ ‘-E’ ‘-mcpu=arm7tdmi’ ‘-mfloat-abi=soft’ ‘-marm’ ‘-mlibarch=armv4t’ ‘-march=armv4t’
>> cc1 -E -quiet -v -iprefix c:\sysgcc\arm-eabi\bin\../lib/gcc/arm-none-eabi/10.3.1/ -isysroot c:\sysgcc\arm-eabi\bin\../arm-none-eabi -D__USES_INITFINI__ – -mcpu=arm7tdmi -mfloat-abi=soft -marm -mlibarch=armv4t -march=armv4t -dM
>> arm-none-eabi-gcc.exe: fatal error: cannot execute ‘cc1’: CreateProcess: No such file or directory
>> compilation terminated.
>> ————————–
>> Command exited with code 1″I executed the cmd part of the Command in the visualGDB TestFrameworks folder, which also produced a similar error.
Then I counterchecked the directory of C:\sysgcc\arm-eabi that it had the cc1.exe and cc1plus.exe. They are located in “C:\sysgcc\arm-eabi\lib\gcc\arm-none-eabi\10.3.1”.Strangely when I click on the link “arm-none-eabi-gcc.exe” in the error message of the visualGDB Log, then visualGDB gives an error “Failed to open [myProjectPath]are-none-eabi-gcc.exe” . That seems like there is some problem with the path.
I am using VisualStudio 2019 16.11.19 with VisualgDB Custom Edition 5.6R8 build 4702. The Project is build with MS Build.
regards Hartmut
September 27, 2022 at 08:08 #33255supportKeymasterHi,
This looks like a corrupt toolchain. Please try deleting it and reinstalling it via the VisualGDB Package Manager.
If it doesn’t help, please try disabling your antivirus. It might be interfering with invocation of some components.
September 27, 2022 at 23:30 #33261hartmutParticipantHi support,
thank you for your prompt reply
I already tried reinstalling the toolchain a few times. Also a different existing installation on a colleagues computer wielded the same results. Disabling the antivirus is not that easy, so I have not done that. However when I tried reinstalling the toolchain with visual studio as admin I sometimes got the info that the toolchain profile is missing. I never got this, when Installing without admin privilege. That problem could however not be resolved, quitting with the same error message as above. I attached the pictures of it. Is there a workaround for the automatic generation of the props file?
Attachments:
You must be logged in to view attached files.September 27, 2022 at 23:31 #33266September 27, 2022 at 23:32 #33268hartmutParticipantAfter the “Failed to extract GCC specs” I get the following Error Details: Encountered 1 errors while trying to update project(s):
—————— ki2 ——————
ki2: Failed to extract GCC specs —> m03: Failed to extract GCC specs
bei f13.h(ToolFlags b, String a, String c, ModifiedEnvirionment d)
bei f13.g_2(String a)
bei e7.g_2(String a)
bei BSPEngine.GCCSpecsDetector.DetectSpecs(RunGCCWithEmptyInput gccLauncher, String language, String queryCommandOverride)
bei e7.c(DiscoveredSettings& a, DiscoveredSettings& b, String c)
bei e7.f(ck1 a)
bei VisualGDB.Common_GUI.WPF.ItemizedProgressWindow.<>c__DisplayClass2_0`1.<RunAction>b__0()
— Ende der internen Ausnahmestapelüberwachung —
bei VisualGDB.Common_GUI.WPF.ItemizedProgressWindow.RunAction[_ResultType](i61`1 action, String title, String caption, r13 exceptionHandler, Int32 noFormTimeout, String[] stages)
bei VisualGDB.Common_GUI.WPF.ItemizedProgressWindowHelper.RunAction[_ResultType](i61`1 action, String title, String caption, r13 exceptionHandler, Int32 noFormTimeout, String[] stages)
bei yq1.s`1.e()
bei vd.m[_Type](f2`1 a)
bei yq1.y[_ResultType](i61`1 c, String d, r13 a, String[] b)
bei i13.i(ManagedToolchain b, jo d, pb1 a, Boolean c)
bei nl2.a.a_2(fd a, Object b)
bei i9.g.c_2(fd a)
bei i9.h.k()
trace=[VisualGDB.Common_GUI.WPF.ItemizedProgressWindow.RunAction:167, VisualGDB.Common_GUI.WPF.ItemizedProgressWindowHelper.RunAction:0, yq1+s`1.e:0, vd.m:71, yq1.y:162, i13.i:622, nl2+a.a_2:242, i9+g.c_2:36, i9+h.k:245]
—————— Inner exception ——————
—————— m03 ——————
m03: Failed to extract GCC specs
bei f13.h(ToolFlags b, String a, String c, ModifiedEnvirionment d)
bei f13.g_2(String a)
bei e7.g_2(String a)
bei BSPEngine.GCCSpecsDetector.DetectSpecs(RunGCCWithEmptyInput gccLauncher, String language, String queryCommandOverride)
bei e7.c(DiscoveredSettings& a, DiscoveredSettings& b, String c)
bei e7.f(ck1 a)
bei VisualGDB.Common_GUI.WPF.ItemizedProgressWindow.<>c__DisplayClass2_0`1.<RunAction>b__0()
trace=[f13.h:483, f13.g_2:40, e7.g_2:166, BSPEngine.GCCSpecsDetector.DetectSpecs:0, e7.c:59, e7.f:795, VisualGDB.Common_GUI.WPF.ItemizedProgressWindow+<>c__DisplayClass2_0`1.<RunAction>b__0:0]September 28, 2022 at 07:35 #33273hartmutParticipantHi support,
we found the problem. An environment variable was set incorrectly. Thanks for the support.
regards Hartmut
September 28, 2022 at 08:10 #33276supportKeymasterThanks for letting us know and good to know it works.
-
AuthorPosts
- You must be logged in to reply to this topic.