• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login
UBports Robot Logo UBports Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login

Building on device with small root partition

Scheduled Pinned Locked Moved App Development
22 Posts 3 Posters 4.0k Views 3 Watching
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • D Offline
      dobey @anhilde
      last edited by dobey 2 Jan 2021, 16:35 1 Feb 2021, 16:34

      @anhilde said in Building on device with small root partition:

      However if I do this, the packet installation always fails with the message, that the package installation requires root access:

      You need to enter the libertine container differently so that you are using it as "root" like so:

      libertine-container-mainager exec -i <containerid> -c bash

      This will give you a "root" prompt inside the container, and you should be able to use apt build-dep then (assuming you did not install sudo in the container).

      After that, you can exit the "root" prompt, and run the standard container shell normally, to be able to build the packages.

      A 1 Reply Last reply 1 Feb 2021, 18:34 Reply Quote 0
      • A Offline
        anhilde @dobey
        last edited by 1 Feb 2021, 18:34

        @dobey Thanks, that was the missing link to getting the container set up. However the tests still fail with the libGLESv2.so.2 issue, same as I had before when trying with the "manually" configured container:

        [100%] Linking CXX shared module libubuntu-contacts-qml.so
        cd /home/phablet/address-book-app/obj-arm-linux-gnueabihf/src/imports/Ubuntu/Contacts && /usr/bin/cmake -E cmake_link_script CMakeFiles/ubuntu-contacts-qml.dir/link.txt --verbose=1
        /usr/bin/arm-linux-gnueabihf-g++  -fPIC -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -std=c++11 -Wall  -Wl,-Bsymbolic-functions -Wl,-z,relro -shared  -o libubuntu-contacts-qml.so CMakeFiles/ubuntu-contacts-qml.dir/contacts.cpp.o CMakeFiles/ubuntu-contacts-qml.dir/imagescalethread.cpp.o CMakeFiles/ubuntu-contacts-qml.dir/plugin.cpp.o CMakeFiles/ubuntu-contacts-qml.dir/simcardcontacts.cpp.o CMakeFiles/ubuntu-contacts-qml.dir/ubuntu-contacts-qml_automoc.cpp.o -lqofono-qt5 /usr/lib/arm-linux-gnueabihf/libQt5Contacts.so.5.0.0 /usr/lib/arm-linux-gnueabihf/libQt5Quick.so.5.12.9 /usr/lib/arm-linux-gnueabihf/libQt5DBus.so.5.12.9 /usr/lib/arm-linux-gnueabihf/libQt5Qml.so.5.12.9 /usr/lib/arm-linux-gnueabihf/libQt5Network.so.5.12.9 /usr/lib/arm-linux-gnueabihf/libQt5Gui.so.5.12.9 /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5.12.9 
        make[3]: Leaving directory '/home/phablet/address-book-app/obj-arm-linux-gnueabihf'
        [100%] Built target ubuntu-contacts-qml
        make[2]: Leaving directory '/home/phablet/address-book-app/obj-arm-linux-gnueabihf'
        /usr/bin/cmake -E cmake_progress_start /home/phablet/address-book-app/obj-arm-linux-gnueabihf/CMakeFiles 0
        make[1]: Leaving directory '/home/phablet/address-book-app/obj-arm-linux-gnueabihf'
           dh_auto_test -O--parallel -O--fail-missing
        	make -j2 test ARGS\+=-j2
        make[1]: Entering directory '/home/phablet/address-book-app/obj-arm-linux-gnueabihf'
        Running tests...
        /usr/bin/ctest --force-new-ctest-process -j2
        Test project /home/phablet/address-book-app/obj-arm-linux-gnueabihf
            Start 1: contact_list
            Start 2: Contact_list_model
        1/9 Test #2: Contact_list_model ...............***Failed    2.20 sec
        /usr/lib/arm-linux-gnueabihf/qt5/bin/qmltestrunner: error while loading shared libraries: libGLESv2.so.2: cannot open shared object file: No such file or directory
        
        D 1 Reply Last reply 1 Feb 2021, 19:09 Reply Quote 0
        • D Offline
          doniks @anhilde
          last edited by doniks 2 Jan 2021, 19:11 1 Feb 2021, 19:09

          @anhilde maybe you need to install more stuff

          maybe libgles2-mesa-dev https://packages.ubuntu.com/search?suite=groovy&arch=any&mode=filename&searchon=contents&keywords=libGLESv2

          A 1 Reply Last reply 1 Feb 2021, 19:30 Reply Quote 0
          • A Offline
            anhilde @doniks
            last edited by 1 Feb 2021, 19:30

            @doniks I would have though, that that should be taken care off by:

            apt build-dep
            

            Is that assumption wrong? Nore, I'm not trying to get this working somehow, but rather want to try and understand how the application development process is intended.

            D 1 Reply Last reply 2 Feb 2021, 18:24 Reply Quote 0
            • A Offline
              anhilde
              last edited by 2 Feb 2021, 07:57

              Hi, I have a problem understanding, how the (if?) the build application should be runnable from within the container. When the build runs the tests I assume it uses the executable address-book-app found in the project tree.

              phablet@ubuntu-phablet:~/address-book-app/obj-arm-linux-gnueabihf$ ./src/app/address-book-app 
              ./src/app/address-book-app: error while loading shared libraries: libGLESv2.so.2: cannot open shared object file: No such file or directory
              phablet@ubuntu-phablet:~/address-book-app/obj-arm-linux-gnueabihf$ ldd ./src/app/address-book-app 
              	libQt5Gui.so.5 => not found
              	libQt5Qml.so.5 => not found
              	libgcc_s.so.1 => not found
              	libstdc++.so.6 => not found
              	libQt5Core.so.5 => not found
              	libQt5Network.so.5 => not found
              	/lib/ld-linux-armhf.so.3 => /lib/ld-linux-armhf.so.3 (0x00000000)
              	libQt5DBus.so.5 => not found
              	libQt5Quick.so.5 => not found
              	libc.so.6 => not found
              
              

              Since that is not directly linked to libGLESv2.so.2 my assumption was that this dependency comes in via libQTGui.so.5. Why is this not found?

              If I search for it logged into the container as root I find libQt5Gui.so.5:

              root@ubuntu-phablet:/# ldd /usr/lib/arm-linux-gnueabihf/libQt5Gui.so.5
              	linux-gate.so.1 =>  (0x00000000)
              	libfakeroot-sysv.so => /usr/lib/arm-linux-gnueabihf/libfakeroot/libfakeroot-sysv.so (0x00000000)
              	libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x00000000)
              	libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x00000000)
              	/lib/ld-linux-armhf.so.3 => /lib/ld-linux-armhf.so.3 (0x00000000)
              	libfakechroot.so => /usr/lib/arm-linux-gnueabihf/fakechroot/libfakechroot.so (0x00000000)
              	libQt5Core.so.5 => /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5 (0x00000000)
              	libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x00000000)
              	libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0x00000000)
              	libicui18n.so.55 => /usr/lib/arm-linux-gnueabihf/libicui18n.so.55 (0x00000000)
              	libicuuc.so.55 => /usr/lib/arm-linux-gnueabihf/libicuuc.so.55 (0x00000000)
              	libicudata.so.55 => /usr/lib/arm-linux-gnueabihf/libicudata.so.55 (0x00000000)
              	libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0x00000000)
              	libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x00000000)
              	libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x00000000)
              	libpcre2-16.so.0 => /usr/lib/arm-linux-gnueabihf/libpcre2-16.so.0 (0x00000000)
              	libdouble-conversion.so.1 => /usr/lib/arm-linux-gnueabihf/libdouble-conversion.so.1 (0x00000000)
              	libglib-2.0.so.0 => /lib/arm-linux-gnueabihf/libglib-2.0.so.0 (0x00000000)
              	libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0x00000000)
              	libGLESv2.so.2 => /usr/lib/arm-linux-gnueabihf/mesa-egl/libGLESv2.so.2 (0x00000000)
              	libglapi.so.0 => /usr/lib/arm-linux-gnueabihf/libglapi.so.0 (0x00000000)
              	libpng12.so.0 => /lib/arm-linux-gnueabihf/libpng12.so.0 (0x00000000)
              	libharfbuzz.so.0 => /usr/lib/arm-linux-gnueabihf/libharfbuzz.so.0 (0x00000000)
              	libfreetype.so.6 => /usr/lib/arm-linux-gnueabihf/libfreetype.so.6 (0x00000000)
              	libgraphite2.so.3 => /usr/lib/arm-linux-gnueabihf/libgraphite2.so.3 (0x00000000)
              

              And libGLESv2.so.2 is available under the path reported by ldd and it reports:

              root@ubuntu-phablet:/usr/lib/arm-linux-gnueabihf/mesa-egl# ldd libGLESv2.so.2
              	linux-gate.so.1 =>  (0x00000000)
              	libfakeroot-sysv.so => /usr/lib/arm-linux-gnueabihf/libfakeroot/libfakeroot-sysv.so (0x00000000)
              	libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x00000000)
              	libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x00000000)
              	/lib/ld-linux-armhf.so.3 => /lib/ld-linux-armhf.so.3 (0x00000000)
              	libfakechroot.so => /usr/lib/arm-linux-gnueabihf/fakechroot/libfakechroot.so (0x00000000)
              	libglapi.so.0 => /usr/lib/arm-linux-gnueabihf/libglapi.so.0 (0x00000000)
              	libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x00000000)
              

              Does anybody have a clue why then the tests fail with the message that libGLESv2.so.2 is missing? Note I do have dyslexia, so if there is an obvious name mix up here, please let me know.

              D 1 Reply Last reply 2 Feb 2021, 15:49 Reply Quote 0
              • D Offline
                dobey @anhilde
                last edited by 2 Feb 2021, 15:49

                @anhilde Well GLES2 is there. There does seem to be a weird issue though, since it's not finding the libs when using the container normally. Especially odd given that it compiled and only failed when trying to run the tests.

                As for what is run for the tests, no, it is not running the address book app itself, but other tests binaries, or qmltestrunner for QML tests.

                1 Reply Last reply Reply Quote 0
                • D Offline
                  doniks @anhilde
                  last edited by doniks 2 Feb 2021, 18:24 2 Feb 2021, 18:24

                  @anhilde said in Building on device with small root partition:

                  @doniks I would have though, that that should be taken care off by:

                  apt build-dep
                  

                  Is that assumption wrong?

                  I would have assumed the same yes ...

                  Nore, I'm not trying to get this working somehow, but rather want to try and understand how the application development process is intended.

                  Understood. And very much appreciated! I was just thinking maybe there is a genuine bug in the dependencies.

                  Full disclosure, I've never done this on-device build myself. I'm just thinking out loud here.

                  Also, I just notice that there are two packages that have this lib: mesa and hybris. Maybe you actually need the other one. Or a related thought: Maybe you can run the tests from OUTSIDE the container, after the building INSIDE is complete.

                  D 1 Reply Last reply 2 Feb 2021, 19:28 Reply Quote 0
                  • D Offline
                    dobey @doniks
                    last edited by 2 Feb 2021, 19:28

                    @doniks said in Building on device with small root partition:

                    , after the building INSIDE is complete.

                    The build is incomplete, because the tests failed to run.

                    A D 2 Replies Last reply 2 Feb 2021, 19:59 Reply Quote 0
                    • A Offline
                      anhilde @dobey
                      last edited by 2 Feb 2021, 19:59

                      @dobey I cannot get the build to run. I always end up with the libGLESv2.so.2 problem. I actually tried installing all packages via:

                      libertine-container-manager install-package -p $ALLPACKS_FROM_APT_BUILD_DEP_COMMAND
                      

                      The very first build fails with:

                      phablet@ubuntu-phablet:~/address-book-app$ DEB_BUILD_OPTIONS="parallel=2 debug" dpkg-buildpackage -rfakeroot -b
                      dpkg-buildpackage: source package address-book-app
                      dpkg-buildpackage: source version 0.4~0ubports1
                      dpkg-buildpackage: source distribution xenial
                      dpkg-buildpackage: source changed by Alberto Mardegan <mardy@users.sourceforge.net>
                      dpkg-buildpackage: host architecture armhf
                       dpkg-source --before-build address-book-app
                      dpkg-checkbuilddeps: error: Unmet build dependencies: dh-apparmor qml-module-ofono qml-module-qt-labs-platform qml-module-qtsysteminfo (>= 5.0~)
                      dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
                      dpkg-buildpackage: warning: (Use -d flag to override.)
                      

                      I installed these packages as well with the libertine-container-manager. Following that the build works, until the test execution fails.

                      I fiddled with the LD_LIBRARY_PATH, just to see if I can get anything going and ran the qmltestrunner manually, leading to this output:

                      phablet@ubuntu-phablet:~/address-book-app$ export LD_LIBRARY_PATH="/usr/lib/arm-linux-gnueabihf:/usr/lib/arm-linux-gnueabihf/mesa-egl:$LD_LIBRARY_PATH"
                      phablet@ubuntu-phablet:~/address-book-app$ /usr/lib/arm-linux-gnueabihf/qt5/bin/qmltestrunner
                      qt.qpa.xcb: could not connect to display 
                      qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
                      This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
                      
                      Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb.
                      
                      Aborted
                      

                      At that point I am wondering, with entering the container with DISPLAY= , there won't be a display available ever in there. So can these tests really run in the container? Is there a nightly build that I could try to investigate, to see how this should be done?

                      1 Reply Last reply Reply Quote 0
                      • D Offline
                        doniks @dobey
                        last edited by 3 Feb 2021, 07:11

                        @dobey said in Building on device with small root partition:

                        @doniks said in Building on device with small root partition:

                        , after the building INSIDE is complete.

                        The build is incomplete, because the tests failed to run.

                        well ok, but I would assume that the build process first creates executables and then tests them. so, if the executables exist, one could still try to use/test them outside the container.

                        and even if the failing tests are before some final step that puts the executables together maybe anhilde can relatively easily disable them for the moment, to get one step further

                        @anhilde

                        root@ubuntu-phablet:/# ldd /usr/lib/arm-linux-gnueabihf/libQt5Gui.so.5
                        	libGLESv2.so.2 => /usr/lib/arm-linux-gnueabihf/mesa-egl/libGLESv2.so.2 (0x00000000)
                        

                        so this is the mesa version, maybe you need the hybris one https://packages.ubuntu.com/search?suite=xenial&arch=armhf&mode=filename&searchon=contents&keywords=libGLESv2 so I guess you could try to libertine-container-manager remove-package -p libgles2-mesa-dev and instead libertine-container-manager install-package -p libhybris

                        D 1 Reply Last reply 3 Feb 2021, 19:48 Reply Quote 0
                        • D Offline
                          dobey @doniks
                          last edited by 3 Feb 2021, 19:48

                          @doniks said in Building on device with small root partition:

                          so, if the executables exist, one could still try to use/test them outside the container.

                          I mean, the packages aren't built yet, because the tests failed, so it's not so easy to do things with them outside the container.

                          A 1 Reply Last reply 4 Feb 2021, 07:25 Reply Quote 1
                          • A Offline
                            anhilde @dobey
                            last edited by 4 Feb 2021, 07:25

                            @dobey I have pulled the *.deb files from the container and installed them with dpkg -i which results in the libGLESv2.so.2 missing error as well.

                            D 1 Reply Last reply 4 Feb 2021, 20:56 Reply Quote 0
                            • D Offline
                              dobey @anhilde
                              last edited by 4 Feb 2021, 20:56

                              @anhilde Did you disable the tests or something? How did you get debs built to install if the issue wasn't resolved?

                              1 Reply Last reply Reply Quote 0
                              19 out of 22
                              • First post
                                19/22
                                Last post