Frequently Asked Questions

 

How do I launch or shutdown the Mer build engine or the emulator?

When you have a Sailfish OS project open in the IDE, you can see two additional control icons in the left toolbar. Click on MerSDK_icon icon to start the Mer build engine and the emulator_icon icon to start the emulator. These buttons will also allow you to shut them down.

 

Control icon colour key

- Green – stopped, click to start

- Gray – starting

- Red – started, click to shut down

 

How do I stop an application running in the emulator?

In the IDE editor view, at the lower edge, you can see a search box followed by four tabs. Click on the Application Output tab. Click on the red Stop button to stop the running application.

 

How do I add additional development headers to the SailfishOS target?

The SDK control center provides options to extend the default Sailfish OS target. In the IDE,
– Click on the SailfishOS icon in the left toolbar to open the SDK control center.
– Click on the manage button next to the SailfishOS-i486 target.
– The list of development headers available for install is displayed.
– Choose the package you wish to install and click on the install button next to it.

 

How do I login into the emulator or build engine?

The virtual machines use SSH key authentication to login. You can login into them from the terminal application on your host with the following commands:

 

Emulator

The Emulator has a Developer settings application, which you can use to set the password for the nemo user. After that you can login to the emulator as user nemo. Alternatively you can login using the SSH keys.

# as user nemo

$ ssh -p 2223 nemo@localhost

$ ssh -p 2223 -i ~/SailfishOS/vmshare/ssh/private_keys/SailfishOS_Emulator/nemo nemo@localhost

 

# as root

$ssh -p 2223 -i ~/SailfishOS/vmshare/ssh/private_keys/SailfishOS_Emulator/root root@localhost

 

Build engine

# as user mersdk

$ ssh -p 2222 -i ~/SailfishOS/vmshare/ssh/private_keys/engine/mersdk mersdk@localhost

 

# as root

$ ssh -p 2222 -i ~/SailfishOS/vmshare/ssh/private_keys/engine/root root@localhost

 

The SSH daemon (and other network services) on the virtual machines can only be accessed from the host. If you make any changes to the target on the build engine, be sure to re-sync with the host using the Control Center (via Targets→SailfishOS-i486→manage→sync).

 

Why are you using virtual machines?

Using virtual machines allows us to efficiently deliver a consistent build environment to a wide range of platforms. Whilst there is a small performance penalty, we think this is a worthwhile tradeoff for the benefits it gives us all. We have further optimisations planned.

 

What are the shared folders for?

- To securely share the SSH keys on the emulator and build engine.
– So the build engine can see your code.
– So Qt Creator can see the target in the build engine.

This essentially means that the Mer SDK user account in the build engine is, as far as possible, your account. If you wish to share additional directories then please discuss this with the community.

 

Why is the emulator showing a black screen?

It thinks it is a real device and is saving power. We have a solution planned for this. In the meantime a mouse movement will wake it up from application or Home screen – if it is on the Lock screen you need to do a big Pull down or emulate the Power button by pressing Host + ‘H’.

 

I see scrollbars in the emulator window. How do I scale it to the window size?

Modern devices have a high vertical resolution which can be more than some screens. The emulator uses a vertical resolution of 960 pixels and allowance should be made for window borders too. In the VM menu select View→Scale or press Host + ‘C’ to scale.

 

Now I’ve built an awesome application – where do I share it?

The official place to share Sailfish OS applications is the Jolla Harbour.

 

I get the following error, it can’t create symlinks, what is the problem?

ln -s libfoo.so.1.0.0 libfoo.so ln: creating symbolic link `libfoo.so.1': Protocol error make[1]: [libfoo.so.1.0.0] Error 1 (ignored)

 

This happens when TARGET=library is set in your library’s .pro file. In Linux a library gets three additional symlinks:

 

libfoo.so -> libfoo.so.1.0.0
libfoo.so.1 -> libfoo.so.1.0.0
libfoo.so.1.0 -> libfoo.so.1.0.0

 

Since the build location is on the shared home directory from Windows which does not support symlinks, this error happens. You can work around this problem by setting TARGET=plugin, then a non-versioned library will be created during build time. If you want the symlinks in the RPM file, you could create them in the %install section of your .spec file like this:

 

mv %{buildroot}/%{_libdir}/libfoo.so %{buildroot}/%{_libdir}/libfoo.so.1.0.0
ln -s -t %{buildroot}/%{_libdir}/libfoo.so.1.0.0 %{buildroot}/%{_libdir}/libfoo.so
ln -s -r %{buildroot}/%{_libdir}/libfoo.so.1.0.0 %{buildroot}/%{_libdir}/libfoo.so.1
ln -s -r %{buildroot}/%{_libdir}/libfoo.so.1.0.0 %{buildroot}/%{_libdir}/libfoo.so.1.0