Table of content

This is the easiest in term so the number of steps, because essentially you only need to execute these commands on you phone (either via Terminal app, or ssh shell):

$ sudo mount -o remount,rw / $ sudo apt-get update $ sudo apt-get install fpc lazarus $ sudo apt-get -f install #this will add dependencies and fix any errors from previous step $ sudo mount -o remount,ro /



it will use a lot of space on your / partition (esp. lazarus part will be some 700-900M)

you will not be getting the most recent version of neither fpc nor lazarus, because the official repos are not up to date with the most recent stable releases if you want, you can always move some of the data to your userspace and create symlinks back to the original location. But first you will need to have enough space to finish installing packages, before you can move them this way.



There is just one problem if you want to use recent Lazarus, it will not compile with FPC compiler older than 3.0.0, and on my ARM devices using the default repos with apt-get lands me older versions like 2.6 or around that version. Since this post will not go into details of building the fpc compiler yourself from sources, so as an alternative solution to get you going, I will provide a pre-compiled fpc 3.0.0 that you can download to your device and use to build Lazarus up to version 1.8 (which is going to be the next stable release, and for now it is just in the release candidate stage).

Method 2: building from sources (recommended) This method is actually my preferred one, and I also recommend it to you. It is also a method that I will focus on, and give a comprehensive step by step explanation for. Remember that on Ubuntu Touch the system partition is read only, and you won't be able to follow this tutorial unless you switch it to writable. These are the commands that you can use to enable writing to system partition and to revert it: #to make system partition writable: $ sudo mount -o remount,rw / #and to revert it to read-only: $ sudo mount -o remount,ro / Prerequisites are some packages that are crucial for the compilation, but might not be installed on your system: $ sudo apt-get install build-essential subversion gcc $ sudo apt-get install libgtk2.0-dev libcairo2-dev libpango1.0-dev libgdk-pixbuf2.0-dev libatk1.0-dev libghc-x11-dev libx11-dev



then we need to get the sources for lazarus. The most recent bleeding edge version is hosted at:

so on your ARM device let's get it, I decided to download it to ~/Lazarus1.8: the gcc package is not a dependency to neither fpc nor lazarus, but installing it generally also installs some other dependencies that came come useful. It probably is not a required step, but I consider it a good practice, and having gcc compiler in addition to fpc is fine with me too. Subversion is needed for downloading sources to compile.then we need to get the sources for lazarus. The most recent bleeding edge version is hosted at: svn.freepascal.org/svn/lazarus/trunk/ but you probably don't want this version, because it might be unstable, or even not possible to compile. The most recent stable release might also not be what you want, since it might be not very recent either. A good practice is to check tags under svn.freepascal.org/svn/lazarus/tags/ and see what is available. Versions that end with RC are release candidates, and are versions that are going to eventually lead to the new stable release. RC versions are generally fine to use if you want something recent. At the time of this writing this is the most recent RC version: svn.freepascal.org/svn/lazarus/tags/lazarus_1_8_0_RC5/ so on your ARM device let's get it, I decided to download it to ~/Lazarus1.8: $ mkdir ~/Lazarus1.8 $ cd ~/Lazarus1.8 $ svn checkout https://svn.freepascal.org/svn/lazarus/tags/lazarus_1_8_0_RC5/ lazarus-code #it will take a while to download... $ cd lazarus-code $ cat README.txt the README.txt file will tell you exactly how to build the sources, and in my case it says:

"(...) Compilation: You don't need ./configure, just do []$ make clean bigide (...)"

so if we should be able to build lazarus with just one more command: $ make clean bigide and it should do the trick, unless:

your version of fpc compiler is too old to compile your version of lazarus (get most recent one from www.freepascal.org)

some packages are missing (just apt-get install them)

you're unlucky (try these 5 Ways to Invite Luck Into Your Life) But there are two problems with this method:the README.txt file will tell you exactly how to build the sources, and in my case it says:so if we should be able to build lazarus with just one more command:and it should do the trick, unless:

Method 3: copying from another device

if you already have working Lazarus IDE on another arm linux device (for example on your raspberry pi), then you can just copy it to your UT phone. But you need to be smart about 2 things:

matching fpc version with lazarus version

adding any missing dependencies for the fpc version, the newer versions are generally backward compatible, so it is ok to have a newer version of fpc on your target than on your source. If the version on your target is too old, you may want to update it to the latest stable release first. The you copy all the lazarus files, and run it.

Upon first time you run lazarus on the target device there will be GUI for telling lazarus where are freepascal sources located, and some other things. This is because I assume that you did not copy lazarus configuration from the source device, so that here on the target device lazarus can now create a fresh configuration.

You might still not be able to actually compile things. There are some dependencies that you are likely needing, and the list I suggest is just based on my experience, you may need something else that I am not listing here, but a fair start:

$ sudo mount -o remount,rw / $ sudo apt-get update $ sudo apt-get install build-essential # things that will provide libraries for gtk widgetset that is default one in lazarus on Linux $ sudo apt-get install libgtk2.0-dev libcairo2-dev libpango1.0-dev libgdk-pixbuf2.0-dev libatk1.0-dev libghc-x11-dev libx11-dev $ sudo mount -o remount,ro /

If you now can compile in your lazarus on the phone, then you are almost good to go, but check the Known Issues chapter.

use-case 1: Raspberry Pi









And I also want to show how to make Lazarus work in a single window mode, like the modern RAD Studio does. By default Lazarus starts in multi window mode like the old Delphi. But you can rebuild the IDE with 3 extra packages:



AnchorDockingDsgn - will make IDE windows dockable within one main window

- will make IDE windows dockable within one main window Sparta_DockedFormEditor - will enable you to switch between source code and form designer views like in the modern Delphi, by switching tabs in the main window

- will enable you to switch between source code and form designer views like in the modern Delphi, by switching tabs in the main window Sparta_MDI - new part of Sparta for Lazarus (added since version 1.6), that further enhances single window mode UX On my Raspbery Pi board I use Ubuntu 16.04 with Mate Desktop. It is really just like a regular Ubuntu Desktop, not much particularities like on Ubuntu Touch. So, the use case here is really pretty much exactly same as it is on Ubuntu Desktop. So I will show you few screens of getting Lazarus1.8 built here, but I will provide more detail about this process in the next scenario for Ubuntu Touch instead. So here we go:it takes few moments to checkout the svn repo into the local folder, but then it's pretty much straightforward, especially that on my raspi I already have FPC compiler 3.0.0 installed:the building will take some time, but it will go smoothly, because I already have all the dependencies, since I have previously installed fpc and lazarus on this system from the default repositories (just using apt-get install fpc lazarus).and as soon as the building is complete, lazarus is good to go! I use --pcp switch to define where I want this lazarus version to store its configuration in. I do this because I will have multiple versions of lazarus on this system, and default config path ~/.lazarus is already being used by another installation. This way you can have any number of Lazarus versions on a single system.And I also want to show how to make Lazarus work in a single window mode, like the modern RAD Studio does. By default Lazarus starts in multi window mode like the old Delphi. But you can rebuild the IDE with 3 extra packages:



Lastly, below is (actually uploaded from Raspberry Pi) actual screen showing Lazarus IDE on the Raspberry Pi connected monitor in Ubuntu Mate Desktop:



And this is how the process looks like on our freshly built Lazarus1.8:Lastly, below is (actually uploaded from Raspberry Pi) actual screen showing Lazarus IDE on the Raspberry Pi connected monitor in Ubuntu Mate Desktop:

use-case 2: Ubuntu Touch

I own Meizu MX4 Ubuntu Edition phone, running Ubuntu Touch. It was one of few phones that you could buy with Ubuntu Touch official system image, in a UT branded box and with all the official blows and whistles. Now I have flashed this phone with UT image maintained by UBports, since Canonical abandoned the platform and it is now taken over by a new team. My UT phone is the main device on which I am using ARM version of Lazarus IDE. Because unlike my raspberry pi, I can always carry my UT phone with me, and have access to FPC and Lazarus IDE at my convenience. Interestingly, just like with raspberry pi, same here I can use Lazarus IDE both on device itself, or over ssh with X forwarding. Although the phone screen is small, and touch screen is not a perfect scenario for writing code (especially given the on-screen keyboard), but it is still great for quick cosmetic fixes and re-compiling, especially when on the go. One pretty great hack around the small form factor and OSK, is to connect external keyboard/mouse via OTG. The screen is still tiny, but other than that it becomes very usable. And if you happen to have a tablet with UT, then the screen size becomes much less of an issue. If your phone supports slimport/microHDMI, or wireless streaming to an external monitor, then that's pretty much same level of experience as on raspberry pi.



Lazarus IDE on the phone (portrait and landscape modes): above loging into my Meizu MX4 and starting Lazarus1.8

after rotating the phone using Lazarus in Landscape mode feels like on Desktop

switching from code editor to form designer view to unleash visual RAD on the phone itself!

and now compiling project on the phone itself!

compilation successful! Natively!

now fliping back to portrait mode

in form designer with app that we want to run

and here we are actually running it!

As you can see, I can develop natively on the UT phone, without any SDKs, any cross-compiling, any of those awful QT GUI designers, without any of these things. And now I can even copy the very same project to my Ubuntu Desktop and compile it there as well, without changing anything.

Normally I could even compile this on OSX or WIndows or other platforms too, but in this particular project I made few calls to system shell (fed bash process some commands to execute) so on Windows it would have no effect, since there is no bash (unless cygwin). It's because this app was made with Ubuntu in mind, while my other apps are be more generic.

This scenario is very usable when you connect keyboard/mouse to the phone via USB/OTG. You can then work like on regular Ubuntu desktop, just that the screen is much smaller (sic!). When I don't use it like that, I most of the time use it over ssh instead



Lazarus IDE off the phone onto the desktop: This is a generally a very straightforward and very productive way of using Lazarus IDE on ARM. You install it on the device, and it runs there, but the application interface is being sent over the ssh onto the monitor of your desktop/laptop computer instead. On Linux systems this is as easy as issuing one command (change IP address to match your scenario):

$ ssh -Y phablet@192.168.0.40 start-lazarus1.8 #start-lazarus1.8 is my wrapper script, explained later on On Windows machine you need to have a ssh client (ie.

But with Ubuntu Touch there are some additional steps to make before things are smooth. Unfortunately Canonical when designing UT totally ignored the scenario with X forwarding over ssh. Sure, the UT devices don't use x server, but rather Canonical's proprietary display server called

$ sudo mount -o remount,rw / $ sudo apt-get install xauth $ sudo mount -o remount,ro / only now, upon the first time you ssh into your UT device from another machine with X forwarding turned on ("ssh -X" or "ssh -Y", see



In case you haven't figured that part already, feel free to see my other post on SSH access setup for Ubuntu Touch.



This is Lazarus IDE on my laptop, but it is actually running remotely off my UT phone:



Missing pieces: There are some bits and pieces that I have not so far mentioned, that I have also added to my installation, before it could look like I'm showing it off: packages missing from UT default image #make image writeable: $ sudo mount -o remount,rw / #osk support in Xmir (why wouldn't UT have this by default is beyond me): $ sudo apt-get -q -y install maliit-inputcontext-gtk3 maliit-inputcontext-gtk2 # window manager (optional but very helpful): $ sudo apt-get install matchbox-window-manager # graphical sudo for Xmir (if you want to have gui with root privilege mode): $ sudo apt-get -q -y install gksu #just so that you can even do x forwarding from your phone (how is this even missing??!): $ sudo apt-get -q -y install xauth #reverting image to read-nly: $ sudo mount -o remount,ro /

my customized components for Lazarus

Firstly, Xmir does report constant dpi of 96, which is not the real dpi of the phone. And the

Secondly, the built in scaling like this:

self.AutoAdjustLayout(lapAutoAdjustForDPI, 96, Screen.PixelsPerInch, Self.Width, ScaleX(Self.Width, 96)); does not seem to handle anything besides the bounds of controls (position and size). There are however parts that will not scale, like fonts, like scrollbars. So even if you have a properly scaled TMemo, and if you even scale up the font size in it, on the UT phone the scrollbars in it will remain so tiny, that you barely will be able to use them on touchscreen.

The bottom line is that I begun implementing my own replacements for lazarus standard components, that allow you to freely scale the zoom aspect by flexible float factor. That is why as soon as I start my app it looks good on the screen, because it autoscales itself properly. And it knows when not to scale. This is because I am also providing APIs that are Mir-aware. I can detect whether or not I am running in XMir, or off a mir device but onto x server over ssh. Also I can ask Mir for screen dpi and compare it against what x server/Xmir reports.

I will be publishing these components as open source as soon as I choose licensing for it. For now just experiment with Lazarus on UT on your own terms, and keep checking my blog and my perhaps you noticed that there is a tab on the component palette called "Ubuntu Convergence". These are not standard lazarus components, these are custom ones I wrote. The reason is that a standard app written in lazarus will not scale properly onto phone's high DPI screen scenario. Sure, Lazarus itself has DPI awareness (see: High DPI - Lazarus wiki - Free Pascal wiki ) but there are few problems with it, that I adressed.Firstly, Xmir does report constant dpi of 96, which is not the real dpi of the phone. And the LCL is not Mir-aware, so it won't check for what dpi value it reports.Secondly, the built in scaling like this:does not seem to handle anything besides the bounds of controls (position and size). There are however parts that will not scale, like fonts, like scrollbars. So even if you have a properly scaled TMemo, and if you even scale up the font size in it, on the UT phone the scrollbars in it will remain so tiny, that you barely will be able to use them on touchscreen.The bottom line is that I begun implementing my own replacements for lazarus standard components, that allow you to freely scale the zoom aspect by flexible float factor. That is why as soon as I start my app it looks good on the screen, because it autoscales itself properly. And it knows when not to scale. This is because I am also providing APIs that are Mir-aware. I can detect whether or not I am running in XMir, or off a mir device but onto x server over ssh. Also I can ask Mir for screen dpi and compare it against what x server/Xmir reports.I will be publishing these components as open source as soon as I choose licensing for it. For now just experiment with Lazarus on UT on your own terms, and keep checking my blog and my Source Forge for updates.

lazarus wrapper script #!/bin/sh #I symlinked this script under /usr/bin/start-lazarus1.8 # Absolute path to this script SCRIPT=$(readlink -f $0) SCRIPTPATH=`dirname $SCRIPT` export CurDir=$(pwd) export LAZDIR=$SCRIPTPATH/lazarus-code export MATCHBOX=/usr/bin/matchbox-window-manager echo "LAZDIR=$LAZDIR" cd $LAZDIR if [ -f $MATCHBOX ]; then matchbox-window-manager & ./lazarus --pcp=~/.lazarus1.8 else ./lazarus --pcp=~/.lazarus1.8 fi cd $CurDir



on the bottom, there is no window manager, so the window decorations are missing, andunless the app itself renders its custom ones, there is also no way to resize/drag the app window, and also no control over its size, so it sits randomly within the black client area. and the difference that having window manager installed is this:on top the window manager is installed, and it adds window decorations (title bar, outer boarders), and it also automatically resizes the app window to fit into the entire client area. It resizes automatically if you resize the Xmir window in the windowed mode or when you rotate the screen in the staged mode (about these two modes see: Ubuntu Phone: How I Felt In Love With Windowed Landscape Mode ).on the bottom, there is no window manager, so the window decorations are missing, andunless the app itself renders its custom ones, there is also no way to resize/drag the app window, and also no control over its size, so it sits randomly within the black client area.





As you can see, I can develop natively on the UT phone, without any SDKs, any cross-compiling, any of those awful QT GUI designers, without any of these things. And now I can even copy the very same project to my Ubuntu Desktop and compile it there as well, without changing anything.Normally I could even compile this on OSX or WIndows or other platforms too, but in this particular project I made few calls to system shell (fed bash process some commands to execute) so on Windows it would have no effect, since there is no bash (unless cygwin). It's because this app was made with Ubuntu in mind, while my other apps are be more generic.This scenario is very usable when you connect keyboard/mouse to the phone via USB/OTG. You can then work like on regular Ubuntu desktop, just that the screen is much smaller (sic!). When I don't use it like that, I most of the time use it over ssh insteadThis is a generally a very straightforward and very productive way of using Lazarus IDE on ARM. You install it on the device, and it runs there, but the application interface is being sent over the ssh onto the monitor of your desktop/laptop computer instead. On Linux systems this is as easy as issuing one command (change IP address to match your scenario):On Windows machine you need to have a ssh client (ie. PuTTY ) and an X server (ie xming ). On OSX ssh client is available by default, but you will also need x server (ie. xquartz ).But with Ubuntu Touch there are some additional steps to make before things are smooth. Unfortunately Canonical when designing UT totally ignored the scenario with X forwarding over ssh. Sure, the UT devices don't use x server, but rather Canonical's proprietary display server called Mir (now Canonical abandoned it in favor of Wayland , which it previously said was not suitable for them, which is why they made Mir instead...). I get this, the phone itself doesn't run x server. But when you forward x over ssh you are using x server of another machine, and sending your app interface to it. And this is some legacy Linux tech that has been around for decades now, and it allows for some amazing workflows. Anyways, the long story short, Canonical didn't even add xauth to the UT system image. That tiny tool would allow UT device to auto generate .Xauthority file which would then make x forwarding possible (explained here ). There are plenty of such small tiny elements missing from UT just because people who made it totally ignored some legit scenarios other from what was officially anticipated. These elements are so tiny, that it is obvious they were not left out due to system image size limitations. Now you have to install xauth on UT yourself, manually:only now, upon the first time you ssh into your UT device from another machine with X forwarding turned on ("ssh -X" or "ssh -Y", see What is the difference between ssh -X and ssh -Y ) the xauth tool will kick in to generate Xauthority file that will make things work.In case you haven't figured that part already, feel free to see my other post on SSH access setup for Ubuntu Touch.This is Lazarus IDE on my laptop, but it is actually running remotely off my UT phone:I can start it on my laptop either by typing ssh command manually, or by creating a desktop launcher that I just double click like any regular locally installed app, like so:

use-case 3: All Things Ubuntu (true convergence)



serving Ubuntu desktop experience out of (or into) a phone, a tablet, a single board computer.



Although different from what Canonical was trying to implement, but it actually delivers full desktop experience served out of a phone, a tablet, a single board computer, you name it:



The ultimate use case is when you employ some good old legacy tech like X forwarding over ssh to access software from plethora of devices running Ubuntu on various architectures and form factors, from a single place, that is most convenient for you to work from, like a laptop or a desktop PC. On that single work station you can start software, including GUI apps, remotely from all of your devices. A true, distributed ecosystem of devices. That, to me, is the true convergence:Although different from what Canonical was trying to implement, but it actually delivers full desktop experience served out of a phone, a tablet, a single board computer, you name it:



Switching widgetsets

"(...) [What widgetset is used for GUI] That is the neat part. You decide. Lazarus is being developed to be totally and completely API independent. Once you write your code you just link it against the API widget set of your choice. If you want to use GTK+, great! If you want it to be Gnome compliant, great! As long as the interface code for the widget set you want to use is available you can link to it. If it isn't available, well you can write it.





For example. Let's say you are creating a product on Windows using the standard Windows widgets. Now you want to create a Linux version. First you decide what widget set you want to use. Let's assume you want to use gtk+. So you copy the code over to your Linux development machine, compile, and link against the gtk+ interface unit. That's it. You've now just created a Linux version of the Windows product without any additional coding.(...)"



The way you choose widget set to use with your application, is by simply navigating to Project > Project Options... > Config and Target: then you click on the blue link "Select another LCL widgetset (macro LCLWidgetType)" and add an override to the LCL widgetset variable (default on linux is gtk2): as you can see thee is a comprehensive list to choose from, but I will focus on gtk and qt only, for these are main choices to consider on Linux. source: www.lazarus-ide.org

Gtk2 This is the default widget set used by Lazarus on Linux. If you didn't do any custom configuration, your apps will be linked against it.

Also, you almost certainly have this widgetset installed on your system, but in some instances you might be missing development packages which are used by developer not users, to be linked against by the program during during compilation, and if you in deed are missing them, this is how you get them on Ubuntu:

$ sudo apt-get install libgtk2.0-dev libgdk-pixbuf2.0-dev #there may be more needed, but at least these 2 you definitely want!

Gtk3 This is much newer version of Gtk widget set, and most recent Lazarus has pretty good support since the bindings are pretty complete. Just like with gtk2, you also need to have packages installed that provide libraries to link gtk3 to your application during compilation:

$ sudo apt-get install libgtk-3-dev and on UT the package reports just under 19MB space needed, so on raspberry pi should be within a fairly similar range. Here are screenshots of me trying to compile my app on Ubuntu TOuch against gtk3:

the first attempt failed during linking, because libraries were not found the libgtk-3-dev on UT requested 19MB of disk space, so far so good the installation went smoothly, no surprises here now I tried compiling again, and it was full success! the app compiles and runs! The GUI appears different with gtk3 too!

worth noticing is that the compiled gtk3 app will not run via xmir on UT phone, only when forwarded over ssh to remote x server. Apparently gtk libraries need to be slightly modified to play well with XMir, and that is why UT default image provides gtk2 libraries for x11 display server - so that Xmir can use those to run legacy apps, which was meant to be used in the Canonical's convergence mode. At least before this happened: Canonical kills its Ubuntu smartphone, tablet, convergence plans

Unity is dead: Ubuntu ditches phone convergence dreams and returns to Gnome

Ubuntu convergence implodes There was some noble idea that even got awarded: Canonical, Not Microsoft, Wins Convergence Award

Canonical wins Orange Award for Converged Computing at MWC 17

Ubuntu convergence finally impresses me Anyways, now it is uncertain how things will move on, on one hand UBports continues the UT maintenance and development, including Mir and XMir, and the convergence may still be worked on. On the other hand, now that Canonical switches to Gnome/Wayland, it is not impossible that they will try to achieve the original goal of convergence over that technology further down the road. For now, the closest we get to the converged experience, IMHO, is by good old X forwarding over SSH. That is as far as we want something immediately available, something that is a legacy tech built into the Linux OS by default. But what I am also interested in exploring more is VNC as, an arguably faster alternative to X forwarding: VNC: A Faster Alternative to X11

Why is VNC so much faster than X Forwarding (both tunneled)?

Qt4 Qt4 was the very first version of qt supported by Lazarus. I once had an entire lazarus IDE built as qt4 app, and it was okay. You definitely can go and try, some people claim that qt4 widgetset provides faster/smoother/more responsive experience, and that gtk2 has some bad limitations, but I never dove into details enough to have an opinion in that discussion, and I have been pretty happy with gtk2 except for few very specific problems related to drawing graphics using LCL's TCanvas class. These problems dealt with the fact that TCanvas methods fro drawing graphics into a graphical device were not thread safe because of some particular way of how device handles were allocated and perhaps related canvas locking mechanisms. It made offscreen bitmap rendering not being possible to happen fully asynchronously with Lazarus TCanvas model when using gtk2 (but was fine on windows platform with windows widgets used). And I have not yet tested this specific category of limitation with gtk3, so I don't really know whether or not it also applies there.

All in all, I am not an evangelist for qt4. On one hand, it requires you to deal with some prerequisites before you can use pascal bindings, yet on the other hand qt4 is not widely available on modern systems. It seems like the world has movd forward beyond qt4 by the time Lazarus made stable bindings for it. Especially in the arm linux world, with smartphones and tablets as an anticipated range of devices to grow market share, I don't think anyone will still look back at qt4. But time will show. Since I have not bothered to personally test qt4 on arm, let me just point you to some related documentation:



Qt5 Now this is something that I am looking forward to adopting more.Qt5 is something that has been long coming to Lazarus. For long, the qt5 bindings were considered to be in alpha stage, but now there are anouncements that qt5 is going to land officially in the next stable release 1.8 of Lazarus IDE. And I have already seen it listed in the available widgetsets menu in the most recent Lazarus 1.8 RC5 (RC stands for release candidate).

Some official documentation is available here:

And it says that qt5.6.2 is tested, and also it is generally being mentioned in multiple places around the Internet (and in the documentations) that qt5 support in Lazarus is aimed at qt5 versions equal or greater than 5.6, which is a bit unfortunate to Ubutu Touch. Current stabl release of UT is based on Ubuntu 15.04 image, and the qt version is reportedly 5.4 (I was told in the

Anyways, the assumption about qt version was made based on the qt5 version default to Ubuntu 15.04 Vivid distribution. And also users who used Libertine container on UT phones have installed qmake in it, and that was also the qt version reported. I was given a great advice by @DanChapman (Telegram), that I can always just check what's in the overlay ppa for vivid for what qt packages are available and in which versions. Here are the qtbase ones on

But why to wonder, if you can actually check and know the answer? I just installed qt5-qmake on the phone itself and... it was such a small installation that apt-get didn't even ask me for any confirmation:



Because UT has qt5 in version lower than 5.6, so I do not expect it to work with qt5 bindings provided by lazarus, but since I just installed qmake on UT, I can show you the steps needed for building the bindings. At the end, I might not be able to use them on UT, but if you are building the environment on another device (ie. Raspberry Pi with Ubuntu Mate) then you would follow same steps, and depending on your Ubuntu version you may have just the right version of qt5 to make these things work.

The information about building Pascal Qt interfce from sources is supplied with Lazarus itself, and it is to be fund in the file lcl/interfaces/qt5/cbindings/README.txt , which is a relative path to wherever you have your lazarus installed to, and for the Linux part the important content from my Lazarus1.8 is:

Compile Pascal Qt Interface from source: ======================================== * Download and unpack the sources * cd into the resulting unpacked directory * This directory contains amongs other things a Qt Project File Qt5Pas.pro * run qmake -query to inspect your Qt installation * qmake (creates Makefile based upon Qt5Pas.pro) * make (compiles) * make install (obtain super user rights with sudo or su) * make clean (cleans directory, do this when switching Qt versions) Linux Note: ----------- To use a different Qt then the system wide Qt, use /PathToOtherQt/bin/qmake and learn about LD_LIBRARY_PATH (export LD_LIBRARY_PATH=/PathToOtherQt/lib) (...) Installation ============ When compiling from source, you can use make install. When using the binary packages, see below. If preferred, first strip the libraries before installation. Linux Binary Installation ------------------------- The libraries should be copied to the distribution specific system library directory e.g. /usr/lib. Ensure the symlinks are correct. The .so.OneDigit link is used when running a program.(google soname) The .so link is used when linking during development (...) so let's start, on my phone the lazarus is checked-out from the official svn to ~/Downloads/Laz1.8/lazarus-code/ , so I go like ths:

#the beginning: $ cd ~/Downloads/Laz1.8/lazarus-code/ #going into building directory: $ cd lcl/interfaces/qt5/cbindings/ $ qake --query and I get this output:

QT_SYSROOT: QT_INSTALL_PREFIX:/usr QT_INSTALL_ARCHDATA:/usr/lib/arm-linux-gnueabihf/qt5 QT_INSTALL_DATA:/usr/share/qt5 QT_INSTALL_DOCS:/usr/share/qt5/doc QT_INSTALL_HEADERS:/usr/include/arm-linux-gnueabihf/qt5 QT_INSTALL_LIBS:/usr/lib/arm-linux-gnueabihf QT_INSTALL_LIBEXECS:/usr/lib/arm-linux-gnueabihf/qt5/libexec QT_INSTALL_BINS:/usr/lib/arm-linux-gnueabihf/qt5/bin QT_INSTALL_TESTS:/usr/tests QT_INSTALL_PLUGINS:/usr/lib/arm-linux-gnueabihf/qt5/plugins QT_INSTALL_IMPORTS:/usr/lib/arm-linux-gnueabihf/qt5/imports QT_INSTALL_QML:/usr/lib/arm-linux-gnueabihf/qt5/qml QT_INSTALL_TRANSLATIONS:/usr/share/qt5/translations QT_INSTALL_CONFIGURATION:/etc/xdg QT_INSTALL_EXAMPLES:/usr/lib/arm-linux-gnueabihf/qt5/examples QT_INSTALL_DEMOS:/usr/lib/arm-linux-gnueabihf/qt5/examples QT_HOST_PREFIX:/usr QT_HOST_DATA:/usr/lib/arm-linux-gnueabihf/qt5 QT_HOST_BINS:/usr/lib/arm-linux-gnueabihf/qt5/bin QT_HOST_LIBS:/usr/lib/arm-linux-gnueabihf QMAKE_SPEC:linux-g++ QMAKE_XSPEC:linux-g++ QMAKE_VERSION:3.0 QT_VERSION:5.4.1 I inspect, before I move on:

#creates Makefile based upon Qt5Pas.pro file: $ qmake and this is where I see that the qt version on the UT is too low for building my bindings, as they require newer qt:

Project MESSAGE: Note: This binding version was generated for Qt 5.6.1. Current Qt is 5.4.1 Project MESSAGE: Qt documents binary compatibility in each Version Change Note: http://qt.nokia.com/developer/changes Project MESSAGE: Adding x11extras for XOrg platform. Project MESSAGE: Pascal Qt Interface for binding platform: BINUX Project MESSAGE: Install location: /usr/lib/arm-linux-gnueabihf Project ERROR: Unknown module(s) in QT: x11extra so I move on to my raspberry pi, and continue just where I left off:

it's crazy how easy these things are on Linux, when with ssh you just jump from one device to another without moving away from in front of your laptop! I was in Ubuntu Touch phone in one moment, and in another I m inside raspberry pi, and all that from the comfort of my laptop! So let's contnue:

#the beginning: $ cd ~/Downloads/Laz1.8/lazarus-code/ #going into building directory: $ cd lcl/interfaces/qt5/cbindings/ #creates Makefile based upon Qt5Pas.pro file: $ qmake #compile: $ make #errors happened, so I install qt5 dependencies: $ sudo apt install qtbase5-dev $ sudo apt install libqt5webkit5-dev $ sudo apt-get install libqt5x11extras5-dev #now we have two versions of qmake: #so we need to call the higer version explicitely: $ /usr/lib/arm-linux-gnueabihf/qt5/bin/qmake #and then we can finally build it: $ make #it will take some time to compile, perhaps you can have a brunch or dinner :D and the building begins...







Known issues

debugger - on both the raspberry pi and Ubuntu Touch phone I was not able to run compiled programs from the IDE due to debugger causing SIGSEGV memory violation exception. Perhaps the gdb needs to be updated to another version, or perhaps downgraded, I didn't investigate this, and I just disabled debugging entirely, because I can always copy my project to my Ubuntu Desktop for debugging if I really need to.

- on both the raspberry pi and Ubuntu Touch phone I was not able to run compiled programs from the IDE due to debugger causing SIGSEGV memory violation exception. Perhaps the gdb needs to be updated to another version, or perhaps downgraded, I didn't investigate this, and I just disabled debugging entirely, because I can always copy my project to my Ubuntu Desktop for debugging if I really need to. big executable size - this one is actually a feture, and something you need to know about. When Lazarus compiles your program it also, by default, adds debuggind information to the binary file, that enables debugging, but increases binary size drastically. There are 2 ways to handle this, you just need to remember that this is something to know about. Traditionally Linux has a strip command that you can strip any executable off the debugging information data, and the file size will be significantly smaller. But Lazarus IDE also allows you to configure the project in such a way, that the debugging information will be stored in a separate file instead of being added to the binary file. That way you won't forget to strip your files. You can set this in the IDE's Project > Project Options... > Compiler Options > Debugging, and check the option called Use external gdb debug symbols file (-Xg) :

- this one is actually a feture, and something you need to know about. When Lazarus compiles your program it also, by default, adds debuggind information to the binary file, that enables debugging, but increases binary size drastically. There are 2 ways to handle this, you just need to remember that this is something to know about. Traditionally Linux has a command that you can strip any executable off the debugging information data, and the file size will be significantly smaller. But Lazarus IDE also allows you to configure the project in such a way, that the debugging information will be stored in a separate file instead of being added to the binary file. That way you won't forget to strip your files. You can set this in the IDE's Project > Project Options... > Compiler Options > Debugging, and check the option called : code editor not working with osk on UT - on Ubuntu Touch platform, the code editor window does not trigger the on-screen keyboard to appear. Every other text input control of Lazarus IDE works propetly, except for the code editor. This is why I only edit code on UT in the on-screen scenario with an external keyboard connected to the phone via OTG USB

- on Ubuntu Touch platform, the code editor window does not trigger the on-screen keyboard to appear. Every other text input control of Lazarus IDE works propetly, except for the code editor. This is why I only edit code on UT in the on-screen scenario with an external keyboard connected to the phone via OTG USB UT window manager - on UT platform gtk2 apps are run via Xmir, which emulates x11 server to the app, but does not provide any window manager. You can off course install some window manager manually and call it before calling your app. There are some very light window managers available on Linux, and one called matchbox-window-manager has been mentioned in the use-case 2: Ubuntu Touch chapter.

- on UT platform gtk2 apps are run via Xmir, which emulates x11 server to the app, but does not provide any window manager. You can off course install some window manager manually and call it before calling your app. There are some very light window managers available on Linux, and one called matchbox-window-manager has been mentioned in the use-case 2: Ubuntu Touch chapter. Delayed touch screen initialization on UT - every time I start gtk2 app on my UT phone directly via Xmir, the very first touch click event never seems to work. Only beginning from the 2nd time I click on my app it works. Not a deal breaker, but it is a bit annoying at times. Not sure if this is Xmir fault or something with the app itself.

- every time I start gtk2 app on my UT phone directly via Xmir, the very first touch click event never seems to work. Only beginning from the 2nd time I click on my app it works. Not a deal breaker, but it is a bit annoying at times. Not sure if this is Xmir fault or something with the app itself. QT version - in the Switching widgetsets chapter I mentionned qt4 and qt5 widgetsets. Although Lazarus1.8 is supposed to support both, but in reality there are some probems linking the app against qt5 bindings at the end of compilation probably due to some difference in the minor versions of qt5 installed on the system. I am yet to actually build and run qt5 app successfully, while at the same time I am not very interested in qt4. This is the default widget set used by Lazarus on Linux. If you didn't do any custom configuration, your apps will be linked against it.Also, you almost certainly have this widgetset installed on your system, but in some instances you might be missing development packages which are used by developer not users, to be linked against by the program during during compilation, and if you in deed are missing them, this is how you get them on Ubuntu:This is much newer version of Gtk widget set, and most recent Lazarus has pretty good support since the bindings are pretty complete. Just like with gtk2, you also need to have packages installed that provide libraries to link gtk3 to your application during compilation:and on UT the package reports just under 19MB space needed, so on raspberry pi should be within a fairly similar range. Here are screenshots of me trying to compile my app on Ubuntu TOuch against gtk3:Qt4 was the very first version of qt supported by Lazarus. I once had an entire lazarus IDE built as qt4 app, and it was okay. You definitely can go and try, some people claim that qt4 widgetset provides faster/smoother/more responsive experience, and that gtk2 has some bad limitations, but I never dove into details enough to have an opinion in that discussion, and I have been pretty happy with gtk2 except for few very specific problems related to drawing graphics using LCL's TCanvas class. These problems dealt with the fact that TCanvas methods fro drawing graphics into a graphical device were not thread safe because of some particular way of how device handles were allocated and perhaps related canvas locking mechanisms. It made offscreen bitmap rendering not being possible to happen fully asynchronously with Lazarus TCanvas model when using gtk2 (but was fine on windows platform with windows widgets used). And I have not yet tested this specific category of limitation with gtk3, so I don't really know whether or not it also applies there.All in all, I am not an evangelist for qt4. On one hand, it requires you to deal with some prerequisites before you can use pascal bindings, yet on the other hand qt4 is not widely available on modern systems. It seems like the world has movd forward beyond qt4 by the time Lazarus made stable bindings for it. Especially in the arm linux world, with smartphones and tablets as an anticipated range of devices to grow market share, I don't think anyone will still look back at qt4. But time will show. Since I have not bothered to personally test qt4 on arm, let me just point you to some related documentation: Qt4 binding - Free Pascal wiki Now this is something that I am looking forward to adopting more.Qt5 is something that has been long coming to Lazarus. For long, the qt5 bindings were considered to be in alpha stage, but now there are anouncements that qt5 is going to land officially in the next stable release 1.8 of Lazarus IDE. And I have already seen it listed in the available widgetsets menu in the most recent Lazarus 1.8 RC5 (RC stands for release candidate).Some official documentation is available here: Qt5 Interface - Free Pascal wiki And it says that qt5.6.2 is tested, and also it is generally being mentioned in multiple places around the Internet (and in the documentations) that qt5 support in Lazarus is aimed at qt5 versions equal or greater than 5.6, which is a bit unfortunate to Ubutu Touch. Current stabl release of UT is based on Ubuntu 15.04 image, and the qt version is reportedly 5.4 (I was told in the UBports Supergroup ). But it is expected that it will be updated to version 5.9, by which time I hope I can have a production ready workflow to make native Mir apps with lazarus using qt5 widgets, and effectively moving beyond the requirement for Xmir. That should give me access to accelerated graphics.Anyways, the assumption about qt version was made based on the qt5 version default to Ubuntu 15.04 Vivid distribution. And also users who used Libertine container on UT phones have installed qmake in it, and that was also the qt version reported. I was given a great advice by @DanChapman (Telegram), that I can always just check what's in the overlay ppa for vivid for what qt packages are available and in which versions. Here are the qtbase ones on Launchpad But why to wonder, if you can actually check and know the answer? I just installed qt5-qmake on the phone itself and... it was such a small installation that apt-get didn't even ask me for any confirmation:and now I can finally confirm that the version on the current vivid based (15.04) Ubuntu Touch is 5.4.1 - finally no assumcasptions. Wow, that was quick!Because UT has qt5 in version lower than 5.6, so I do not expect it to work with qt5 bindings provided by lazarus, but since I just installed qmake on UT, I can show you the steps needed for building the bindings. At the end, I might not be able to use them on UT, but if you are building the environment on another device (ie. Raspberry Pi with Ubuntu Mate) then you would follow same steps, and depending on your Ubuntu version you may have just the right version of qt5 to make these things work.The information about building Pascal Qt interfce from sources is supplied with Lazarus itself, and it is to be fund in the file, which is a relative path to wherever you have your lazarus installed to, and for the Linux part the important content from my Lazarus1.8 is:so let's start, on my phone the lazarus is checked-out from the official svn to, so I go like ths:and I get this output:I inspect, before I move on:and this is where I see that the qt version on the UT is too low for building my bindings, as they require newer qt:so I move on to my raspberry pi, and continue just where I left off:and the building begins...and done! We have successfully built Qt5 bindings for Lazarus! At this moment we should be able to use qt5 widgetset in lazarus:and the compilation went thru, but linking at the end failed. I only suspect that it might be because the actual qt5 version on the system is lower than expectet v5.6, as you can see again:true, it's been a while since I made full system upgrade on my raspi, so perhaps just running apt-get update and apt-get upgrade will get me nowere qt5 version, and maybe then (perhaps even I will need to build the PasQt5 bindings again). And just MAYBE, I will even be able to move the compiled .so libraries that linker accepts over to the UT phone and get them to work. But for now, I just stop at this stage, where you should have understanding of what is needed before you can build qt5 apps with lazarus.





Lazarus IDE runs on plethora of platforms but today we focus on ARM Linux: Embedded Linux, single board computers, smartphones and tablets. Native visual RAD development on ARM Linux.I wrote this post with the aspiration for it to become the most comprehensive practical guide for Lazarus IDE, and effectively Object Pascal software development on and for ARM Linux, but with focus specifically on Ubuntu.