I am using VS2015 RC and the cross platform C++ Shared Library Template. Under the .Shared code I added a simple point class. When it created the class, in the .cpp it included pch.h or a pre-compiled header that is only available in .android and not .ios. That threw an error, so I just removed that so I didn't get errors and figured I could include my STL items as needed. Hopefully that is the correct route for that.
Anyway my main issue is
In the Point.cpp file I need to use sqrt so I need to include math.h:
#include <math.h>
I have tried including it several different ways (cmath...), but no matter what I get the error myprojectname.iOS: Error: cannot open source file "math.h".
According to the setting sin the project properties for .iOS Use STL is LLVM C== standard library with C++11 support (libc++).
I am not sure how to add the correct include directory for iOS this is the first time I've written a cross platform library and done any iOS development.
From what I've read all the STL classes are available on both platforms. Any help with any of it would be great. Too bad there isn't a full tutorial on making a simple math library that you then use in an Android and ios app.
Related
The Android app I am working on is completely written in C++. I need to integrate it with a static library that also is written in C++. There is no dependency on STL in any of the projects.
The static library uses cmake to build. Unfortunately, the app is based on an old AOSP version of Android NDK and has no support for cmake.
I also have a newer version of Android NDK in a different directory. This version does support cmake toolchains.
I am thinking I will build the static library against the new NDK and use it in my main project. The ABI is the same for both the projects - armv7a.
I have tested this logic with a sample code. It seems to work. I am able to invoke methods in the static library from my main app.
Also, there are no name-mangling issues.
The question I have is if there is any issue I am overlooking.
I am thinking it should not matter that the compilers used to build the sources are different. As long as they are producing arm-compatible code, I should be able to able to integrate them.
As a matter of fact, another library that I am using, gstreamer, is available for download as pre-built binaries at https://gstreamer.freedesktop.org/data/pkg/android.
Please advice.
For those interested, mixing NDKs doesn't seem to be an issue as long as you follow certain guidelines. Some of them are listed at https://developer.android.com/ndk/guides/cpp-support.
Essentially, there is no problem if your project is 'C' based. However, if you are using C++, you must not use STL.
I have managed to build part of my code with two NDKs and I am not seeing any link time or runtime errors.
I am trying to make a C++ application with wxWidgets for raspberry on Visual studio.
I created a blink project from the templates and I only added the library wx.h in order to test the code and when I try to compile it fails because it doesn't find the library.
By the way, the blink project itself works fine. It only fails when I add the wx.h library.
#include <wx-3.1\wx\wx.h>
It's odd, because whe I open the file it has the right path.
Even intellisense detects the path correctly.
But I can't figure out what is causing the error.
I configured a remote connection to the raspberry:
And these are the errors displayed:
There is not enough information to answer your question, e.g. you don't explain how do you build your project at all (e.g. do you use CMake?), but a couple of observations that may be helpful:
wxWidgets headers are included as <wx/wx.h>, you definitely should not have the wx-3.1 component and you must use slashes and not backslashes.
You have to provide the compiler with the appropriate options, which usually happens by running wx-config --cxxflags under Unix systems (which may be hidden from you if you use CMake FindwxWidgets module which uses wx-config internally).
I am trying to implement the ProtectedData Class in C++ but are having some issues with compilation. My first error comes from not being able to use #using <System.Security.dll>. The error is that IntelliSense: "#using" requires C++/CLI to be enabled, however when I go into my project settings and set the common language runtime support to /clr, In my project I do not see my sytax errors getting corrected anymore. I then thought ok this must have fixed all the issues but then i go to compile and then I receive and error that '/clr' and '/Gm' command-line options are incompatible. So i go to look at this and I am not sure what to put to correct my problem. Is there any way I can use the ProtectedData Class without having to go through the different config process?
I am using Microsoft Visual C++ 2010 Express.
The link to the ProtectedData Class is here: http://msdn.microsoft.com/en-us/library/system.security.cryptography.protecteddata.aspx?cs-save-lang=1&cs-lang=cpp#code-snippet-2
Thank you for your time.
You could use Microsoft Visual C# 2010 Express instead. C++/CLI is best used only as a .NET/native bridging framework, and only when other methods of interoperation aren't suitable (such P/Invoke).
If you decide to use C++, you do need to use the /CLR switch. Although you can tweak a C++ project into a C++/CLI project, it's best to start fresh with the one of the CLR project templates.
Two ways to indicate that you want to use an external .NET assembly:
specify it with #using, or
add it to the References section of the project properties
Since you mentioned Intellisense, you'll find that it's not supported in C++/CLI code.
I am working on a C++/CLI project with VS 2012 in Dynamic Library (.dll) and x64 mode.
If I switch the mode to Static Library, I get the error below.
Error 1 error C1107: could not find assembly 'mscorlib.dll': please specify the assembly search path using /AI or by setting the LIBPATH environment variable C:\Depot\Main\Current\Sln\ALibraryProject\Stdafx.cpp 1 1 ALibraryProject
I tried removing the reference to the mscorlib.dll then adding it again from:
Project > Properties > General > Common Properties
But that didn't help. As I know that VS handles the reference to the .NET assemblies, I don't want to add a disk file reference to it as it seems illogical! Did anybody face this before?
I had the same problem when converting my solution from the VS2010 compiler to VS2013 compiler.
I resolved it by changing the project settings (for the project containing the managed .cpp file that was throwing this error) as follows: In Project Settings | C/C++ | General | Additional #using Directories I added the macro $(FrameworkPathOverride). This resolves to the reference assembly directory for the version of .NET that you're targeting, which in my case is C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5.1
If I switch the mode to Static Library
This is not the typical error you get when you try to build a static library with /clr in effect. I'd have to assume you've been tinkering with project settings to get rid of the inscrutable linker errors you get when you try to do this.
Core issue is that the C++/CLI build system doesn't support static libraries that contain MSIL. Managed code doesn't use a linker, binding happens at runtime. Which makes the essential difference between static libraries and DLLs disappear. So Microsoft decided to not support it because it didn't make much sense to implement it. Unfortunately they don't yell loud enough when you try to do it anyway, the linker errors you get don't give enough of a hint what you did wrong. Workarounds, like merging with ILMerge don't work either, it cannot deal with mixed-mode assemblies. Merging the native code sections and their associated relocation table entries is very untrivial.
Keep in mind that it is fine to link native static libraries. A typical C++/CLI project has only the ref class wrappers that need to be built with /clr in effect. You can glue any amount of native code from libraries into the final assembly.
I'm forced to theorize about the actual compile error, too many programmers get this error for another reason that doesn't have anything to do with building static libraries and they are harassing me in the comments.
Do beware that targeting a different version of .NET than the one you have installed on your machine is quite a hazardous affair, particularly so if you want to target 4.0 and you have 4.5.x installed. The key element in your .vcxproj file is the <TargetFrameworkVersion>. This will be missing if you started the project targeting an old .NET version, you have to insert it yourself. The IDE also doesn't support changing it if it is present, again edit by hand.
Which is enough to coax MSBuild into generating the proper compile command. You can verify if that panned-out well, look in the *.tlog subdirectory of the Debug build directory for your project. The cl.command.1.tlog file shows the options that were passed to the compiler. It should contain:
/AI"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0"
/FU"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\mscorlib.dll"
Note the subdirectory, very important that it matches your intended .NET target. v4.0 in this example. And very, very important that it does not point to c:\windows\microsoft.net, the legacy location for reference assemblies.
I have the same problem. Having a dll doesn't work, as I need to provide a native C++ wrapper for a .net object so it can fulfil a natice c++ interface - I can't use .net in a dll interface - this gives a compile error
This worked as a static library in VS 2010 (with .net 4)
Some of my executables and dlls which also have some code with /clr. They don't have an issue. I'm not trying to make a net Lbirary.
I solved it by removing dependency in old and not updated mixed lib, which was also configured only in Debug configuration, and as result, it started to get the same error as yours after I changed some code.
It was not simple to find it, because error is not clear, and the dependency was set up via "Additional Dependencies" in project settings.
Open visual studio and unload your project then Go to the project folder and open file .vcxproj . Search for tag "targetFrameworkVersion"
(if not present it means ur project is not using dot net frameworks.so no requirement of change)
Change it to required version
Save the file.
And now reload the project .
I am reading up about linking native libraries into MonoTouch, specifically this documentation:
http://monotouch.net/Documentation/Linking_Native_Libraries
Here it describes linking to C libraries. Is it also possible to link to C++ libraries from MonoTouch? I am very new to MonoTouch and particularly to importing libraries, so I would appreciate any advice about problems I may face trying to import a C++ library, if this is indeed possible. Would wrapping the C++ library in an Objective-C library and then using btouch to import this be a good route to take? Or is there an easier approach? Bearing in mind that my knowledge of C++ (and Objective-C for that matter) can best be described as "dangerous". ;)
The reason that I ask is that I am needing to make use of a C++ API from Sybase to access their Ultralite database. I have managed to get a sample application that accesses the Ultralite C++ API working in Xcode, with Objective-C. But now I am trying to port this sample to MonoTouch. The sample application can be found here:
https://github.com/BruceHill/Ultralite-Names-Sample-ObjC
The Sybase documentation for Xcode mentions the following, with reference to using the API in Xcode:
This tutorial uses the UltraLite C++ API. In order to eliminate the need to cast to C types, compile the source as C++. To compile the project as C++:
In the Search in Build Settings box, enter Compile Sources As.
Choose Objective-C++ from the options in the Value field
What are the implications of this for working with this API in MonoTouch?
You can certainly use a C++ api, but you will need to either wrap it in a C api, or a ObjC+btouch api to be able to talk to this. Invoking C api's uses PInvoke, and C++ libraries use symbol mangling. While theoretically you could pinvoke to the mangled symbol, this isn't a good idea as the mangling is compiler specific.