I am trying to write a CMakeLists.txt file for my STM32 project. I am using cmake files from this repo: https://github.com/ObKo/stm32-cmake. Building from command line works fine. I am doing it in that way:
cmake -C "..\STM32F207ZCTx_config.cmake" -DCMAKE_BUILD_TYPE=DEBUG -G "Eclipse CDT4 - Unix Makefiles" ..
make.exe -j4
In cache file I have some variables set:
set(CMAKE_MAKE_PROGRAM "D:/STM32Workbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.16.0.201807130628/tools/make/make.exe" CACHE STRING "stm32 make")
set(CMAKE_TOOLCHAIN_FILE "stm32-cmake/gcc_stm32.cmake" CACHE STRING "stm32 toolchain")
set(TOOLCHAIN_PREFIX "D:/STM32Workbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.16.0.201807130628/tools/compiler" CACHE STRING "arm toolchain path")
When I import created project to STM32 Workbench it generates a lot of errors "unresolved external" regarding stdint.h types (e.g. uint8_t, int32_t).
After some debugging this problem I realized that there are missing some defines which are used by stdint.h header. I checked out the compiler with this command:
arm-none-eabi-gcc.exe -dM -E out.h
And got the list of defines in arm-none-eabi-gcc:
#define __UINTMAX_TYPE__ long long unsigned int
#define __INT_FAST16_TYPE__ int
#define __INT_FAST64_TYPE__ long long int
#define __INT_FAST32_TYPE__ int
#define __UINT_LEAST16_TYPE__ short unsigned int
#define __SIZE_TYPE__ unsigned int
#define __INT_LEAST16_TYPE__ short int
... and much more
These defines are needed by stdint.h to create correct uint8_t and other types.
I can add manually these defines to Eclipse project, but I am wondering if there is method to add these defines to Eclipse project automagically from CMake?
Any help will be appreciated.
Problem was in STM32Workbench. Sources were excluded from build and from indexer.
To fix it - right mouse click on source, Properties, C/C++ General, Preprocessor Include Paths, uncheck Exclude resource from build.
Now the indexer is able to find all sources and all "unresolved external" errors are gone!
Related
Context
On Windows, using mingw32 and its x86_64 version. In order to use a third-party library (within Unity), I'am trying to build a wrapper library (dll) around the native one (to simplify the integration in Unity). I need this library to be 64bits.
The problem arises when linking against the created wrapper library in a test program: the program crash on a segfault, whereas the 32bits version runs just fine.
Procedure
I am using the 32 and 64bits version of the dll provided by the third-party (see Dependencies analysis on Picture) to compile wrapping libraries.
The wrapper library is simply wrapping some functions of the native library. The header is:
#include <stdlib.h>
#include <stdio.h>
#include "ATC3DG.h"
#pragma once
#ifdef __cplusplus
extern "C"
{
#endif
__declspec(dllexport) int trakSTAR_Init();
__declspec(dllexport) int trakSTAR_GetMeasurement(double S1_X[3], double S1_A[3], double *S1_T, unsigned short * S1_Q, double S2_X[3], double S2_A[3], double *S2_T, unsigned short * S2_Q, double S3_X[3], double S3_A[3], double *S3_T, unsigned short * S3_Q);
__declspec(dllexport) int trakSTAR_Close();
__declspec(dllexport) void trakSTAR_ErrorName(int errorcode, char *errortxt);
#ifdef __cplusplus
}
#endif
It is compiling fine for both the 32 and 64bits versions respectively with:
mingw32-gcc.exe -shared -Iinclude -o bin\Release\libWrapper.dll WrapperLib.c lib\win32\nativelib.lib
and
x86_64-w64-mingw32-gcc.exe -shared -Iinclude -o bin\Release\libWrapper64.dll WrapperLib.c lib\win64\nativelib64.lib
Then, compiling test codes linking this Wrapper dll using respectively:
mingw32-gcc.exe -I.\include -L.\test -llibWrapper .\test\MainTest.c -o test\Test32
and
x86_64-w64-mingw32-gcc.exe -g -I.\include -L.\test .\test\MainTest.c -o test\Test64 -llibWrapper64
also works fine and produce the two executables.
Problem
Now, while the 32bits version (Test32.exe) runs fine, the 64bits version produce a Segfault straight ahead (no even first console print). The necessary dll (native and wrapper for both 32 and 64bits version are in the execution folder).
When inspecting the two Wrapper dlls with Dependencies, I can't see any major difference (see picture).
What could be the cause of the problem with the 64bits library?
What are my options to understand what is going wrong and debug/inspect further?
Note: Compiling a test code against the native dll works fine for both in 32 and 64 bits.
Note2: Running GDB on the faulty test program does not provide more information.
I have an application that requires the use of glib and a 32 bit library supplied by a third party.
When I compile on 32 bit Ubuntu the application builds and runs successfully.
However when I try the same on 64 bit Ubuntu it fails to build because of the following error:
/usr/include/glib-2.0/glib/gtypes.h: In function ‘_GLIB_CHECKED_ADD_U64’:
/usr/include/glib-2.0/glib/gmacros.h:217:53: error: size of array ‘_GStaticAssertCompileTimeAssertion_0’ is negative
#define G_STATIC_ASSERT(expr) typedef char G_PASTE (_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1] G_GNUC_UNUSED
^
/usr/include/glib-2.0/glib/gmacros.h:214:47: note: in definition of macro ‘G_PASTE_ARGS’
#define G_PASTE_ARGS(identifier1,identifier2) identifier1 ## identifier2
^
/usr/include/glib-2.0/glib/gmacros.h:217:44: note: in expansion of macro ‘G_PASTE’
#define G_STATIC_ASSERT(expr) typedef char G_PASTE (_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1] G_GNUC_UNUSED
^
/usr/include/glib-2.0/glib/gtypes.h:422:3: note: in expansion of macro ‘G_STATIC_ASSERT’
G_STATIC_ASSERT(sizeof (unsigned long long) == sizeof (guint64));
^
Note: I have gcc-multilib and g++-multilib.
I also tried changing the defines inside /usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h from 8 to 4 with no success.
I also tried installing libglib2.0-dev:i686 but pkg config in cmake can not find glib. I am also using the appropriate -m32 flags for C, CXX and LD
Any help with this issue would be greatly appreciated.
No idea why glib wouldn't try to use int64_t instead of duplicating that. Seems silly to me. Maybe they do this on purpose to increase the chance of breaking if you do what you did, and try to compile 32-bit code using a 64-bit glib install.
To compile 32-bit apps, you need 32-bit library object files (.so). They will come with a glibconfig.h that has appropriate typedefs for -m32.
Installing libglib2.0-dev:i686 should be the right approach. I assume you eventually got that sorted out, so the app you're building finds the -I include paths and -L library paths for it.
I'm trying to compile HDF5 with MinGW's gcc 4.8.1 and CMake. I followed the instructions in the INSTALL_CMake documentation for Windows and read everything that I found on Google but I still get the following errors:
In file included from c:\mingw32-xy\include\fcntl.h:37:0,
from C:\Users\jicervan.NDC\Downloads\hdf5-1.8.13\hdf5-1.8.13\src\H5private.h:53,
from C:\Users\jicervan.NDC\Downloads\hdf5-1.8.13\hdf5-1.8.13\src\H5detect.c:57:
c:\mingw32-xy\include\io.h:301:1: error: unknown type name 'off64_t'
__CRT_INLINE off64_t lseek64 (int, off64_t, int);
^
c:\mingw32-xy\include\io.h:301:36: error: unknown type name 'off64_t'
__CRT_INLINE off64_t lseek64 (int, off64_t, int);
^
c:\mingw32-xy\include\io.h:302:1: error: unknown type name 'off64_t'
__CRT_INLINE off64_t lseek64 (int fd, off64_t offset, int whence) {
^
c:\mingw32-xy\include\io.h:302:39: error: unknown type name 'off64_t'
__CRT_INLINE off64_t lseek64 (int fd, off64_t offset, int whence) {
^
In file included from C:\Users\jicervan.NDC\Downloads\hdf5-1.8.13\hdf5-1.8.13\src\H5private.h:70:0,
from C:\Users\jicervan.NDC\Downloads\hdf5-1.8.13\hdf5-1.8.13\src\H5detect.c:57:
c:\mingw32-xy\include\unistd.h:65:20: error: unknown type name 'off_t'
int ftruncate(int, off_t);
The errors and warnings go on and on with a long list of warnings and undefines. Does anybody has any suggestions on how to solve this problem? Are there any other alternatives like using the Visual Studio binaries with MinGW maybe?
I finally got it working. My first attempt was to use configure and make according to the documentation in the /release_docs/INSTALL_MinGW.txt file, but it didn't work. I ended up using CMake. For documentation purposes, here's the procedure that I followed:
OPERATING SYSTEM: Windows 8.1 pro
COMPILER: CMake + MinGW gcc version 4.8.1
HDF5 VERSION: 1.8.13
STEPS:
Uncompress the hdf5-1.8.13.zip file.
Download CMake, and run the GUI.
Set the source folder to <hdf5-location>/hdf5-1.8.13 and the build folder to the folder where you want to place your Makefile.
Click on Configure, and a pop-up window will appear. Choose the MinGW Makefiles option as the generator for your project, and select the Use default native compilers option.
Once the list is populated with options, leave the default checkboxes selected, and also select BUILD_SHARED_LIBRARIES. Now the fun begins; compiling.
Locate the file H5pubconfig.h file in your HDF5 build folder and append the following lines:
// Define Windows 32
#ifndef H5_HAVE_WIN32_API
#ifdef WIN32 /* defined for all windows systems */
#define H5_HAVE_WIN32_API 1
#endif
#endif
// Define MinGW
#ifndef H5_HAVE_MINGW
#ifdef __MINGW32__ /*defined for all MinGW compilers */
#define H5_HAVE_MINGW 1
#endif
#endif
// Redefine _In_ and _Out_ to empty values
#define _In_
#define _Out_
// Redefine off_t and off64_t to match io.h and unistd.h
#define off_t _off_t
#define off64_t _off64_t
On the file io.hlocated in <MyFolder>/MinGW32/include/ change every instance of off64_t to _off64_t.
On the file unistd.hlocated in <MyFolder>/MinGW32/include/ change every instance of off_t to _off_t.
On the MinGW/MSYS command prompt, change directory to the location of your HDF5 Makefile (set on step 3).
Type the command Make and verify that it's compiled correctly.
Don't forget to include the flags -I/<your-HDF5-build-folder>/include/, -L/<your-HDF5-build-folder>/bin/, and -lhdf5 when you compile. Happy coding.
I'm learning how to compile a C trigger to load on PostgreSQL
When compile the "trigf.c" (in the example at http://www.postgresql.org/docs/9.3/interactive/trigger-example.html), I get some issue related to int64 error (c.h header)
#ifdef HAVE_LONG_INT_64
/* Plain "long int" fits, use it */
#ifndef HAVE_INT64
typedef long int int64;
#endif
#ifndef HAVE_UINT64
typedef unsigned long int uint64;
#endif
#elif defined(HAVE_LONG_LONG_INT_64)
/* We have working support for "long long int", use that */
#ifndef HAVE_INT64
typedef long long int int64;
#endif
#ifndef HAVE_UINT64
typedef unsigned long long int uint64;
#endif
#else
/* neither HAVE_LONG_INT_64 nor HAVE_LONG_LONG_INT_64 */
#error must have a working 64-bit integer datatype
#endif
-> [Error] #error must have a working 64-bit integer datatype
I don't know how to solve that problem, because clearly that there is a working 64 bit integer datatype that I can use.
Edit: I installed pgsql from binary. The C compiler I used for compile the C function file is MinGW GCC 4.7.2. (Using the path of Dev-cpp mingw gcc).
The command line is :
gcc -fpic -c "D:\trigf.c"
At the first time, it showed an error that in c.h: not found libintl.h (no such file or directory). Then I download the Lib Intl - 0.14.4 (library for native language support). The installation create a folder: C:\Program Files (x86)\GnuWin32.
I edited the environment variable CPATH, added C:\Program Files (x86)\GnuWin32\include folder, which contained libintl.h.
I ran the command again, and I met with the above error.
Update: It turns out not to be too hard to build extensions stand-alone with MSVC on Windows. I wrote a blog post detailing the process today.
The usual way to build extensions on Windows is to do it inside a working PostgreSQL build tree.
See these instructions on the PostgreSQL wiki.
You might be able to do it using MinGW and PGXS using a suitable Makefile instead.
Just trying to compile a standalone .c file is unlikely to work as there are a variety of paths and preprocessor definitions required.
It doesn't help that the current PostgreSQL packages don't include headers for public dependencies, which is really rather frustrating. You can safely compile without ENABLE_NLS defined even if the target PostgreSQL was built with ENABLE_NLS, though, and in this case libintl.h won't be required.
In Zend engine code for PHP I see lines like the below in the header files.
ZEND_API char *zend_strndup(const char *s, unsigned int length) ZEND_ATTRIBUTE_MALLOC;
I am new to professional C/C++ programming.
When I try to compile the c files in this package using gcc I get errors like
zend_alloc.h:55: error: expected =, ,, ;, asm or __attribute__ before char
I tried the command gcc -I./ -I../TSRM zend_language_*.c
It looks like gcc is complaing about ZEND_API. What does ZEND_API indicate? Can anyone help me figure out why this error happens?
SVN repository where the files are located.
These files are part of the PHP interpreter, and are not intended to be compiled separately from it. The configure script is supposed to define the ZEND_API macro to:
__attribute__ ((visibility("default")))
on systems that support it (e.g, GCC 4.0+), and to nothing on other compilers.
If you're just trying to build PHP, download the whole source bundle from php.net and use configure / make to build it. The build process is complex, and isn't intended to be obvious (or even possible) to run manually.