[question] Stuck the last step of cpp_with_xamarin about mobcat HOT 5 CLOSED

Thanks for reporting these issues. The sample and walkthrough have been updated. Please can you let me know if this resolves the Android runtime issues you had experienced. Can you also confirm whether you get the EntryPointNotFound exception when you use the NuGet package provided in the Artefacts folder. Be sure to remove the current version from all projects and from the local .nuget cache (~/Users/{user}/.nuget/packages) before re-adding them.

from mobcat.

Thanks for the update Mike. I have pulled the latest changes and both the Android and iOS version build and run fine, and I see the math calculation output. I was using the nuget package that you added in with the latest commit, but I have yet to confirm if this works if I build the C++ libraries locally with the updated build script. I'll add a comment in once I test that this afternoon.

I noticed with the build script you have changed the method to compile for the various Android platforms as the old method was was deprecated (i.e. each compiler having its own subdirectory now). I assume this is the main change you made in that regard?

from mobcat.

Thanks for confirming Haroon. The primary changes to the build script were to leverage the prebuilt toolchains rather than the standalone toolchain approach for the reason you describe and adding the -static-libstdc++ flag to link with the LLVM libc++ library which is now the only STL available in the NDK. Please do let me know if you are able to successfully compile the libraries using the updated steps.

from mobcat.

Ok so the script that you updated now works, even if I am building the native libraries from scratch. I had three follow up questions if you had some time :

1. Could you replicate the work done in your build script with CMake, provided we tell CMake about the platforms and architectures to compile for. This would then give use a single project that could build a C++ library for any of those platform/architecture combinations.
2. Do you have any more information about this 'bait and switch' method that is being used?
3. I understand the change you made to the android NDK part of the script (i.e. using the specific clang compilers for each architecture), but I don't get is what the change is that fixed the iOS error I was getting before:

 MTOUCH : error MT5212: Native linking failed, duplicate symbol: '_main'.
    MTOUCH : error MT5213: Duplicate symbol in: /Users/hhaider/Projects/MathFuncsApp/MathFuncsApp.iOS/obj/iPhoneSimulator/Debug/device-builds/iphone10.4-12.1/mtouch-cache/libMathFuncs.a(MyMathFuncsTest.o) (Location related to previous error)
    MTOUCH : error MT5213: Duplicate symbol in: /Users/hhaider/Projects/MathFuncsApp/MathFuncsApp.iOS/obj/iPhoneSimulator/Debug/device-builds/iphone10.4-12.1/mtouch-cache/x86_64/main.o (Location related to previous error)
    error MT5209 : Native linking error : 1 duplicate symbol for architecture x86_64
    MTOUCH : error MT5202: Native linking failed. Please review the build log.

I am now working on the actual project with this same workflow and it seems to be working fine for now!

from mobcat.

Thanks for confirming you are now able to complete the walkthrough using the newer NDK and for your positive engagement helping to keep our samples up-to-date. In answer to your questions:

1. You can absolutely replace the build script with CMake as part of your build process and continue to work with VS Code using the CMake Tools extension
2. Paul Bett's does an excellent job of describing bait and switch in his post. My Colleague James Montemagno also touches upon this concept in a guest lecture for Xamarin University on Using and Developing Plugins for Xamarin
3. The only change made to the iOS aspects of the script was to bump the target SDK version from 12.1 to 12.2. The precompiled iOS library, that you were able to use successfully in your project, had not been updated from its original version. There are a number of reasons why you encountered the MT5212 and MT5213 toolchain errors as described in the mtouch errors documentation. Adding -vvvv to the additional mtouch build arguments to get a more verbose build log might assist you with further investigation should you encounter this error in future

from mobcat.