My aim is to use Apache thrift on one of our device having vxWorks 6.8 (C++).
I need steps to build thrift lib(.so) or sample application on vxWorks. It would be great help if someone could suggest way out. I am using Windriver Workbench 3.2 on windows 7 and target is PENTIUM3gnu. I can use boost but not C++ 11.
Well, as someone who had to make Thrift build on a bog-normal Fedora PC, and as someone who knows the pain of making it work on embedded platforms¹, I can assure you that your confusion is at least partly caused by Thrift's sub-par build system.
I can't actually give you detailed descriptions on how to build it on vxWorks, but here's the general consensus on what needs to be done when building it on something that doesn't happen to be very similar to the maintainer's machines:
massage all the ./configure options, and explicitly disable every single thing you don't need. Even after much script fixing, I couldn't build the examples/tutorials, so I had to disable them
explicitly state dependency paths. The autoconfigure scripts seem to have been modified in a manner that makes auto-detection of libraries work worse than it normally does with autoconf
try to build. Find the places where for some reasons, the build system uses hardwired locations and hence fails
rinse, repeat.
¹ OpenEmbedded, Android
Related
I am trying to setup grpc server for a embedded device which runs the C++ environment. I have followed the link at https://github.com/grpc/grpc/blob/master/INSTALL.md, but I am unable to understand what needs to be done there in a order for grpc library to be available or installed in C++ libs.
Setting up grpc for C++, I assume to be having a generic approach for windows/Linux environment apart from the specifics of C++ run time location
The approach at above location says to build, but its failing for me at step,
With error as below,
Anyone if having more detailed link/reference to step by step process would be really helpful
For building gRPC under Windows nowadays, I would highly encourage people to use the provided CMakefile.
We haven't done any work towards supporting cygwin however, and we don't have any plans in supporting it at the moment. Most of the Windows-specific codebase would expect msys/mingw or VC, and I wouldn't be surprised if it would fail at runtime with cygwin even if you manage to compile, as our usage of the Linux API is probably too advanced for cygwin's emulation layer.
The Makefile should potentially behave properly under msys, if you insist on using it.
My task is to create a C++ SDK - in the form of a dynamic library(s), most likely.
It is supposed to be used on different platforms - Windows (32/64 bit), Linux (32/64 bit), Mac OS, Android and iOS. I don't have much experience with multi-platform project setup and I'm trying to decide what methods and tools to use for easiest development and deployment.
Side note: I will also have to prepare automatic builds (jobs) on Bamboo CI server, in order to run compilation and tests for each required target.
My main dilemmas are:
Project setup. Should I prepare different project schemas for use on different platforms (like .sln on Windows and makefiles on Linux), or maybe try using a tool like CMake? Is it even possible to prepare a CMake project that will suit all these target platforms?
Compilation toolchain. Should I use "native" C++ compilers for every platform (like MSVC on Windows and GCC on Linux), or maybe a single toolchain like Clang + LLVM? Would Clang + LLVM (and some linker obviously) be even able to build distributable binaries for all these platforms I need?
Development Environment. Which OS/IDE would be best for working on that kind of project? I prefer working on Windows and my usual IDE is Visual Studio - would it be viable in this case, or maybe something else would be more appropriate?
I know that my problem is very complex and there is no straight answer for any of these points, but every advice and even partial answer will be much appreciated :)
As you say, there is no one-size-fits all solution, so I will make some general suggestions. Feel free to pick-and-choose as you feel is most beneficial.
If you plan to do your building on the host OS, cmake sounds like exactly the tool for you. It self-describes as a "build system generator", where the steps to build on a specific host OS are abstracted away, meaning the same setup "should" work for any system cmake supports.
If you're thinking of cross-compiling, you're in for some hurt with the iOS and MacOS goals. As far as I know, and I have put some effort into trying, Apple does not release compilers for their systems that do not run on their systems -> You will have to compile for iOS and MacOS from a MacOS computer. If you can prove me wrong on this point, I would be glad to hear it :)
Depending on your licensing requirements, if you really want an overkill solution you could look into Qt* and qmake. I have had excellent luck with their multiarchitecture solutions, and Qt supports all of the systems you listed in your original question. I find Qt + qmake far easier to deal with than cmake.
* Yes, Qt does non-GUI work quite well too!
I touched on this in the second point of 1., but my general suggestion would be to use native toolchains. Excluding MacOS, it's easy to set up Virtual Machines, build server, etc. to build native code, and my experience with cross-compilers is they always add another layer of heartache, even worse than having to remote-access a separate builder computer.
Provided you avoid system-dependent headers, libraries, or extensions, it shouldn't matter what system you use. Things like <windows.h> and <linux/*.h> are obvious, but the best way cross-platform compatibility can be verified is by testing the foreign systems as often as possible.
Agnostic of compiler used, I would suggest turning on all the warnings. They are usually important, and may indicate a place where the compiler was able to band-aid over a problem but trying to compile for another system will blow up. If you're working on a team, it might be a good idea to set warnings to result in build errors to make sure the rest of the team is as rigorous as you are.
I don't know about LLVM or MSVC, but GCC will give you some hints as to platfom-specific extensions if you give it the -pedantic and -ansi flags. As explaind here, those flags tell GCC to warn for any GNU-specific extensions.
You are very likely going to need multiple tool-chains (you mention C++ and it has no ABI so to be usable on Windows you are more or less required to build with CL). It follows that you will not be able to use a single vendor-specific project setup. As the project grows maintaining multiple versions of project files becomes quickly untenable so your choice of build system is critical. Have a look at Shake and compare to alternatives with a similar feature-set. The choice of IDE is of less importance - many programmers prefer their favorite editor (Emacs or Vim) and may need to do work on any of the supported platforms.
I am required to write a C++ application to run on an embedded Linux setup (DMP Vortex86DX processor). The vendor provides a minimal linux installation image that can be installed to the board and contains appropriate hardware drivers. My question is motivated by the answer to my previous question about writing Linux software on a particular kernel to run on a different kernel . I don't really know where to start when it comes to writing the software with regards to ensuring compatibility.
My instinctive approach would be to install the same versions of g++ on the embedded device and on my desktop development machine, write the application on the dev maching, copy to the board and compile it there. This seems madness though and I find it hard to believe that this is how embedded software is developed. With regards to the answer to my previous question, is there a way I can simply build on my desktop but use the version of glibc that exists on the embedded device - if so how can enforce linkage to a specific version? Or is it possible to build everything statically so that the application doesn't link to anything dynamically (I doubt this is possible).
I am a total novice to embedded development, and foresee months of frustration unless I can get hold of some good advice or resources. Any pointers or suggestion of where to start will be very gratefully received no matter how simple or trivial they seem - I really am starting at the very bottom with regards to embedded stuff.
OK, given the fact that the Vortex86SX/DX/MX claims to be x86 compatible, a small set of compiler switches should enable you to compile code for your target machine: -m32 to ensure 32bit code, and no -march switch targeting a specific CPU.
Then you'll need to link your code. As long as you don't use anything fancy, but simple established glibc functions, I'd expect the ABI to be the same on your development machine and the embedded system. In other words, you compile against your host libraries, copy the binary to the embedded system, and it should simply run using the libraries available there.
If X-Linux were to use some other libc, like uclibc or similar, then you'd need a cross compiler on your host. I have little experience with Ubuntu in that regard, but I know that the sys-devel/crossdev package for Gentoo linux makes generation of cross-compilers very easy. This can be both for different architectures (not needed in your case) and different libraries (like e.g. uclibc).
I'd say simply give copying the binaries a try, and report back if you encounter any problems there.
I am currently researching a good setup for a continuous integration server which would build various C++ applications for several Linux distributions.
My primary question is how other users here have handled the differences in system libraries between Linux distributions?
While it might be relatively easy to build direct dependencies such as UI libraries along with an application, "indirect" dependencies such as glibc look like a big pain if they had to be built alongside the application every time. I am therefore thinking of moving the actual build execution into a separate virtual machine for each distribution, e.g. using rlogin to run the commands. My goal is to prevent binary incompatibilities between build-machine library versions and those deployed in the target distributions.
Does anyone here have any experience with such a process and could tell if the above sounds like a feasible approach?
We use Jenkins (Contiguous Integration) and CMake (build system) for this purpose. Jenkins is similar to Buildbot, i.e. it also has buildmaster and buildslaves. Currently I have setup 8 slaves to build for 4 different platforms (FC8, FC10, FC12 and Windows 7). We build both debug and release binaries, so I dedicated one slave for each platform and build type.
As for the third party libraries like Qt & Boost, I compiled them on each platform and checked them into a separate repository.
#esavard: We use CMake 2.8 to do cross compilation, I have not used minigw but a quick google search indicates that it is possible. Here is a link to a tutorial to cross compile for Windows on Linux using CMake and miniGW.
I have not used Buildbot and cannot comment on its features but thought I should mention an alternative that we are currently using.
Hope this helps.
Buildbot has the notion of buildmasters and buildslaves.
A buildmaster takes care of displaying the web GUI, sending email, triggering builds, and other housekeeping. The buildslaves wait on the buildmaster and when commanded perform builds.
We have buildbot set up to build on a number of different platforms, some of them VMs, and it's working well for us.
Certainly buildbot and many virtual machines is the way to go with this. We have VMWare ESX server hosting many build slaves which overnight compile our application. The application is then tested on another virtual machine (not the build slave and just having a default OS install) to verify that it works and all dependency's are packaged.
The nice thing I would like to do is make the testing run time phase an automated step but I haven't been given the time to do that yet.
I have neved did a cross platform development before but the process we currently employ such as doing the development on a Windows machine (as we are mostly a Windows shop) and then actually building the binaries on a Solaris box looks a bit convoluted to me.
Can you recomend me a cross compiler so I can limit development tasks to a Windows machine (e.g. building Solaris binaries (.so)), and only use Solaris machine for a testing and deployment.
It would also be great to be able to test a resulting binaries on a Windows machine before (e.g. dependencies b/w binaries) deploying them into the Solaris box, but it looks like I am asking for too much.
Why not use a tool like cruisecontrol to build your apps for you simultanously on both platforms. Doing it this way makes it easier to add more platforms in the future.
Failing that you could use cygwin or mingw to build on windows only for development, then build your real distribution on solaris.
I don't know anything about cross compilers as I've never used therm, sorry
I don't know if a Windows/Cygwin hosted compiler that targets Solaris exists as a ready-to-use product, in any case some googling around didn't give any results.
However, I do have some experience with the creation of gcc&friends based toolchains that run under Cygwin and target Linux platforms (i386 and ARM). When your target is Linux, there's a tool called crosstool that automates a lot of the work that needs to be done, so basically with a reasonably fast machine, a healthy dose of patience and a (longish) evening of build runs you'll be able to build a usable toolchain.
Although in theory you could mimic what crosstool does to create your own cygwin to solaris toolchain, I'm afraid that in practice it may just not be worth the effort.