So as Bob mentioned in his yesterday’s update, I tried to build natively on the Tizen emulator (available as part of their SDK). Unfortunately this proved to be an dead-end (see the full story below).
We still thought we’d describe what our process was, as that might help someone down the road and/or convince the Tizen people to make this process possible in the future. After all it’s a pity to have a Linux flavor that can’t build anything natively… Why not stick to Android then?
So first step is installing the SDK (network install or local image-based install, either are fine).
This basically creates 3 folders (assuming a *NIX-based system here):
~/.installmanager_2.3.1~/.tizen-sdk-data~/.tizen-sdk
The last one is the most interesting one. The first two are essentially there for storing logs of the SDK installation and the emulator data and logs. The tizen-sdk dir (A.K.A SDK_PATH in scripts) is a pretty massive folder (~6GB), which contain files for the emulator, IDE (Eclipse spin-off) and libraries/toolchains for the various platforms and architectures.
The emulator can be found under ~/tizen-sdk/tools/emulator, and the bin/em-cli in it is what I used to get the emulator running (note that there’s also a UI in it, but it died on me consistently). So with it you can do a few interesting things:
./em-cli list-image, which lists the base images available: x86-standard / mobile-2.3.1, x86-circle / wearable-2.3.1, x86-standard / wearable-2.3.1./em-cli create [...], to create such a VM (see below for details)./em-cli launch [...], to launch VMs./em-cli delete [...], to delete VMs- …
Note that em-cli -h gives you all the actions possible, while em-cli -h <ACTION> gives you help on a specific action (e.g. em-cli -h create)
So you can create a VM called mytizenvm like so:
./em-cli create -n mytizenvm --base-id 2
The value for --base-id corresponds to the ID field from the list-image command above, in this case corresponding to x86-standard / wearable-2.3.1 (ID 2). This should return Success: To create new Virtual Machine is completed. (sic). The data is stored under ~/tizen-sdk-data/emulator/vms/mytizenvm by default (where you’ll also find logs).
The content of ~/tizen-sdk-data/emulator/vms/mytizenvm is as follow:
$ file *
logs: directory
emulimg-mytizenvm01.x86: QEMU QCOW Image (unknown version)
swap-mytizenvm01.img: QEMU QCOW Image (unknown version)
vm_config.xml: XML document text
So really just a QEMU image and a config file.
Next up is launching the VM:
./em-cli launch -n mytizenvm
You can see the logs under ~/tizen-sdk-data/emulator/vms/mytizenvm/logs. By now you should see something like this pop up on desktop environment:
Note that the button on the right-hand side is clickable and that right-clicking on the watch image itself gives you access to a contextual menu. Also, closing the watch cleanly has never worked for me, I always had to Force Close it (in Advanced sub-menu of the contextual menu).
From here, we want to open a shell in order to access the emulated device: use the Shell option in the contextual menu, this will pop-up your default terminal (gnome-terminal in my case). Tadah! You are now in the Tizen system.
On it:
- you are the developer user, whose home dir is
/home/developer
- you can become root:
su - root
- you can setup a shared directory with your “host” machine (the one you started the emulator with), by default under
/mnt/host on the device (right-click> Control Panel > Device Manager > Host Directory Sharing). Note that the /mnt/host is owned by the system user.
- you can see what ports are open:
netstat -tulpn
- you have access to a few very basic binaries under the usual
bin folders (see echo $PATH for complete list)
But in order to build either geth or eth, ones needs to… be able to build in general! And this is were things get rough. There is no make. So we should try and build it! But… there’s no gcc to build it either! So we need to build gcc itself… So it means having to go through these steps.
There is also an rpm binary available however, and http://download.tizen.org/snapshots/tizen holds many RPM files. I poked around at it but was unable to get anything useful out of that binary (it lacks both -bb and --rebuild options for one thing).
So at this point, I decided to get help on the Tizen forum, and Bob pinged one of his contact on the Tizen side. And then we were basically adviced to give up that route and to stick to cross-compilation (see Tizen native builds section of Bob’s post for the specific answer).
So now… off to cross-compilation wonderland instead (luckily the SDK setup will be useful here as well)!
doublethinkco 