I know that in a normal NDK build, the C++ libraries are built and packed into an apk file. But how can I automate this in Eclipse? I have tried following http://mhandroid.wordpress.com/2011/01/23/using-eclipse-for-android-cc-development/ to run the native-activity sample that came with the NDK, and it ended up not working. Even after I got past most of the reference errors via including, nothing happens when I run it as an Android Application (with a Motorola phone plugged in).
I have looked around quite a bit about this and am still stuck, so I'm open to suggestions at this point. Thanks!
(Please keep in mind that I'm using MinGW/MSys on Windows 7, mostly for running scripts with bash)
I've just decided to go with an Ubuntu VM and use that, and with some tweaking it seems to be working the way it should. I used a combination of http://mhandroid.wordpress.com/2011/01/23/using-eclipse-for-android-cc-development/ and http://developer.android.com/sdk/ndk/overview.html#native-activity to get everything set up. Also a very important note, go to C/C++ General -> Code Analysis -> Launching in your Eclipse project settings and disable both of those options for any native activities you make. I'm not sure if there's a good way to set the libs and includes up for it to work, but currently live bug checking screws things up in the NDK, and I can currently build successfully without it. Plus it'll still mark errors in red after a failed build, so you shouldn't be completely in the middle of nowhere when finding errors.
Related
I've spent the past few months converting a project of mine with about 1500 source code files into Swift. It was incredibly tedious, but I finally did it. It runs well, builds well, but:
When I attempt to archive the project, Xcode fails with the following error:
ditto: can't get real path for source '/Users/USER/Library/Developer/Xcode/DerivedData/
APP-dtsbrzschafjiubelceuxtfwstqf/Build/Intermediates/ArchiveIntermediates/APPCore/
IntermediateBuildFilesPath/APPCore.build/Release/APPCore.build/Objects-normal/
x86_64/APPCore.swiftmodule''
Command /usr/bin/ditto failed with exit code 1
APP being the app and APPCore being the embedded framework.
What I've tried:
cleaning the project (which really has no effect when archiving, since archive always compiles from scratch)
using Xcode 7.2 beta (released a few days ago)
making as many declarations as possible non-public
disabling any Swift optimizations for the release build configuration
building the APPCore framework as release - which actually works (!) - and does (!) create the .swiftmodule file
The last part being the strangest here. This evidently points to the archive doing something slightly different, but I have no idea what.
My question is if anyone has any idea why is this happening and how to debug this. I've spent the last two days trying to figure this out, but no results...
I've googled this error as well, but unfortunately, the answers were fairly limited and suggesting to comment all lines of code and then start slowly uncommenting them until the project builds. Which is OK for a smaller project, but not for a 25KLOC project, mainly when you have absolutely no idea where to start...
I had the same issue and your question actually helped me to solve it (Xcode 8).
In debug mode just got the "ditto: can't get real path for source" without any further information. Switching to release mode showed me that the problem was that the framework wasn't allowed to have a bridging header file. I went to the build settings and removed the bridging header file (don't know why there was one) and it now compiles both in release and debug mode.
I use the IDEA13 community to work with the Haxe openFL. I had installed the Haxe plugin. I create a haxe project. I can run it with any target, such as Flash,HTML5, mac and so on. But I can't debug it with any target platform. To my surprise, I even not see the red point after I click the IDEA side which would appear a red point when I do the same in a java project.
Then I tried to use debug icon button to debug it. But nothing show me after the compile complete.
Can anybody know whether the IDEA13 support to debug Haxe project? if can, how can I set?
I need help.
I wish everyone goes well.
Unfortunately the community plugin does not provide debugging for all the targets.
Currently only flash and an experimental cpp debugger(tivo fork) are the only implementations provided.
For html5 the plugin requires work to integrate with idea's javascript debugger. You can however use the Haxe generated source maps for break points on Haxe source code within the chrome developer tools.
There is activity for this plugin on github so it may just be a matter of time.
I'm currently working on the eyewriter 2.0, with the idea that if I can get it working, we can recommend the DIY to our ALS patients and their families.
However, I've been running into many complications while trying to get the software up and running.
I'm currently running Windows 8.1.
I have installed currently Code::Blocks 12.11 and OpenFrameworks v.0.7.4.
I have the openframeworks additions for Code::Blocks installed.
I have successfully run multiple example programs in openframeworks.
I have tried various combinations of C::B and OF such as the following:
13.12 and v.0.8.4;
13.12 and v.0.8.0;
12.11 and v.0.8.0;
12.11 and v.0.7.4;
10.05 and v.0.6.1 FAT pre-release;
10.05 and v.0.6.2 FAT pre-release;
The most common error I have been getting is "fatal error: gl\glew.h: no such file or directory" for the line #include "GL\glew.h" in the ofConstants.h
I'm able to eliminate this error by finding the file manually and inserting the path (i.e. C:/.../.../.../glew.h). However, there are many, many, more errors similar to this which causes the manual correction to be very tedious.
I'm suspecting that the problem is due to my newb ignorance of the proper file structure. I haven't changed the structure from the zipped file which can be found on github.
Location of Workspace: C:\openframeworks\apps\eyewriter-master\eyeWriterTracker\RemoteEyeTracker.workspace
Location of glew.h: C:\openframeworks\libs\openFrameworks\gl\glew.h
Has anyone had any success building this on a windows machine? Are there any obvious mistakes that I am making? I'm fairly certain that I'm making noobish mistakes, as I'm new to frameworks and my C++ knowledge is moderately limited.
Is this perhaps easier to do in Ubuntu? I do have the possibility of using Ubuntu in Oracle VM, although not ideal as the purpose is to allow ease of communication to ALS patients and this would add another step in the process even after it's built.
I also am aware that there are already pre-compiled versions of the Eyewriter software available, but I would like to use that only as a last resort when all other resources have been exhausted.
Thanks!
Make a new project with projectGenerator(add neccessary addons)
Add files from eyewriter to your new project
That project is really old, so there will be a lot of changes, oF documentation will come in handy
have fun !
I am working on a project that uses Cinder for graphics, and for image loading, we are using FreeImage mainly for loading HDR images.
It is all working fine under windows, but now I am trying to build an OSX version I am hitting a snag.
First I tried to download and build FreeImage, but the makefiles are hopelessly outdated and do not work. I managed to fudge them and build the library, but when adding to xcode it didn't seem to link. The error was that the library was ignored because it was built with a different architecture. (I couldn't figure out how to fix this, but it is an option to go back to if all else fails).
Anyway, my next attempt was to use macports to install and build FreeImage. This all worked without error and I was able to include the library in my project.
However, the problem now it that I get many std linking errors. After searching around, it seems my problem is that freeimage was built with libstdc++, but cinder complains if I dont build my project with C++11.
So, is there any way of fixing this? Can I modify the make files macports uses to build freeimage? Or is there some other sneaky way? Any suggestions appreciated.
Sorry if this question is a bit parochial, but in my searches I have seen others with similar problems (but unfortunately few answers).
I've been trying to build linphone for android for a few days now but I've come to a point where I'm unable to fix the problem I encounter in the build process.
I've been following the provided readme step by step and also tried several ways explained here in SO questions but non get me passed this current point.
http://pastebin.com/gxmc2gwZ
The above pasbin link shows the output of my mingw32 window when I run make. At the end it just holds. It feels like make just goes into an infinite loop. I've left it running overnight but it stays at that exact spot. The only way to stop it is ctrl-c.
Sofar I've used 3 difirent android NDK builds thinking there might be an incompatability.
r8e, r7c and r7 dont work. r7 doesn't even get this far.
I've also tried running make with SHELL="sh -x" but the resulting output is hardly difirent (as expected).
I've tried searching on google but all hits always show an error in the logs. Mine does not.
If anyone has any idea what can cause it to hang that would be REALLY appriciated.
I fixed the problem by running ndk-build.cmd from the project root directory in a command prompt instead of using make in mingw wich called the linux version. my project is now happely compiling along.