Prolog: I am using STM32 CubeIDE to develop embedded application for STM32 Microcontrollers, like the F1 Series, the F4 Series, the G0 series and some others with C.
What happened:
Today morning the automatic update feature suggested me to update to STM CubeID Version 1.9.0 and i accepted. After the updater had finished, I opened my current project and changed one variable in a typedef struct and hit the "build" button. All of a sudden the linker reported lots of "multiple definition" and "first defined here" errors. This project was compiling perfectly without any issues yesterday with CubeIDE Version 1.8
After searching an hour or two, where I could have missed a semicolon or something in that direction, which could mess up the whole code, I came to the conclusion, that the upgrade from CubeIDE 1.8.0 to 1.9.0 might be the root cause for this errors.
So I decided to uninstall CubeIDE 1.9.0 and reinstall Version 1.8.0, rolled back the project to the last working version from yesterday evening (compiled with 1.8.0), made the same changes, and Voila! - anything worked well again.
For me it looks like STM messed something up with the linker. Can anyone confirm this behavior, or was only me affected?
This is due to compiler update. From the release notes of STM32CubeIDE:
GCC 10 support by default
From GCC 10 release notes:
GCC now defaults to -fno-common. As a result, global variable accesses
are more efficient on various targets. In C, global variables with
multiple tentative definitions now result in linker errors. With
-fcommon such definitions are silently merged during linking.
This page has futher explanation and a workaround:
A common mistake in C is omitting extern when declaring a global
variable in a header file. If the header is included by several files
it results in multiple definitions of the same variable. In previous
GCC versions this error is ignored. GCC 10 defaults to -fno-common,
which means a linker error will now be reported. To fix this, use
extern in header files when declaring global variables, and ensure
each global is defined in exactly one C file. If tentative definitions
of particular variables need to be placed in a common block,
__attribute__((__common__)) can be used to force that behavior even in code compiled without -fcommon. As a workaround, legacy C code where
all tentative definitions should be placed into a common block can be
compiled with -fcommon.
In Project > Properties > C/C++ build > Settings > gcc compiler > miscellaneous > Other flags, try adding -fcommon as shown below to avoid the 1k+ linker error issue with STM CubeIDE 1.9.
Related
I am having problems getting VS Code’s Intellisense for C++ to work.
I am using Windows 10, g++ and gdb. I have installed the extensions C/C++ for Visual Studio Code and the C/C++ Extension Pack.
If I write msg, for example, main, mitl, module and mutable will appear, but that’s it - essentially, I get a partial list. The subsequent ‘s’ and ‘g’ of msg produce nothing nor does the normally triggering dot or full stop after msg (msg.) Even the simplest printf produces only private, protected, and pragma, but printf is never an option.
I have uninstalled and reinstalled VS Code to no avail. I have also deleted all extensions and reinstalled them as per Completely uninstall VS Code extensions, again, without success. A simple piece of code compiled without issue, but when I changed the source code file for something a little more complicated the following messages appeared.
Please update #include errors detected. Please update your includePAth. IntelliSense features fro this translation unit(C/NOTES/Programming/VSCODE/helloworld.cp) will be provided by the tag parser
*[2/1/2023, 10:54:07 PM] For C++ source files, IntelliSenseMode was changed from "windows-gcc-x64" to "windows-msvc-x64" based on compiler args and querying compilerPath: "C:\ghcup\ghc\9.2.5\mingw\bin\gcc.exe"
[2/1/2023, 10:54:07 PM] For C source files, IntelliSenseMode was changed from "windows-gcc-x64" to "windows-msvc-x64" based on compiler args and querying compilerPath: "C:\ghcup\ghc\9.2.5\mingw\bin\gcc.exe"*
Is it a case of IntelliSense looking at the C compiler (gcc.exe) and not the C++ compiler (g++.exe) and if so how can I change that?
I am playing around with a project for a STM32 µC. I use the SW4STM32 workbench and CubeMX on a Mac OSX system. My project itself is fine, everything compiles accordingly and behaves on the device as expected.
For a further learning purpose, I would like to implement unit tests using the CppuUTest framework. I have set up everything, got my test directories and a makefile to configure the MakefileWorker variables in place.
However, when executing the Makefile, I keep getting the error:
error:
register 'sp' unsuitable for global register variables on this target
This error originates from the file syscalls.c (which is a file generated by CubeMX). The line causing the error is:
register char * stack_ptr asm("sp");
After doing my research, it seems like there is no easy workaround to solve the issue. The source code is generated by Cube and works fine when compiling with the sw4stm32 toolchain (which is using a mcu gcc compiler).
However, the CppUTest toolchain is using clang, which cannot cope with global register variables (as the error says aswell).
My question here ist:
Has anyone of you had the same error yet or more experience in setting up CppUTest for a sw4stm32 project on an OSx system? Does anyone have an idea how to solve this problem?
If you need more information / code snippets from me, I will gladly share it.
Thank you very much guys! Any help would be highly appreciated :-)
Cheers,
Tobi
I have installed pycparser that parses C code.
Using pycparser I want to parse an open source project, namely PostgreSQL(version-11.0). I have build it using Visual Studio Express 2017 compiler suite. However, during compilation it cannot find some header files, namely windows.h and winsock2.h.
While looking at the directory structure of the build PostgreSQL, I find that it does not have these header files. How to fix this issue?
Also a strange error occurred as:
postgresql/src/include/c.h:363:2: error: #error must have a working
64-bit integer datatype
Note: I am using Windows 10 64-bit platform and postgresql-11.0
The steps are as follows:
I downloaded visual studio 2017, Windows-10 SDK, Active Perl as described in the steps to build from source in PostgreSQL.
After this I open the developer command prompt of Visual Studio and navigate to the folder postgresql-11.0/src/tools/msvc
Use command "build" to build postgresql. The build process was successful, but still windows.h and winsock2.h was not found in directory structure of PostgreSQL.
I don't know pycparser, but your problem probably has two aspects to it:
You didn't give pycparser the correct list of include directories. The header files you mention are not part of PostgreSQL.
Maybe you can get the list from the environment of the Visual Studio prompt. I don't have a Windows here to verify that.
The error message means that neither HAVE_LONG_INT_64 nor HAVE_LONG_LONG_INT_64 are defined.
Now pg_config.h.win32, which is copied to pg_config.h during the MSVC install process, has the following:
#if (_MSC_VER > 1200)
#define HAVE_LONG_LONG_INT_64 1
#endif
Since you are not using MSVC, you probable don't have _MSC_VER set, which causes the error.
You could define _MSC_VER and see if you get to build then.
Essentially you are in a tight spot here, because pycparser is not a supported build procedure, so you'll have to dig into the source and fix things as you go. Without an understanding of the PostgreSQL source and the build process, you probably won't get far.
I installed the latest official iphone sdk and now my personal project is getting the same compiler error in UIView.h as described in this question:
Syntax error before '^' token
syntax error before '^' token
The solution is apparently to change compiler settings to use GCC 4.2 or LLVM.
I've tried using every compiler setting available in Xcode that but am still getting the errors.
Is there something else I should be doing to support the (^) block syntax in my project. The project was building fine with the previous official sdk release (pre OS4)
Another strange detail, I only get the error in debug config, not release.
I tried comparing the build settings between debug and release but didnt see any major differences. Where there were differences I tried setting the debug config to use the release config values but still getting those errors.
thanks in advance for any help
ok so I just found my problem.
I was changing build settings by right click -> Get Info on the project but I should have been doing it on the target (which was still using GCC 4.0 even though the project was set to 4.2)
Make sure you have the right configuration or configurations picked when you change compile settings. It's easy to overlook this, for example: picking the Release build when you meant the Debug, or vice versa; or by using other custom build configurations.
Since upgrading to Xcode 3.2.1, I've experienced a strange issue that has really killed my workflow. The issue only exhibits itself under my own user account (the same project opened by a different user works fine). Therefore, the heart of this question is, "what does Xcode load from the user directory that could conceivably cause this issue?"
(System: Snow Leopard 10.6.1; Xcode 3.2.1 w/ iPhone SDK 3.1.2)
Symptoms:
Code completion only works on symbols of the current class or already referenced in the class. Virtually useless.
Document/reference lookups (i.e. option-double-clicking on an identifier or symbol returns this strange result): "Documentation not found for the symbol 'symbol name'. Click here to view symbol declaration."
Like I said, since other users are experiencing normal behavior in Xcode, this must be due to something only loaded for my user account. I've already eliminated ~/Library/Preferences/com.apple.Xcode.plist, ~/Application Support/Developer,~/Application Support/Xcode`.
The only thing I've recently installed is mogenerator (the defunct xmod integration may have killed it, but it doesn't install anything to the user directory)
Update: 10/26/09
This one is really starting to kill me. I did a fresh OS X install, followed by an Xcode 3.2 install from the Leopard disc, followed by an iPhone SDK install from the ADC site, and this started occurring again within 30 minutes of my having started working. I'm at an utter loss. The error is most obvious when option-double-clicking on a symbol (say, the NSString class) and instead of getting the documentation snippet, a message "Cannot determine the symbol for the current selection." appears.
Update: 10/26/09 #2
I just tried creating a fresh project, and that project's symbols are appearing fine. So the issue is apparently local to my project. Hopefully that's a better start. To demonstrate what I'm talking about, here's a screen of the issue manifesting itself with respect to documentation:
Have you tried rebuilding your CodeSense index? Project > Edit Project Settings > General >
alt text http://idisk.mac.com/cdespinosa/Public/Rebuild.png
After doing that, check Console.app to see if Xcode issued any warnings. It's possible that some of your source code causes the indexer to stop, and you don't end up with a valid index. Filing a bug with Apple and providing the source, if possible, would help Apple fix problems like this.
This is the first thing I'd try:
alt text http://img.skitch.com/20091026-ek3id5s121wqrsiu8apwm4qgir.png
Wait until it doesn't say "Getting" anywhere anymore before doing anything documentation related.
Given the clues from the console:
10/26/09 7:21:58 PM Xcode[19072] Warning: Couldn't discover the 'clang' compiler's built-in search paths and preprocessor definitions for language dialect 'objective-c'. This may lead to indexing issues.
Compiler: /Developer/usr/bin/clang
Reason: clang version 1.0.1 (http://llvm.org/svn/llvm-project/cfe/tags/Apple/clang-24 exported)
Target: x86_64-apple-darwin10
clang: warning: not using the clang compiler for the 'armv6' architecture
I'm going to say that you tried to configure an iPhone Device build to use the Clang compiler, which is not yet supported for compilation. (It works for static analysis, but not for building).
Find the Compiler Version build setting and set it back to gcc 4.2.
I had this same problem and I was able to workaround it by:
Setting the target to be the iPhone simulator
Quit and relaunch Xcode
Rebuild the index
Clean and rebuild the simulator target
Maybe it's a bug in Xcode with iPhone device selected when a project is first opened.