Straight question about WebRTC compilation on Windows (GN/Ninja): Is there a specific configuration in GN that tells ninja to build WebRTC into DLLs that can be consumed by a MSVC application? Currently I just build them statically, but this is not good because I am using a legacy application that should consume WebRTC in dynamic link only. Looking into WebRTC build list (in gn) it seems there is no such configuration. Is that statement correct? If not, what would be the option to be used?
Related
i have a separate build-flow that can produce .out files for the MT3620/M4 core using the same gcc-arm compiler.... for reasons beyond the scope of this question, it's not practical for me to migrate this build-flow into cmake....
once i generate the .out file, my thinking was to simply envelop it within a project structure identical to the samples -- with an conforming app_manifest.json file.... from here, i could effectively run just the final step of the cmake build -- which generates the image package....
before i go down this path, is there anything obvious i'm missing here????
As of today you will need to decide to install Azure Sphere SDK Preview for Visual Studio or Azure Sphere SDK Preview for Windows (You cannot install both SDKs on the same PC.)
To develop applications, however, you need to set up your development environment and possibly install additional tools. The Azure Sphere SDK for Windows supports development with the CLI only. If you've installed this version of the SDK, you'll need to install CMake and Ninja on your PC.
If you plan to develop real-time capable applications (RTApps), you might need to install a compiler for the embedded processor and set up hardware to display output from the app.
Both Quickstarts "Build an RTapp on cmd" and "Build an RTApp with Visual Studio" require that you use CMake at some stage and those are the supported methods.
Update: New documentation improvements will be done soon to address the option of using a different build system to cmake and "yes" it should work as you suggest.
I have a npapi plugin(bundle) for chrome, which use C++ and objective-c. now it needs to be build by google native client.
I wonder that can nacl support objective-c? how to compile o-c file by MakeFile
And if possible, how to build nacl plugin in Xcode? I tried, but i found that the libraries of nacl are " archive with no architecture specification".(use lipo -info *.a)
I hope someone to help me, thanks a lot!!!
If you use Objective-C without any of its usual libraries then you should be able to use the PNaCl toolchain (which is based on LLVM) to have it parse Objective-C. I'm not aware of projects that have done this, so you should definitely let folks on the mailing list know if you get something working (do keep the questions on SO, though!).
It sounds like your application won't be running on the open web (where only architecture-independent PNaCl can run, not NaCl), so you could either use the PNaCl toolchain to create a .pexe, or you could use the same toolchain to create a .nexe for each architecture you target. The documentation I linked to helps with both approaches, but note that using the PNaCl toolchain to create a .nexe is currently being improved. You can therefore follow the instructions on the bug tracker, or try out nacl-clang when it's released (or build it yourself if you're brave).
Our Mac application can (sadly) only build and run in 32bit-only. Reason is: a huge bunch of very old 32bit-only C++ code shared with other platforms (Windows, Android, Linux, etc.). This is cross server-client networking-protocol code, so it can't really be replaced. Until EVERYONE needs is 64bit, we're bound to build our app 32bit only.
Now I'm building a new module for this application as an external private dynamic framework. I'd like to use ARC, and the new niceties of modern Obj-C runtime, but these are only available in 64bit-only builds.
So… Could my 32bit Mac Application link, and use, and load a 64bit-only framework?
Well, I found the answer, which is on the whole --- NO.
Here are the details, and a work-around.
First off, a 32bit process can’t load 64bit code. The linker complains when you try to link the 64bit-only framework to your 32bit app.
I was offered two ways around this, both rely on parting the 32bit-only code and the 64bit-only code into 2 different processes, talking using XPC.
The first way would be to create a "host" 64bit process that will load my 64bit framework, and the 32bit application can then use XPC to talk to it.
The second option would be to extract all the 64bit-unsafe code (things I MUST compile 32bit-only) and put THAT in a special 32bit-only process then I can make my application 64bit only on Mac, add the new framework, and talk via XPC to the 32bit helper process.
I'm prepping an application for submission to the Windows Store that utilises the Bing Maps API - as such, the app has to be compiled to target specific architectures. Whilst there is a guide to submission, it's not clear how to submit both Arm and x86 configurations of the same app. Is it even possible, or will there have to be in the store twice?
When you select the option to create your app package from the Visual Studio Store menu, you get a choice to select the package architecture. There are 4 options: Neutral, x86, x64, ARM.
If you select Neutral, then it builds a single package for "Any CPU" that you can upload to the Store. If you select x86, x64 and ARM, it will build a package for each of these configurations, and you will have to upload the corresponding packages for the architectures you wish to support.
Additionally, if you're building to submit to the Store, make sure to always select Release for each of the selected architectures.
There are cases where some references don't support building using a Neutral architecture. The Microsoft Visual C++ Runtime Package is an example.
Taken from here:
The process of engineering for ARM was different for each language (JavaScript, C++, and C#/VB), based on existing implementation details
of the various runtimes and compilers.
JavaScript uses a JIT compiler, so platform targeting is taken care of at runtime. Therefore Metro style apps using JavaScript are
platform neutral, and you can write once to run on x86/x64/ARM.
C# and Visual Basic are also abstracted from hardware differences. They compile to MSIL, which is platform neutral. Therefore, Metro
style apps using C# or Visual Basic can be compiled once to run on
x86/x64/ARM.
C++ is close to the metal, and compiled to the machine language for
the platform that you’re targeting. This offers developers full
control, but also requires that they specify the hardware where the
app will be supported.
The essence of it is that pure .net or pure html/js will run on any architecture without problems. If you want C++ then you will need to compile your app once for each supported architecture. My understanding is that you can create an app package which contains installers for multiple architectures in this case.
The post here has some good details on packaging your app for multiple architectures. Here are a few highlights:
7.In the Select the packages to create and the solution configuration mappings section, select the check box for each build configuration
for which you want to create a package.
The build configurations grid lists the possible platform
architectures of the package (that is, Neutral, ARM, x64, and x86). In
each row, a combo box displays the combination of the current Solution
Configuration and Architecture choices that are relevant for that
row’s architecture. The check box for the default platform is set to
the current, active project platform. The combo box for the Neutral
row show the Solution Configuration combinations that contain AnyCPU
as the project’s platform. If no Solution Configuration combination is
relevant, the entire row for that platform is unavailable for
selection. One package is produced for each configuration that you
specify.
8.For each build configuration that you specified, choose the Solution Configuration that you want to build.
When you package an app for the Store, you can specify Release or any
custom solution configuration that you’ve created.
A package will be created for each build configuration that you
specified.
From here we get this:
7.Click Packages to upload your app's packages.
And finally from the previous link:
Signing and publishing
After your app passes the certification testing, its packages are
digitally signed to protect them against tampering after they have
been released. When this phase begins, you cannot cancel your
submission.
Note It might take some time for your app's listing to appear in
search results. This is normal. Also, you can't change a release date
after you submit the app to the Windows Store, but you can cancel the
release, update the release date, and re-submit.
Overview: During the build process you specify all architectures you want your app to work for and it creates a package for each. During the submission process you select all the packages you built for that app. When submitting you app this way only one version will show up in the store.
If you build just a HTML5/javascript Windows Store app, it work on all version (ARM, x86 and x84)
If you create something web with bing api. No worry about what platform doesn't work.
Answer is here: http://developer.android.com/google/play/publishing/multiple-apks.html
TLDR:
Go to your Google Play app developer console
Choose your app
Select APK on the left
Turn on Advanced Mode
Upload your ARM apk
Upload your x86 apk
Google will figure out the rest
How can I know, whether an external library can be compiled to work on a different platform? the library for instance is tesseract-ocr
And if it possible, how do I do this?? (Basically I would like to create a Qt application that uses this library)
To find out, try building the library yourself. At the moment your question is quite broad. Post new questions when you have something more specific to ask.
If building the library fails, it is most probably due to some unsupported dependencies that you need to port first yourself.
Porting to Maemo is probably straightforward as it is a Debian-based environment and supports all the build tools such as autotools.
Symbian doesn't have autotools. Perhaps the fastest way to get started there is to first configure and build the library on e.g. cygwin and then generate the required bld.inf and .mmp files to build it on Symbian.
You can link your Qt application to regular C/C++ libraries. Just include the necessary header files in your code and link to the library using LIBS += -lfoo in your .pro file.