I've manage to make my Android Project work with a Visual Studio project. The only problem I have is when I compiled the c++ project the vsc++ compiler gives me this error:
android-ndk-r6b\platforms\android-9\arch-x86\usr\include\sys\cdefs.h(252): fatal error C1189: #error : "No function renaming possible"
If anyone had this problem before, any input would be nice.
The error happens when I include the .h that contains includes to those files
jni.h
android\log.h
EDIT :
I've looked at cdefs.h around line 252 :
245 | #if !defined(_STANDALONE) && !defined(_KERNEL)
246 | #ifdef __GNUC__
247 | #define __RENAME(x) ___RENAME(x)
248 | #else
249 | #ifdef __lint__
250 | #define __RENAME(x) __symbolrename(x)
251 | #else
252 | #error "No function renaming possible"
253 | #endif /* __lint__ */
254 | #endif /* __GNUC__ */
255 | #else /* _STANDALONE || _KERNEL */
256 | #define __RENAME(x) no renaming in kernel or standalone environment
257 | #endif
But honestly, I'm not sure what no renaming... means.
It seems that cdefs.h from $(NDKROOT)/.../includes somehow conflicts with the "default" cdefs.h from Visual Studio. Try to directly address the folder android in your includes and change #include <android/log.h> to #include <log.h> in your source file.
Regarding the jni.h I have no further clue...
There is #error pragma in the source code. Find this pragma and explore it's vicinity to check for any comments and / or #ifdef that might give you a hint on what's the problem.
I wanted to do the same thing, compile my Android code using Visual Studio. Even though Studio has no tablet emulator, I could at least run some of my logic under Studio, the parts that do not involve anything specific to Android (e.g. UI drawing). Why bother with such a limited dev environment? Well, simply because Studio has a very nice C++ editor and it compiles much more quickly then Android Studio/Gradle. And I have a lot of non-UI logic that I need to get right. So I'm dividing my work into a pre-step, which I think can be done more quickly with Studio.
For me, I copied over jni.h (from android NDK's x86 folder). And I made some tweaks...
#define __NDK_FPABI__
//#include <sys/cdefs.h>
...
#define JNIEXPORT //gdh: __attribute__ ((visibility ("default")))
That made Studio happy.
Related
I've seen the related question regarding "_T()" not found. I have a console app. The "Debug" version of the console app compiles and runs fine. When I try to compile it as a "Release" version I first get hundreds of _T() Not Found. I tried adding #include <tchar.h> to pch.h which was completely ineffective. Based on what I found in the question about undefined _T() I read, I added the text
#ifdef _UNICODE
#define _T(x) L ## x
#else /* _UNICODE */
#define _T(x) x
#endif /* _UNICODE */
#include <tchar.h>
#include "framework.h"
to pch.h before #include "framework.h". The compiler noticed but now complained as follows:
Error C2039 '_tcscpy_s': is not a member of '`global namespace'' Anon C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29333\atlmfc\include\atlchecked.h 111
plus a few hundred other similar messages.
This is not the first time this has happened. Every project I've tried to build with VS2019 eventually has this happen to it. And, this happens compiling a completely pristine "pch.h" that I had not (initially) modified at all before this error occurred.
I've already tried deleting VS and reinstalling it. My OS is Windows 10 (64-bit)
The list of Include directories is the same for both the Debug and Release configurations.
I feel that this must be related to something in the way Visual Studio is configured, but mostly I need help fixing it. The compiler seems to be getting tangled up in its own header files. What can I do to analyze/fix this?
ADDENDUM:
Just since I started writing this question I have gone back to my project and tried the Debug version again. Now it is getting the same errors. And I made no changes since the previous time I built it earlier today.
is it possible to port Eigen, a C++ template library for linear algebra, to IAR workbench for ARM. I have tried to do this while but am getting following compile errors
Error[Pe337]: linkage specification is incompatible with previous "__nounwind __iar_builtin_get_CONTROL" (declared at line 58 of "C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.3\arm\inc\c\iccarm_builtin.h") C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.3\arm\CMSIS\Core\Include\cmsis_gcc.h 151
This is the entire error I get when I use the preprocessors
__GNUC__
__arm__
if I dont use these preprocessors I get an error from a #error preprocessor
from the Eigen file Macros.h
"error Please tell me what is the equivalent of attribute((aligned(n))) for your compiler"
#if (defined __CUDACC__)
#define EIGEN_ALIGN_TO_BOUNDARY(n) __align__(n)
#elif EIGEN_COMP_GNUC || EIGEN_COMP_PGI || EIGEN_COMP_IBM || EIGEN_COMP_ARM
#define EIGEN_ALIGN_TO_BOUNDARY(n) __attribute__((aligned(n)))
#elif EIGEN_COMP_MSVC
#define EIGEN_ALIGN_TO_BOUNDARY(n) __declspec(align(n))
#elif EIGEN_COMP_SUNCC
// FIXME not sure about this one:
#define EIGEN_ALIGN_TO_BOUNDARY(n) __attribute__((aligned(n)))
#else
//#define EIGEN_ALIGN_TO_BOUNDARY(n) __declspec(align(n))
#error Please tell me what is the equivalent of __attribute__((aligned(n))) for your compiler
#endif
I have it working for visual c++ but not IAR. All includes are added.
These errors change based on the preprocessors I use to try to configure Eigen. Is it possible to use Eigen with IAR?
To add to #chtz answer, here's how I got the EIGEN_ALIGN_TO_BOUNDARY macro to work with IAR, in a way that is consistent with the eigen library:
1: add this to top of Macros.h to identify the IAR ARM compiler
/// \internal EIGEN_COMP_ICCARM set to 1 if the compiler is IAR eWARM
#if defined(__ICCARM__)
#define EIGEN_COMP_ICCARM 1
#else
#define EIGEN_COMP_ICCARM 0
#endif
2: add this case to where EIGEN_ALIGN_TO_BOUNDARY(n) is defined in Macros.h
#elif EIGEN_COMP_ICCARM
#define IAR_STRINGIFY(a) #a
#define IAR_ALIGN_STR(n) IAR_STRINGIFY(data_alignment=n)
#define EIGEN_ALIGN_TO_BOUNDARY(n) _Pragma(IAR_ALIGN_STR(n))
EIGEN_ALIGN_TO_BOUNDARY(n) should now correctly expand to _Pragma("data_alignment=n")
I have now gotten it to build and run. Thank you #chtz for the EIGEN_DONT_ALIGN macro suggestion. This is how I did it. I am unsure however what repercussions this has on the library itself, as in what features this may take away. I did this:
include the directory to where you installed Eigen as the additional includes.
in lines 86, 105, 125, 145 in file DenseStorage.h change the lines
EIGEN_ALIGN_TO_BOUNDARY(8) T array[Size];
to their respective
_Pragma("data_alignment=8") T array[Size];
(pay attention to the number)
in Macros.h , line 665 , comment out the "#error Please tell me what is the"
finally, define the macro EIGEN_DONT_ALIGN in the preprocessor settings.
This is what worked for Eigen 3.3.7
Was just testing a simple hello world mqtt program on my mbed board and I keep getting this error:
Error: Cannot open source input file "fsl_enet.h": No such file or directory in "EthernetInterface/lwip-eth/arch/TARGET_Freescale/k64f_emac_config.h", Line: 33, Col: 23.
Error
I even tried fixing the error by doing what the compiler suggests by adding mbed-dev library, but the error is still there.
#ifndef K64F_EMAC_CONFIG_H__
#define K64F_EMAC_CONFIG_H__
#include "fsl_enet.h"
#define ENET_RX_RING_LEN (16)
#define ENET_TX_RING_LEN (8)
#define ENET_ETH_MAX_FLEN (1522) // recommended size for a VLAN frame
#if defined(__cplusplus)
extern "C" {
#endif
int phy_link_status(void);
#if defined(__cplusplus)
}
#endif
#endif // #define K64F_EMAC_CONFIG_H__
Looks like the EthernetLibrary was broken recently for K64F. If you import https://developer.mbed.org/teams/mqtt/code/HelloMQTT/, and choose NOT to update libraries it compiles fine for K64F.
thanks for reporting. The tools scripts were not updated (+ mbed lib), which caused this breakage in the ethernet library. Because ethernet lib requires some new KSDK files which are not yet available.
The next mbed SDK release is tomorrow, which should fix this. In the meantime, we will look at this, to find better solution - for instance to move the target code in the lwip/arch into HAL. I'll have a look today.
Good day everyone,
I recently upgraded to Visual Studio 2012 and I'm loving the improved C++11 support and the dark theme. However, I'm trying to write a program that runs on Windows XP and higher, and I'm running into some strange issue.
The first time I tried to run my program on a XP virtual machine I got the "This is not a valid Win32 program" error message. Some googling revealed that I needed to apply Update 1 to VS to be able to target Windows XP. I searched for that but found Update 2 instead. I applied that and set the platform toolset to v110_xp, then recompiled my program and tried to run it again. This time I got no error message, but upon trying to start the program I hear XP's error sound (the same one you hear when calling MessageBox with MB_ICONERROR) and then nothing else happens. No mention of anything in Windows XP's Event viewer either.
I thought perhaps Update 2 messed something else up, so I completely uninstalled VS2012, including all the MS SQL crap it leaves behind, reinstalled it and only applied Update 1. Compiled my code with the XP toolset again, but the same thing happens. An error sound but no message when trying to start my program.
Some more googling revealed that I had to define PSAPI_VERSION to 1 to target the pre Windows 7 version of the Process API so I did that, but the issue remains.
I began to think something was wrong with my code so I made the most basic Hello World program, but it STILL has the same issue. So I'm out of ideas now.
Here is the code I used to compile the Hello World program:
main.cpp:
#include "winapi.h"
int WINAPI wWinMain(HINSTANCE inst, HINSTANCE prev, wchar_t *cmdline, int show)
{
MessageBox(HWND_DESKTOP, L"Let's hope this works in Windows XP...", L"Testing 1... 2... 3...", MB_ICONERROR);
return 0;
}
winapi.h:
#ifndef WINAPI_H_INCLUDED
#define WINAPI_H_INCLUDED
#ifdef _WIN32
// WINDOWS DEFINES /////////////////////////////////////////////////////////////
// If this is not a console program, let the linker include a manifest to
// enable visual styles.
#ifndef _CONSOLE
# pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")
#endif // _CONSOLE
// Shorten compile time by only including the most basic Windows definitions.
#define WIN32_LEAN_AND_MEAN
#define NOGDICAPMASKS // CC_*, LC_*, PC_*, CP_*, TC_*, RC_
#define NOSYSMETRICS // SM_*
#define NOICONS // IDI_*
#define NOKEYSTATES // MK_*
#define NOSYSCOMMANDS // SC_*
#define NORASTEROPS // Binary and Tertiary raster ops
#define OEMRESOURCE // OEM Resource values (OCR_NORMAL and related constants)
#define NOATOM // Atom Manager routines
#define NOCLIPBOARD // Clipboard routines
#define NODRAWTEXT // DrawText() and DT_*
#define NOKERNEL // All KERNEL defines and routines
#define NONLS // All NLS defines and routines
#define NOMEMMGR // GMEM_*, LMEM_*, GHND, LHND, associated routines
#define NOMETAFILE // typedef METAFILEPICT
#define NOMINMAX // Macros min(a,b) and max(a,b)
#define NOOPENFILE // OpenFile(), OemToAnsi, AnsiToOem, and OF_*
#define NOSERVICE // All Service Controller routines, SERVICE_ equates, etc.
#define NOSOUND // Sound driver routines
#define NOTEXTMETRIC // typedef TEXTMETRIC and associated routines
#define NOWH // SetWindowsHook and WH_*
#define NOCOMM // COMM driver routines
#define NOKANJI // Kanji support stuff.
#define NOHELP // Help engine interface.
#define NOPROFILER // Profiler interface.
#define NODEFERWINDOWPOS // DeferWindowPos routines
#define NOMCX // Modem Configuration Extensions
// Enable strict typechecking on Windows types like HANDLE, HWND and HDC.
#define STRICT
// Enable targetting of pre-Win7 Process API functions when compiling on
// VS2012 or higher.
#if _MSC_VER >= 1700
# define PSAPI_VERSION 1
#endif // _MSC_VER
// Specify the minimum versions of Windows and Internet Explorer supported
// by this code.
#define NTDDI_VERSION NTDDI_WIN2K
#define _WIN32_WINNT _WIN32_WINNT_WIN2K
#define WINVER _WIN32_WINNT_WIN2K
#define _WIN32_IE _WIN32_IE_IE50
// WINDOWS INCLUDES ////////////////////////////////////////////////////////////
#include <Windows.h>
#else // _WIN32
// OTHER OS ////////////////////////////////////////////////////////////////////
#error This software has been written with Visual C++ in mind.
////////////////////////////////////////////////////////////////////////////////
#endif // _WIN32
#endif // WINAPI_H_INCLUDED
As I've said, I compile this code by targeting the v110_xp toolset, and I statically link the CRT with /MD using the project settings window. I compiled it as x86 code and it runs fine on my Windows 7 x64 machine. Running dumpbin on the resulting executable confirms that's it's compiled as 32 bit code for operating system version 5.01 and the Windows GUI subsystem.
To make this as complete as possible, here are the executable's imports:
D:\Projects\xptest\Release>dumpbin /imports xptest.exe
Microsoft (R) COFF/PE Dumper Version 11.00.51106.1
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file xptest.exe
File Type: EXECUTABLE IMAGE
Section contains the following imports:
USER32.dll
4070FC Import Address Table
40B19C Import Name Table
0 time date stamp
0 Index of first forwarder reference
215 MessageBoxW
KERNEL32.dll
407000 Import Address Table
40B0A0 Import Name Table
0 time date stamp
0 Index of first forwarder reference
218 GetModuleHandleW
8F CreateFileW
187 GetCommandLineW
300 IsDebuggerPresent
304 IsProcessorFeaturePresent
202 GetLastError
473 SetLastError
2EF InterlockedIncrement
2EB InterlockedDecrement
1C5 GetCurrentThreadId
EA EncodePointer
CA DecodePointer
119 ExitProcess
217 GetModuleHandleExW
245 GetProcAddress
367 MultiByteToWideChar
264 GetStdHandle
525 WriteFile
214 GetModuleFileNameW
24A GetProcessHeap
1F3 GetFileType
2E3 InitializeCriticalSectionAndSpinCount
D1 DeleteCriticalSection
263 GetStartupInfoW
3A7 QueryPerformanceCounter
1C1 GetCurrentProcessId
279 GetSystemTimeAsFileTime
1DA GetEnvironmentStringsW
161 FreeEnvironmentStringsW
4D3 UnhandledExceptionFilter
4A5 SetUnhandledExceptionFilter
1C0 GetCurrentProcess
4C0 TerminateProcess
4C5 TlsAlloc
4C7 TlsGetValue
4C8 TlsSetValue
4C6 TlsFree
EE EnterCriticalSection
339 LeaveCriticalSection
2CF HeapFree
4B2 Sleep
30A IsValidCodePage
168 GetACP
237 GetOEMCP
172 GetCPInfo
33E LoadLibraryExW
38A OutputDebugStringW
33F LoadLibraryW
418 RtlUnwind
2CB HeapAlloc
2D2 HeapReAlloc
511 WideCharToMultiByte
269 GetStringTypeW
2D4 HeapSize
32D LCMapStringW
157 FlushFileBuffers
19A GetConsoleCP
1AC GetConsoleMode
487 SetStdHandle
467 SetFilePointerEx
524 WriteConsoleW
52 CloseHandle
Summary
3000 .data
5000 .rdata
3000 .reloc
1000 .rsrc
6000 .text
As I said, I'm completely out of ideas here... I've tried everything I can think of. Any helpful comment would be very much appreciated!
Regards,
Gerard
Before you #include any of the Windows headers, make sure you have the following #define's:
#ifndef WINVER
#define WINVER 0x0501
#endif
#ifndef _WIN32_WINNT // Specifies that the minimum required platform is Windows XP.
#define _WIN32_WINNT 0x0501
#endif
It's all explained on MSDN here, if you want to see other alternatives.
I am trying to migrate existing c++ 32 code to 64 code on windows7 with visual studio 2010.i never did 64bit compilation before. with the help of internet references i did the setup for 64 bit compilation. like VS2010 with 64 bit compiler etc and other configuration changes.
In the preprocessor i removed WIN32 and added WIN64. i have some other pre-processors like OS_WIN_32 and some other which are specific in my code.
In the code wherever WIN32 was getting used i added extra condition as || WIN64 this is just to ensure that application should get compiled with win32 as well as win64.
When i am trying to compile the code i am getting the compilation error saying
fatal error C1189: #error : Only one of the WIN32 and WIN64 symbols should be defined
this error is coming from the local code where we have a check whether both WIN32 and WIN64 are defined. that code is as shown below.
#if defined WIN32 && defined WIN64
# error Only one of the WIN32 and WIN64 symbols should be defined
#endif
in VS2010 if macros are not enabled then the code inside the macro gets greyed out. in my code also the above error is greyed out. but still i am getting that error.
The code where i added WIN64 is including windows.h. for reference givine it below.
#if defined WIN32 || defined WIN64
#include <windows.h>
#include <process.h>
#endif
So my question is why i am getting this error? shouldnt we add windows.h for 64bit compilation.? i tried by commenting this inclusion but i am getting other errors wrt HANDLE which are used in the code.
If i go to WIN32 definition VS2010 is pointing to a definition in windef.h file. This file is present in Microsoft SDKs\windows\v7.0A\include folder i.e. not my local code.
for referance that definition is given below.
#ifndef WIN32
#define WIN32
#endif
So i want to know why compiler is getting both pre-processors WIN32 and WIN64.
Thanks in advance for your help.
You shouldn't define either yourself. The macro's that should be used to check this are
_WIN32 // always defined for Windows apps
_WIN64 // only defined for x64 compilation
These are defined by the compiler (see here).
Often, the IDE adds the unprefixed macros to the commandline to not let legacy projects which use the non-documented unprefixed versions fail to build. The fact that they work is not a reason to use them, when documented alternatives are present.
It boils down to this:
#ifdef _WIN32
// We're on Windows, yay!
#ifdef _WIN64
// We're on x64! Yay!
#else // _WIN64
// We're on x86 (or perhaps IA64, but that one doesn't matter anymore). Yay!
#endif // _WIN64
#else // _WIN32
// We're not on Windows, maybe WindowsCE or WindowsPhone stuff, otherwise some other platform
#endif