It’s pain in the ass. Really. If you can stick to Ubuntu or its derivatives, please do that.
I kinda hate how Tizen Studio is developed to only support Ubuntu out-of-the-box. A software should not dictate what Linux distro it should be installed on. Distro is just like a religion for some people, and some people are like me, who doesn’t like Ubuntu and its bloatware.
Personally I use OpenSUSE on my home workstation, and Fedora on my office workstation. Both distros are RPM based and it is really difficult to install Tizen Studio which is tied to Ubuntu (which relies on Debian Package).
Installing Tizen Studio in Fedora and OpenSUSE is basically similar: it nags every single time. Firstly, Tizen Studio requires Oracle JDK. So for a system with OpenJDK by default installed, you have to install Oracle JDK then change the default Java to Oracle JDK. I am not sure why Tizen Studio forces us to go for Oracle JDK instead of OpenJDK as there might be only subtle differences between those two. Even this Stack Overflow thread said so.
Continue reading “Tizen Studio on Other Than Ubuntu”
I have been dealing with Tizen development since about last year, and since then I have been learning of utilizing C++11 features on my codes. Currently I am developing a some kind of component to help performing message pump in threading, so you can dispatch a function to a queue to be performed in separate thread.
It is a simple components actually. You can take a look at GitHub.
DispatchQueue class basically accepts functions to be queued to be executed in another thread. I uses
std::deque to queue the tasks, and
std::function to store lambda or other callable objects. To support the threading, I uses
std::mutex for synchronization, as well as
std::condition_variable to suspend thread during empty queue.
The code compiles flawlessly, but when I tried to run a Tizen native app using this component, the app directly crashed upon starting the
DispatchQueue class. The worst part was that the call stack in crash log does not show that it was crashing in user code, but it shown that the signal was SIGABRT so it might be caused by an unhandled exception.
Continue reading “Weird std::thread bug on GCC 4.9 on ARM target”