Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What would be a pratical example of sysroot and prefix options for Qt

I'm looking at all the options that can be run for the configure script provided with Qt. (specifically qt-everywhere-opensource-src-5.2.0).

After considerable searching, I've determined this stuff is poorly documented at best so I was hoping I could get some help. When I look at the descriptions for prefix and sysroot configuration options:

~/qt-everywhere-opensource-src-5.2.0$ ./configure -help | grep "sysroot"
-extprefix <dir> ... When -sysroot is used, install everything to <dir>,
-sysroot <dir> ...... Sets <dir> as the target compiler's and qmake's sysroot and also sets pkg-config paths.
-no-gcc-sysroot ..... When using -sysroot, it disables the passing of --sysroot to the compiler

~/qt-everywhere-opensource-src-5.2.0$ ./configure -help | grep "prefix"
-prefix <dir> ...... This will install everything relative to <dir>
-extprefix <dir> ... When -sysroot is used, install everything to <dir>,
-hostprefix [dir] .. Tools and libraries needed when developing

So I've used -prefix before, and it did exactly as described. It placed everything at the provided <dir>, then when I built my application using <prefix_dir>/bin/qmake and installed that on my target platform it wanted to find all the shared object libraries at <prefix_dir>/lib.

I'm under the impressions that if I use -sysroot it will install everything at <sysroot_dir> then when I install my application on the target platform it will search in /lib. At least I hope that's true.

Now if my assumption is correct... then what's the point of -extprefix? Are they saying that if I can redirect where things good if I use both -sysroot and -extprefix?

And what would be a reason why I would want to use -no-gcc-sysroot? If I wanted my Qt libs to be installed at "sysroot" why wouldn't I want gcc to use/know the same sysroot?

An explanation of some of these would be great, even better if I can get some practical examples of how to correctly use these options.

like image 316
Mike Avatar asked Mar 20 '14 17:03

Mike


2 Answers

These are options that are used when building embedded platforms. Yes they are a royal mess. So here's only a partial answer:

-prefix

  • tried and proven way to say /usr/lib instead of /usr/local/lib or similar for the entire installation of Qt
  • when Qt is built for the platform it is currently running on (typical for desktop)

-sysroot /path

  • intends to build Qt for a system which isn't installed at /
  • for example -sysroot ~/mysystem where ~/myssytem contains /lib /bin etc...
  • will pass --sysroot to other tools, like gcc and pkg-config, so they will search for their dependencies in ~/mysystem/lib rather than /lib

-extprefix /b

  • when using -sysroot /a, don't actually write to /a
  • write qt to /b instead
  • this is intended for cross-compiling against read-only sysroots

-no-gcc-sysroot

  • very specific hack for compilers that can't find their own crt inside --sysroot
  • passes sysroot to pkgconfig and others, but not to gcc
  • so that gcc will be called with -L/sysroot/lib/ correctly, but doesn't try to find implicit paths (crt) here.

-hostprefix /path

  • when compiling for a different target than we are currently running on
  • qmake will be the host architecture (for example x86) and qt itself will be the target architecture (lets say arm)
  • so put qmake in /path instead of the target system specified by -sysroot. it won't be any useful on the target system

To add to the confusion:

-R /path

  • sets the linkers runpath - which is where QtGui finds QtCore for example - independant of all the other options

Which flags you want to use when compiling for a target not your host, depends on a boatload of hardcoded assumptions inside configure.

generally -sysroot plus -prefix should work for most use cases.

i.e. when you have:

 $ ls ~/mytarget
 lib bin share dev

you could just use -sysroot ~/mytarget -prefix /

like image 161
aep Avatar answered Sep 29 '22 21:09

aep


One practical example would be cross compiling Qt for Raspberry Pi and then creating a "sister" kit to add to Qt Creator.

The following command install Qt on the Pi after mounting the Pi's root filesystem:

    ./configure -opengl es2 -device linux-rasp-pi-g++ -device-option CROSS_COMPILE=$RPI_TOOLCHAIN -sysroot $RPI_SYSROOT -opensource -confirm-license -optimized-qmake -reduce-exports -release -make libs -prefix /usr/local/qt-5.5.1-pi -skip qtwebkit

The following command then installs the binaries on the desktop by using Pi's root file system.

    ./configure -opengl es2 -device linux-rasp-pi-g++ -device-option CROSS_COMPILE=$RPI_TOOLCHAIN -sysroot $RPI_SYSROOT -opensource -confirm-license -optimized-qmake -reduce-exports -release -make libs -extprefix /usr/local/qt-5.5.1-pi -skip qtwebkit

Note that the only difference is the use of -extprefix instead of -prefix which directs the installation location.

Note: You can install Qt on host and target simultaneously by specifying both prefix and extprefix in the same line

Now you can add this kit to your Qt Creator by specifying your qmake path, device, compiler, debugger and sysroot. So you can create a qt project on your desktop and then build and run on either the desktop or the pi depending on the kit you choose.

like image 35
kingvittu Avatar answered Sep 29 '22 23:09

kingvittu