Stm32cubeIde: [Startup/subdir.mk:15: Startup/startup_stm32f100rbtx.o] Error 3

[Ruslan1]

Created a simple project for my vldiscovery board in STM32cubeIde. try to compile and get this error message. It seems that the compiler can't find directory Startup in path. Added it to the path list - the result is still the same. Whats that? how to solve?

[Markus GIRDLAND]

Is this from a created STM32 project inside CubeIDE itself? Just a newly created project that immediately fails?

What's the path to the workspace? Do you use any non-ascii characters or spaces anywhere?

[Ruslan1]

//Is this from a created STM32 project inside CubeIDE itself? Just a newly created project that immediately fails?

Yes. The new project.

//What's the path to the workspace? Do you use any non-ascii characters or spaces anywhere?

The workspace path is: D:\Calculations\STM32\

The project path is: D:\Calculations\STM32\proba

The exact error is: make: *** [Startup/subdir.mk:15: Startup/startup_stm32f100rbtx.o] Error 3 proba C/C++ Problem

As I see, the compiler can't generate object file startup_stm32f100rbtx.o from the file startup_stm32f100rbtx.s, which is in the D:\Calculations\STM32\proba\Startup directory.

[Markus GIRDLAND]

Any chance you know how to reproduce the problem?

Does it happen with every project you create?

Could you send the project to me (e-mail is in my profile)?

[Ruslan1]

Have been sent the project in message.

[MWebj]

I have exactly the same problem. Installed CubeIDE and created a project from scratch. I don't know if it matters, but my CubeIDE is installed in

C:\Program Files\STMicroelectronics\STM32CubeIDE which is the default location for 64-bit apps in Swedish WIndows 10.

[MWebj]

One thing I've noticed is that if I open Project/Properties and look at C/C++ Build/Environment/PATH then I see that the STM path's given by the IDE uses a mixture of '\' and '/'. '\' for the plugins and '/' for java.

C:\Program Files\STMicroelectronics\STM32CubeIDE\v1.0.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.7-2018-q2-update.win32_1.0.0.201904181610\tools\bin;
C:\Program Files\STMicroelectronics\STM32CubeIDE\v1.0.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.make.win32_1.0.0.201904231117\tools\bin;
C:/Program Files/STMicroelectronics/STM32CubeIDE/v1.0.0/STM32CubeIDE/jre/bin/server;
C:/Program Files/STMicroelectronics/STM32CubeIDE/v1.0.0/STM32CubeIDE/jre/bin;
C:/Program Files/STMicroelectronics/STM32CubeIDE/v1.0.0/STM32CubeIDE/jre/lib/amd64

[MWebj]

This is really bizarr!!

In Project/Properties/C/C++ Build/Builder setting I modify the "Build command" to "make -n -w -j2".

I then do a Project/Build All to get the commands that make issues in the CDT Build Console, which is

make -n -w -j2 all 
make: Entering directory 'C:/Data/STM32-Workbench/VCU/Debug'
arm-none-eabi-gcc -mcpu=cortex-m0plus -g3 -c -x assembler-with-cpp --specs=nano.specs -mfloat-abi=soft -mthumb -o "Startup/startup_stm32l082kztx.o" "../Startup/startup_stm32l082kztx.s"

The I'II open a DOS-Shell and set path according to Project/Properties/C/C++ Build/Environment/PATH in my previous post above.

If I then copy'n'paste the compiler command on line 3 above into the DOS-Shell, then command completes successfully !!!!!!!

But then I discover something even more bizzar!!

I open a local console in Eclipse. Go to my build dir C:/Data/STM32-Workbench/VCU/Debug and start to type in the compile command because I can't copy'paste into this stupid console :(

So I get to the -o parameter and type '-o "St" and then press tab. The console expands this to "Startup". I change this to "Startup/" and press tab again. Now console expands this to "Startup/Drivers" !!!! A complete bogus expansion!!! And if I continue to huit tab it walks thru all files in the Debug directory. BUT, if I instead change to "Startup\" and hit tab then I only get "Startup\subdir.mk" which is a correct expansion since this is the only file present in Debug\Startup.

The same happens when I try to expand the input file "../Startup/" with tab. It incorrectly expands to "../Startup/Drivers". But if I change \ to / then expansion works correctly.

Anyway, so now I have added the compiler dir to Windows system environment path, restarted Eclipse and if I look at the path environment variable in the Eclipse console I can see that the compiler path is there. I've also verified that the correct compiler starts when I run arm-none-eabi-gcc.

Again I see that when I run the command above issued by make in Eclipse Command Shell Console it runs fine (both with '/' and '\') in filepaths.

But, again. If I now run Project/Build All it fails with a "Can't find path" error message. It really ***** to have to spend hours and hours figuring out why a fresh install of a software package doesn't even manage to run the most trivial test :(

[MWebj]

Now I've found what causes Eclipse not being able to build. It's because Eclipse MAY NOT BE INSTALLED IN A DIRECTORY WHERE THERE ARE SPACES IN THE PATH!!!!! Such as "C:\Program Files" :(

This is really incredible. Hasn't ST tested this software on any other location than default C:\ST ??? And since there is this limitation, why does the installer accept changing to a different location if it may break the entire IDE? This is really pathetic!

Programs should NOT be installed under the root since they will not then get the correct security settings, and will then be subject to infection. How hard can it be to do things right??? Get some real Windows programmers who knows how to make proper applications, and not just hacks.

[MWebj]

If you can't figure out how to handle blanks in paths, try converting the paths to 8.3 style which doesn't have any spaces

[Ruslan1]

Please explain step by step how to solve the issue, I'm not an expert.

The program path is C:\Program files.....!

Thanks!

[turboscrew]

Usually it's enough to give paths containing blanks, quoted.

[MWebj]

It's not the installer that fails when I give it a path which contains blanks. It's Eclipse itself whch for some reason can't run the compiler when it's installed in a directory which contains blanks. And then it won't help to give the installer a quoted path since Eclipse will figure out by itself where it's installed.

[turboscrew]

I think most of the paths in eclipse - including paths to plugins - can be changed.

Also, thank Microsoft for standard path name it has itself problems of handling...