Hey all. After much googling, I landed here as no similar problems I read about were my exact cocktail of issues. Here’s what I’ve done so far:
-successfully put out a very simple, one function dll plugin for unity using Visual Studio/C++ that works. I used the Windows openCV package with openworld_341.dll.
-tried producing an android plugin from the same solution. I tried to do this by switching from x64 to ARM and from dll to static library, then had it export as .a instead of .lib…which builds successfully, but Unity refuses to recognize the .a file while running on android. Maybe I’m naive in thinking that was all I had to do?
-tried restarting a new project in Visual C++ with Android, C++ and a shared library as a target, using folders from the actual Android sdk of OpenCV (thinking maybe I was an idiot for not doing this first). Now it lets me build to .so, which is great. I added in the usual library folders and proper dependencies.
However – my last issue seems to be that for whatever reason, this Visual C++ Android dynamic shared library solution does not have iostream.h or stdio.h. What am I missing here, other than the obvious? When I built a project for windows/x64, these were findable automatically.
Other notes since then: I have ARM as my target, release mode. I use gnu c++ 11 as my language option, have tried both clang and gcc, have tried with opencv 3.41, 4.5 and 4.1, and I’ve tried a few different android NDKs, including 21e and 16rb. I’ve been trying with the precompiled binaries for the opencv android sdk. Errors will vary each time — when I feel like I get close, all the errors seem to come from the arm neon header file, but I can’t prove others won’t pop up if those were fixed.
Is it possible that visual Studio 2019 has some kind of built in tool chain under the hood that makes building android plugins for this impossible? Amin Ahmadi seems to have done it at least once though (his blog tutorial was one of the ones I tried unsuccessfully)
Or maybe you just can’t do this with precompiled binaries and have to build from the source?
That would break the Internet, but the common ones from the arm neon header file, and are:
“Identifier __fp16 is undefined” (line 34)
“float 16_f is ambiguous”
“Identifier __builtin_neon_v(somename) is undefined” (there’s many variants of that one)
“expected a vector operand”
“Too many initializer values”
I seem to have all the ARM build tools installed that VS 2019 recommends, so I’m stumped.
also be aware, that those headers are part of the resp. compiler / toolchain, they won’t get redistributed with anything you build with it.
(in other words, you made a local mess with various compilers, and we cannot help)
Look, I get it – I’m the resident cranky developer at my job and I talk like that to people who mess with my stuff when I think they’re meddling with things they shouldn’t be. I also say “not my problem” often enough that I get that too. But I also said a lot more than what you just quoted and all I’m trying to do is find the right toolchain that I should be using across the board for compilation. I sure as hell didn’t make a mess of anything on my own – I’m using the Visual Studio 2019 Dynamic Shared Library template FOR ANDROID, with the changes to include and library folders.
yes, this forum can do some nice things. I last saw such functionality in phpBB two decades ago.
since there seems to be nobody who knows much about OpenCV + NDK, you get to experiment.
keep/swap parts and try again. you should swap out Visual Studio for Eclipse or plain command line. see if it can be built like that, and it’s just a problem with the setup/configuration/… of VS.
you questioned whether the official binary release’s contents can even be used for this… they can’t if it’s a build for x86/x64 (even if you run android on x86 I’d question that) and I am unaware of any official ARM binary releases of OpenCV.
Hrm. I know there’s a paid plugin for OpenCV that works in Android with Unity, so someone’s made an ARM plugin with it. I’m just trying to save some money and streamline what I need.
And I’m using the android sdk release – that’s got everything needed to (supposedly) make an ARM target shared library that works with Unity for Android, according to several tutorials that I will continue to pore over.
you could comb through opencv source (git blame on specific files) and track down those people that wrote about it. the tutorial I saw mentions opencv v3.0.0, which makes me think it has aged several years without anyone touching it.
“build from source” must mean cross-compiling in this case. be sure you’re actually executing the toolchain/compiler for android/NDK (not anything for the host), and that all the flags make sense (it’ll need to know what architecture and whatnot). cross-compiling is more finnicky than just building for the same host.
Thanks. Toolchains are what I’m wondering about – Visual Studio automatically populates the project settings with numerous uses of the LLVM toolchain, and I’m wondering if anyone here knows if that’s right or wrong.
llvm sounds sensible. I have no clue but here it looks like that’s the usual compiler. a good sign but not the finish line.
if you’re out of luck, some GSoC participant once several years ago spent a summer making stuff work, kinda, and everything around it has morphed since then, and nobody cared for it in that time, and now it doesn’t work anymore. I hope that’s not the case. I hope there’s not just that one company that sells a solution, but that the recipes exist somewhere.
or maybe you’re doing something you aren’t supposed to. you’re in the best position to figure that out. everyone else is further away from the subject matter.
software construction is stuck in the past. it’s all serial batch execution of glorified shell scripts. the most complex data structure is the string. everything is held together by strings that have to be precisely correct. tools have no smarts, and those that have a little, are made so unreasonably complex that they’re practically near impossible to use. if anything’s not in the exact right place, instead of being the least bit helpful, the toolchain craps a dozen pages of errors at you. it’s tiresome, I know. it’s one of the big reasons why people leave the programming world. it’s one of the big reasons why highly educated people (can) refuse to do much/any programming in their jobs. I am constantly amazed that anything builds successfully. I’ll be quiet now.