Compiling custom C++ applications using CMake in Armbian?

[Ozmydis]

Just started with creating custom images for an Orange Pi R1+ LTS board. In my build I'd like to compile some custom C++ applications using CMake, then install them onto the root file system to run on the board. Couldn't find much on this on the docs, though maybe I haven't looked hard enough! A couple of questions:

1. I noticed the customize-image.sh script in the build repository - would amending this script be the intended method for this kind of functionality or is there another, better way?
2. How would I provide CMake the relevant info to compile correctly for the board.

Thanks in advance.

[going]

The right way is to build a debian package for your application. Then, at the stage of creating the image, install it.

To create additional packages in armbian, there is a chroot environment mechanism that will assemble the package in the native environment with all the necessary dependencies.
If this is your personal project, you need to create a debian folder in the root of the project and fill it with the necessary files.
How to do this correctly is described in great detail in the documentation:

debmake-doc, maint-guide
Next, you simply add the necessary "in the image and likeness" to the "armbian-build/packages/extras-buildpkgs/" folder necessary for the build.

And run the build system with the EXTERNAL_NEW=compile parameter.

There is really not enough documentation on this part, but I hope that it will appear as a result of our conversation.

Ask anything you want. I will guide you along this path.

[Ozmydis]

Thanks for your reply, I've created a debian package now. However, when I run:

 

sudo ./compile.sh  BOARD=orangepi-r1plus-lts BRANCH=current RELEASE=jammy BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no COMPRESS_OUTPUTIMAGE=sha,gpg,img EXTERNAL_NEW=compile

 

I receive the following error:

 

[ o.k. ] Creating build chroot [ focal/amd64 ]
I: Retrieving InRelease 
I: Checking Release signature
I: Valid Release signature (key id F6ECB3762474EDA9D21B7022871920D1991BC93C)
I: Retrieving Packages 
I: Retrieving Packages 
I: Retrieving Packages 
E: Couldn't download http://localhost:3142/ports.ubuntu.com/dists/focal/main/binary-amd64/Packages
[ error ] ERROR in function create_chroot [ main.sh:595 -> main.sh:552 -> chroot-buildpackages.sh:194 -> chroot-buildpackages.sh:68 -> general.sh:0 ]
[ error ] Create chroot first stage failed 
[ o.k. ] Process terminated 

I assume this is some sort of other issue, since it occurs even when I remove my package from the packages/extras-buildpkgs/ directory. I'm basing my build off the master branch (commit 31ac6383e tag 22.11.0-trunk.0048).

[going]

I'll check it out now.

What environment are you running in now?

 

 

 

[Ozmydis]

My mistake, I somehow missed that the build environment must be Ubuntu Jammy 22.04.x amd64. 

[going]

34 минуты назад, Ozmydis сказал:

[ o.k. ] Creating build chroot [ focal/amd64 ]

It tries for amd64 but should for arm64

[going]

17 минут назад, Ozmydis сказал:

the build environment must be Ubuntu Jammy 22.04.x

What environment are you running in now?

 

If you running in focal then

Try to fix it

RELEASE=focal

 

[Ozmydis]

2 hours ago, going said:

What environment are you running in now?

 

I updated my build environment to Jammy 22.04.1 before seeing your message, but I get the same issue as I did originally unfortunately. I was using Focal 20.04 beforehand.

 

$ uname -a
Linux build-env 5.15.0-48-generic #54-Ubuntu SMP Fri Aug 26 13:26:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
$ dpkg --print-architecture
amd64

 

Any suggestions?

Edited October 6, 2022 by Ozmydis

[going]

34 минуты назад, Ozmydis сказал:

Any suggestions?

Most likely, some packages are not installed. To catch this bug, I install a clean environment and try to run it.

[going]

1 час назад, Ozmydis сказал:

I updated my build environment to Jammy 22.04.1

Is this environment running in some kind of virtual machine?

Is the package installed?

  distcc --version
 

I found another problem. And this is due to some recent fixations. The error is implicit.

I apologize. I'll have to wait until I find it and fix it.

[Ozmydis]

Quote

Is this environment running in some kind of virtual machine?

Yes, this is all running in a proxmox server VM. distcc is installed, output:

 

$ distcc --version
distcc 3.3.5 x86_64-pc-linux-gnu
  (protocols 1, 2 and 3) (default port 3632)
  built Jan 13 2022 19:12:28
...etc.

 

I've installed a new VM from a fresh 22.04 ISO, just waiting to see what comes of it. 

 

Quote

I found another problem. And this is due to some recent fixations. The error is implicit.

I apologize. I'll have to wait until I find it and fix it.

Ok, thanks for letting me know.

[going]

1 час назад, Ozmydis сказал:

running in a proxmox server VM.

I'm not familiar with this. But it seems that the build system does not understand this and does not set some variables correctly.

E: Couldn't download http://localhost:3142/ports.ubuntu.com/dists/focal/main/binary-amd64/Packages

Please check for your VM:

Restart VM.

Add to cmdline: NO_APT_CACHER=yes

And look carefully at `output/debug/*'.

 

I am using a Qemu/KVM VM based on libvirt.

 

 

[going]

While I'm fixing the found parts of poorly connected logic, you can use my branch:

https://github.com/The-going/armbian-build/tree/chroot_build_pkg
I use it to work on one package in a chroot environment. It will always be rebased relative to the master armbian branch.

 

You can immediately start creating packages and see something similar:

leo@vm-jammy:~/armbian$ ./compile.sh test BUILD_CHROOT='htop sunxi-tools'
[ warn ] This script requires root privileges, trying to use sudo 
[sudo] password for leo: 
[ o.k. ] Using config file [ /home/leo/armbian/userpatches/config-test.conf ]
[ o.k. ] Command line: setting BUILD_CHROOT to [ htop ]
[ .... ] Extension being added [ sunxi-tools :: added by main.sh:381 -> configuration.sh:173 -> config/sources/families/sun50iw1.conf:2 -> config/sources/families/include/sunxi64_common.inc:1 ]
[ o.k. ] Extension manager [ processed 3 Extension Methods calls and 3 Extension Method implementations ]
[ o.k. ] Starting package building process [ jammy/arm64 ]
[ o.k. ] Creating build chroot [ jammy/arm64 ]
I: Retrieving InRelease 
I: Checking Release signature
I: Valid Release signature (key id F6ECB3762474EDA9D21B7022871920D1991BC93C)
I: Retrieving Packages 
I: Validating Packages 
I: Retrieving Packages 
I: Validating Packages 
I: Retrieving Packages 
I: Validating Packages 
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on http://localhost:3142/ports.ubuntu.com...
I: Checking component universe on http://localhost:3142/ports.ubuntu.com...
I: Retrieving adduser 3.118ubuntu5
I: Validating adduser 3.118ubuntu5
......
......
[ o.k. ] Debootstrap complete [ jammy/arm64 ]
[ o.k. ] Create a clean Environment archive [ jammy-arm64-v7.tar.xz ]
 758MiB [14.1MiB/s] [============================================================================================================>] 100%
[ o.k. ] Unpack the clean environment [ jammy-arm64-v7.tar.xz ]
[ o.k. ] selected_packages= [ htop sunxi-tools ]
[ o.k. ] Building packages [ htop jammy/arm64 ]
[ o.k. ] Checking git sources [ extra/htop 2.2.0 ]

A clean build environment will be created. It will be packed and will be unpacked each time for the next package.
You will need to register the build dependencies in the debian/control file. They will be installed automatically.

Edited October 6, 2022 by going
Add more

[Ozmydis]

Thanks, I can build using this when the EXTERNAL_NEW=compile parameter is omitted. BUILD_CHROOT doesn't seem to use my debian package when I give its name, which might mean I have an issue with how I'm setting up the package...

 

1) Does BUILD_CHROOT throw any errors if it cannot find the package name it has been given?

2) Is a .conf file in the extras-buildpkgs directory required for detecting package names/configuration for Armbian? 

3) Are there any ways of speeding up the build times when debugging for problems such as this?

 

I'll take a further look into this at a later date.

[going]

37 минут назад, Ozmydis сказал:

1) Does BUILD_CHROOT throw any errors if it cannot find the package name it has been given?

2) Is a .conf file in the extras-buildpkgs directory required for detecting package names/configuration for Armbian? 

 

1) The BUILD_CHROOT global variable contains a list of packages that the chroot_build_packages function takes as arguments.

https://github.com/The-going/armbian-build/blob/a99d4c51ff5592995ffe3098220a56b737d93ec6/lib/chroot-buildpackages.sh#L172

2) Next, the find utility searches for the full path for the configuration file of the corresponding name.

https://github.com/The-going/armbian-build/blob/a99d4c51ff5592995ffe3098220a56b737d93ec6/lib/chroot-buildpackages.sh#L251

- Then, in the for loop, the configuration file is read and becomes part of the script for the period of one cycle.

https://github.com/The-going/armbian-build/blob/a99d4c51ff5592995ffe3098220a56b737d93ec6/lib/chroot-buildpackages.sh#L260

It contains local variables and functions necessary for operation. Example:

leo@vm-jammy:~/armbian$ cat  packages/extras-buildpkgs/90-hostapd-realtek.conf 
# hostapd-realtek
local package_name="hostapd-realtek"
local package_repo="http://w1.fi/hostap.git"
local package_ref="tag:hostap_2_5"
local package_upstream_version="3:2.5-4"
local package_install_target="hostapd-realtek"
local package_component="${release}-utils"

package_checkbuild()
{
        true
}

package_checkinstall()
{
        false
}

package_repo -  the repository will be cloned from the address

package_ref - the corresponding tag will be extracted to the working directory. You can specify a branch:master.

package_upstream_version - If it exists, then during the build process, the package version will be installed larger than this one.

In order for your assembled package to be newer than the one that exists in the system.

package_checkbuild() - a function that checks various conditions and returns true or false. If false, the package will be skipped and will not be built.

package_install_target - A strange entity. Must contain a name. By which the existence of the collected package is checked.

If it exists then the build is skipped. To rebuild a package, you must first delete it.

package_component - the template is part of the path where the built package will be moved

package_checkinstall - If true, then the newly built package will be installed before the next package is built.

3) NCPU_CHROOT - A global variable that contains the number of dedicated processors for building a package in a chroot environment.

Can be defined at the very beginning. If not defined then it will be equal to 2

[Ozmydis]

I've created a .conf file for my package now. It seems to recognise it as it performs the build when I call the package from the BUILD_CHROOT parameter, but does not actually put the executable into the deb package; it only puts the documentation files in there. 

 

To solve this I was hoping to base my package layout in Armbian off the htop package which already exists in the repository, however htop also fails during the build process:

 

./compile.sh BOARD=orangepi-r1plus-lts BRANCH=current RELEASE=jammy BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no NO_APT_CACHER=yes NCPU_CHROOT=4 BUILD_CHROOT='htop'

 

Output:

 

[ warn ] This script requires root privileges, trying to use sudo 
[ o.k. ] Using config file [ /home/user/going-armbian-repo/armbian-build/userpatches/config-example.conf ]
[ o.k. ] Command line: setting BOARD to [ orangepi-r1plus-lts ]
[ o.k. ] Command line: setting BRANCH to [ current ]
[ o.k. ] Command line: setting RELEASE to [ jammy ]
[ o.k. ] Command line: setting BUILD_MINIMAL to [ yes ]
[ o.k. ] Command line: setting BUILD_DESKTOP to [ no ]
[ o.k. ] Command line: setting KERNEL_ONLY to [ no ]
[ o.k. ] Command line: setting KERNEL_CONFIGURE to [ no ]
[ o.k. ] Command line: setting NO_APT_CACHER to [ yes ]
[ o.k. ] Command line: setting NCPU_CHROOT to [ 4 ]
[ o.k. ] Command line: setting BUILD_CHROOT to [ htop ]
[ .... ] Extension being added [ rkbin-tools :: added by main.sh:381 -> configuration.sh:173 -> config/sources/families/rockchip64.conf:1 -> config/sources/families/include/rockchip64_common.inc:1 ]
[ o.k. ] Extension manager [ processed 3 Extension Methods calls and 3 Extension Method implementations ]
[ o.k. ] Starting package building process [ jammy/arm64 ]
[ o.k. ] Unpack the clean environment [ jammy-arm64-v7.tar.xz ]
[ o.k. ] selected_packages= [ htop ]
[ o.k. ] Building packages [ htop jammy/arm64 ]
[ o.k. ] Checking git sources [ extra/htop 2.2.0 ]
[ .... ] Up to date 
Failed to mount /etc/localtime (type n/a) on /home/user/going-armbian-repo/armbian-build/.tmp/build-VYOYl/jammy-arm64-v7/usr/share/zoneinfo/UTC (MS_BIND ""): No such file or directory
[ .... ] Copying sources 

...

checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating htop.1
config.status: creating config.h
config.status: executing depfiles commands
make[1]: Leaving directory '/root/build/htop'
   dh_auto_build
    make -j4
make[1]: Entering directory '/root/build/htop'
./scripts/MakeHeader.py AvailableColumnsPanel.c
./scripts/MakeHeader.py AvailableMetersPanel.c
./scripts/MakeHeader.py CategoriesPanel.c
./scripts/MakeHeader.py CheckItem.c
make[1]: Leaving directory '/root/build/htop'
[ error ] Failed building [ htop jammy/arm64 ]
[ o.k. ] Build time htop  [  149 sec. ]
[ warn ] Following packages failed to build 
[ .... ] htop:jammy/arm64 
[ o.k. ] Runtime [ 2 min ]

 

Some problem with python maybe? I'm not quite sure. It might be easier to resolve the original issue with my package if I knew where the executable was being compiled to, since I assume "/root" must be a mount somewhere on my build machine...

[going]

6 часов назад, Ozmydis сказал:

It might be easier to resolve the original issue with my package

Without a doubt, this is the best option.
If I understand correctly, your package is going as pkg-name.deb? but is there something missing inside?

The output/debug/pkg-name.log file is exist? What does it contain?

 

[going]

Unfortunately, the build mechanism assumes that you already have a working debian directory for your project.

If you need a debugging environment, then this is something else.
Can I look at your project?

 

Unfortunately, the build mechanism assumes that you already have a working debian directory for your project.

If you need a debugging environment, then this is something else.

Can I look at your project?
If not, then show the debian/rules file and write what debugging information you want to see. I'll try to add functionality.

 

 

[going]

6 часов назад, Ozmydis сказал:

"/root" must be a mount somewhere on my build machine

I have added debugging code to view the temporary directory, which is deleted at the end of the process.

Pull the updates and run with the additional parameter DEBUG_TMP= true

You will see a message and when you are done browsing, delete this temporary folder manually.

[Ozmydis]

Thank you. I was able to debug the issues with my Debian package. Using your chroot_build_pkg branch I can build the .deb file into what I expect it to look like. package_checkbuild() and package_checkinstall() are both set to true for my package so I expect that the package will be installed to the image when the EXTERNAL_NEW=compile parameter is applied.

 

Of course when I do add the EXTERNAL_NEW=compile parameter, I still have the original issue where my system tries to download amd64, when it should download arm64, so the image build fails before it reaches my package. Need to figure out some sort of way to get around this...

[going]

5 часов назад, Ozmydis сказал:

Thank you.

Your gratitude can be made in the form of a description of the problems you encountered when interacting with the build system.

What functionality could be added? Any opinion matters.

 

6 часов назад, Ozmydis сказал:

Need to figure out some sort of way to get around this...

I fixed this bug in my branch. Please pull.

[Ozmydis]

Ok, I am currently on holiday so I will get around to providing feedback and using your new commits in a couple of weeks. 

[Ozmydis]

Your fix has allowed me to download and install the packages that were breaking now. Still get an error back from the build process though inside the output/debug/install.log file:

 

openpgp: Passphrase is required to unlock private key "Armbian builder (Temporary key for installing packages during Armbian image creation) <root@localhost>"
openpgp: 2048-bit RSA key, ID 92B90DE1925644A6, created 2016-08-05
Loading packages...
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
OK
Ign:1 http://localhost:8189 jammy InRelease
Hit:2 http://ports.ubuntu.com jammy InRelease
Hit:3 http://ports.ubuntu.com jammy-security InRelease
Hit:4 http://ports.ubuntu.com jammy-updates InRelease
Hit:5 http://ports.ubuntu.com jammy-backports InRelease
Hit:6 http://ppa.launchpadcontent.net/saiarcot895/chromium-beta/ubuntu jammy InRelease
Hit:7 http://ppa.launchpadcontent.net/mozillateam/ppa/ubuntu jammy InRelease
Hit:10 https://ppa.launchpadcontent.net/jonathonf/zfs/ubuntu jammy InRelease
Hit:11 http://deb.volian.org/volian scar InRelease
Hit:8 https://cli.github.com/packages stable InRelease
Hit:9 http://armbian.systemonachip.net/apt jammy InRelease
Ign:1 http://localhost:8189 jammy InRelease
Ign:1 http://localhost:8189 jammy InRelease
Err:1 http://localhost:8189 jammy InRelease
  Could not connect to localhost:8189 (::1). - connect (111: Connection refused) Could not connect to localhost:8189 (127.0.0.1). - connect (111: Connection refused)
Reading package lists...
W: Failed to fetch http://localhost:8189/dists/jammy/InRelease  Could not connect to localhost:8189 (::1). - connect (111: Connection refused) Could not connect to localhost:8189 (127.0.0.1). - connect (111: Connection refused)
W: Some index files failed to download. They have been ignored, or old ones used instead.
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package helloworld
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
OK
Checking that no-one is using this disk right now ... OK

 

Which is unusual since it seems to download the package fine in the BUILD_CHROOT environment...

 

On 10/11/2022 at 9:30 PM, going said:

Your gratitude can be made in the form of a description of the problems you encountered when interacting with the build system.

What functionality could be added? Any opinion matters.

 

I think that a good amount of my issues came from misunderstanding the build system, and good documentation would be helpful in that regard. This conversation started with me suggesting to do this all in the customize-image.sh file, so some information on when and when not to use this file would be useful. Beyond documentation, here's a short list of things I think might be improvements:

• A warning message for new users might be nice if they attempt to run the build environment on something which is not officially supported by Armbian.
• Some example files in the packages/extras-buildpkgs directory which contain comments and details on how to lay out the configuration file for a package would be helpful (maybe something similar to the userpatches/config-example.conf file?).
• Another solution would be to create something similar to Yocto's devtool for generating and testing packages to be put onto the image. The process might be much easier for users with something like this. The BUILD_CHROOT parameter's functionality might be a part of the testing functionality for example.
• In customize-image.sh it might be better to give the chroot and host environment variables instead of using userpatches/overlay and /tmp/overlay.
• customize-image.sh might be better off being spread across multiple files? I imagine someone who might have multiple releases would have quite a large file here if they're doing a lot of customization to the image before unmounting.

[going]

26.10.2022 в 16:56, Ozmydis сказал:

Still get an error back from the build process though inside the output/debug/install.log file:

Thanks for the feedback. I'm working on a fix.