2 Linux versions needed to build different AP versions?

General
1

Until now I did my building with a Debian bullseye 11 VM

  • setup
~$ sudo apt-get install git gitk git-gui
~$ sudo apt install python3-dev python3-pip python3-setuptools python3-numpy python3-pyparsing python3-psutil python-is-python3 gcc-arm-none-eabi rsync
~/ardupilot$ python -m pip install empy pexpect future
  • building different AP versions (checked up to AP 4.4.4)
~$ git clone --recurse-submodules https://github.com/ArduPilot/ardupilot.git
~$ cd ardupilot
~/ardupilot$ git checkout tags/Plane-4.3.1
~/ardupilot$ git submodule update --init --recursive
~/ardupilot$ ./waf configure --board revo-mini
~/ardupilot$ ./waf plane

Works fine, but not with master (AP 4.6.0)

I get this here

ChibiOS build requires g++ version 10.2.1 or later, found 8.3.1

Found Cannot build ardupilot on MacOS
but not very helpful. g++ 12.2.1-6 is installed here too.

Now I learned (with the help from Yuri_Rage) that I also can build in a Debian bookworm 12 VM

  • setup (my notes)
~$ sudo apt install git
~$ git clone --recurse-submodules https://github.com/ArduPilot/ardupilot.git
~$ cd ardupilot
~/ardupilot$ ./Tools/environment_install/install-prereqs-ubuntu.sh
~/ardupilot$ source ~/.profile
~/ardupilot$ ./waf configure --board revo-mini
~/ardupilot$ ./waf plane

		## AFTER REBOOT - LOGOUT/LOGIN ##

~$ cd ardupilot
~/ardupilot$ ./waf distclean
~/ardupilot$ source ~/.profile
~/ardupilot$ ./waf configure --board KakuteF7Mini
~/ardupilot$ ./waf plane

Works like a charm, but what with building older versions?

Tried those 2 command


~/ardupilot$ git checkout tags/Plane-4.3.1
~/ardupilot$ git submodule update --init --recursive

but then there is the problem with
./Tools/environment_install/install-prereqs-ubuntu.sh
as that 4.3.1 version does not match the 4.6.0 version …

Could someone here please enlighten me!

br KH

2 
gcc-arm-none-eabi

This ins’t our toolchain and is uncontrolled as you are pulling from debian apt repo. That is why you have a differenct. Use the toolchain we provide.

3

Debian 12 is YOUR toolchain and I would like to skip my DIY Debian 11 environment.

So please advice, how to build older AP versions with that Debian 12 VM.

br KH

4

I’ve had zero issues building any AP 4.x branch on Debian or Ubuntu.

If your toolchain is incorrect, it may be that some of your earlier experiments spoiled the environment.

5

So that command (your command sequence) with added two lines to step back to 4.4.4 should work?

I am not sure, that the commands in those 2 lines are correct as well positioning the lines at that stage in your command sequence.

~$ sudo apt install git
~$ git clone --recurse-submodules https://github.com/ArduPilot/ardupilot.git
~$ cd ardupilot

~/ardupilot$ git checkout tags/Plane-4.4.4
~/ardupilot$ git submodule update --init --recursive

~/ardupilot$ ./Tools/environment_install/install-prereqs-ubuntu.sh
~/ardupilot$ source ~/.profile
~/ardupilot$ ./waf configure --board revo-mini
~/ardupilot$ ./waf plane

When I compare the content of the folders ‘~/ardupilot/Tools/environment_install/’ between ‘4.6.0’ and after trying to step back to ‘stable’ the scripts are totally different. So I assume my method of stepping down from ‘4.6.0’ to ‘stable’ is wrong!

Screenshot_2024-03-26_17-20-21
Screenshot_2024-03-26_17-20-211135×514 79.2 KB

As I mentioned before; I am doing my ‘experiments’ in a VM with a fresh Debian 12 (1st snapshot!) and the 2nd snapshot is set after your 8 commands and I was able to build 4.6.0. So I think. it is always easy to revert to a clean and probably unspoiled environment here.

redards KH

6

By re-cloning and checking out an old branch, you ran the install script that doesn’t have Bookworm support.

The commands I gave you will set up the environment. Then leave it alone. If you want to build a previous version, use the cloned repo as is, and simply git checkout Copter-4.xxx followed by waf as needed.

Quit trying to reinvent the wheel and reinstall everything for each build.

7

That was the answer, I was hoping to get. Thank you for your patience.

The environment is working fine, so all I have to do is start the Debian 12 VM, open a terminal
and add that line

~$ cd ardupilot

~$ git checkout Plane-4.xxx

~/ardupilot$ ./waf distclean
~/ardupilot$ source ~/.profile
~/ardupilot$ ./waf configure --board KakuteF7Mini
~/ardupilot$ ./waf plane

Final questions:

  • is the position of that command to change from version 4.6.0 to … in the sequence at that position OK? Or should it be inserted later?

  • must it be ‘Plane-4.xxx’, or is ‘Plane-4.4.4’ OK or can it also be ‘plane-4.4.4’ ?

br KH

8

The x’s are in place of version number. You have to use an existing branch.

To get back to 4.6-dev, you would check out the master branch.

You ought to do some tutorials on using git. It’s not as hard as you’re making.

9

debian isn’t a toolchain … it is an OS.

You did install gcc-arm-none-eabi toolchain using apt-get . That is the wrong toolchain. Our toolchain for STM target ins’t this one and is donwloaded using the install script and added to your PATH using the .profile.

After, as Yuri explained, just use the install script once and only the one from the master branch.
Then you can freely switch between branch using git to compile the version you need.

10

You did install gcc-arm-none-eabi toolchain using apt-get

No, I did not manually install gcc-arm-none-eabi!
And it is NOT installed by default in a Debian installation.

Please have a look at the terminal protocol
New File.txt (204.1 KB)

But as this protocol is a bit large, I copied all relevant line from that protocol to give you a short overview

Saving to: ‘gcc-arm-none-eabi-10-2020-q4-major-x86_64-linux.tar.bz2’

2024-03-27 10:22:06 (5.75 MB/s) - ‘gcc-arm-none-eabi-10-2020-q4-major-x86_64-linux.tar.bz2’ saved [156882554/156882554]

  • sudo chmod -R 777 gcc-arm-none-eabi-10-2020-q4-major-x86_64-linux.tar.bz2

  • sudo tar xjf gcc-arm-none-eabi-10-2020-q4-major-x86_64-linux.tar.bz2

  • sudo rm gcc-arm-none-eabi-10-2020-q4-major-x86_64-linux.tar.bz2

  • echo ‘Registering STM32 Toolchain for ccache’
    Registering STM32 Toolchain for ccache

Registering STM32 Toolchain for ccache

  • sudo ln -s -f /usr/bin/ccache /usr/lib/ccache/arm-none-eabi-g++

  • sudo ln -s -f /usr/bin/ccache /usr/lib/ccache/arm-none-eabi-gcc

  • echo ‘Done!’

  • exportline=‘export PATH=/opt/gcc-arm-none-eabi-10-2020-q4-major/bin:$PATH’

  • grep -Fxq ‘export PATH=/opt/gcc-arm-none-eabi-10-2020-q4-major/bin:$PATH’ /home/kalle/.profile

  • maybe_prompt_user ‘Add /opt/gcc-arm-none-eabi-10-2020-q4-major/bin to your PATH [N/y]?’

  • false

  • read -p ‘Add /opt/gcc-arm-none-eabi-10-2020-q4-major/bin to your PATH [N/y]?’
    Add /opt/gcc-arm-none-eabi-10-2020-q4-major/bin to your PATH [N/y]?y

  • echo export ‘PATH=/opt/gcc-arm-none-eabi-10-2020-q4-major/bin:$PATH’

  • eval export ‘PATH=/opt/gcc-arm-none-eabi-10-2020-q4-major/bin:$PATH’
    ++ export PATH=/opt/gcc-arm-none-eabi-10-2020-q4-major/bin:/home/kalle/venv-ardupilot/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
    ++ PATH=/opt/gcc-arm-none-eabi-10-2020-q4-major/bin:/home/kalle/venv-ardupilot/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

++ export PATH=/home/kalle/ardupilot/Tools/autotest:/opt/gcc-arm-none-eabi-10-2020-q4-major/bin:/home/kalle/venv-ardupilot/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
++ PATH=/home/kalle/ardupilot/Tools/autotest:/opt/gcc-arm-none-eabi-10-2020-q4-major/bin:/home/kalle/venv-ardupilot/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

++ export PATH=/usr/lib/ccache:/home/kalle/ardupilot/Tools/autotest:/opt/gcc-arm-none-eabi-10-2020-q4-major/bin:/home/kalle/venv-ardupilot/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
++ PATH=/usr/lib/ccache:/home/kalle/ardupilot/Tools/autotest:/opt/gcc-arm-none-eabi-10-2020-q4-major/bin:/home/kalle/venv-ardupilot/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

  • echo ‘Done!’
    Done!

Using toolchain : arm-none-eabi
Checking for ‘g++’ (C++ compiler) : /usr/lib/ccache/arm-none-eabi-g++
Checking for ‘gcc’ (C compiler) : /usr/lib/ccache/arm-none-eabi-gcc

Checking for program ‘arm-none-eabi-objcopy’ : /opt/gcc-arm-none-eabi-10-2020-q4-major/bin/arm-none-eabi-objcopy
Checking for program ‘arm-none-eabi-nm’ : /opt/gcc-arm-none-eabi-10-2020-q4-major/bin/arm-none-eabi-nm

12

To build an old version in your existing clone, you ought to sync submodules for the checked out branch. There is a script to make that very easy:

./waf distclean
git checkout Plane-4.4.4
./Tools/gittools/submodule-sync.sh
./waf configure --board KakuteF7Mini
./waf plane

To return to the master branch (at present, 4.6-dev):

./waf distclean
git checkout master
./Tools/gittools/submodule-sync.sh
13

Yuri, thank you for being so patient with me.

Try later and come back …

cu KH

14

Looks a bit better.

Python at Debian 12 here is

 ~$ python --version
Python 3.11.2
~$ which python
/usr/bin/python

Now

~$ cd ardupilot
~/ardupilot$ ./waf distclean
~/ardupilot$ git checkout Plane-4.4.4
~/ardupilot$ ./Tools/gittools/submodule-sync.sh

until here it looks OK to me. Then

~/ardupilot$ ./waf configure --board KakuteF7Mini

results in different error messages

Waf: The wscript in ‘/home/kalle/ardupilot’ is unreadable
Traceback (most recent call last):
File “/home/kalle/ardupilot/modules/waf/waflib/Scripting.py”, line 140, in waf_entry_point
set_main_module(os.path.normpath(os.path.join(Context.run_dir, Context.WSCRIPT_FILE)))
File “/home/kalle/ardupilot/modules/waf/waflib/Scripting.py”, line 190, in set_main_module
Context.g_module = Context.load_module(file_path)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/home/kalle/ardupilot/modules/waf/waflib/Context.py”, line 665, in load_module
code = Utils.readf(path, m=‘rU’, encoding=encoding)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/home/kalle/ardupilot/modules/waf/waflib/Utils.py”, line 231, in readf
with open(fname, m) as f:
^^^^^^^^^^^^^^
ValueError: invalid mode: ‘rUb’

But this last ValueError ‘Utils.readf(path, m=‘rU’, encoding=encoding’

shows up for instance here 1789646 – python-wxpython4 fails to build with Python 3.9

Enclosed the full transcript from terminal

New File.txt (12.7 KB)

15

While I was able to show you how to build a specific subversion, the branches that you should probably use are Plane-4.4 or Plane-4.5 (with no minor subversion - those are the release branches for the most recent firmware on each).

Rewinding time too far may cause complications. I was able to reproduce that behavior with Plane-4.4, but Plane-4.5 builds fine (ostensibly because prior versions didn’t play nice with venv).

4.5 is on the cusp of stable release, anyway. Recommend you use it (or master) as the starting point for whatever project you have in mind.

To properly begin making your own revisions on Plane-4.5, you’d do something like this:

git checkout Plane-4.5
./Tools/gittools/submodule-sync.sh
git checkout -b Plane-4.5-my-new-feature

Then make your edits, test, and commit. You could make a pull request after committing and pushing to a forked repo.

If all of that sounds too complicated, then I’m afraid that’s where my tutoring will end. It’s basic git usage, which you probably ought to study on your own.

1 Like
16

That seems to be the actual situation, good to hear. My thoughts were ‘Maybe I am a bit too old for things like that?’ Thank you Yuri for being frank to me …
And I think it is a good idea to stop this here.

Short story from my side. I do have several of those revo-minis here, ideal for small planes I use. But the idea of having an OLED display and possibly a micro SD card interested me.
I think, stable version at that time was 4.1.7 and there was only one ‘hwdef.dat’, which did not cover those additions. Have to admit, my last time, I did programming myself, was doing my thesis as a student of mechanical engineering in FORTRAN IV in the late 70s.
But there were a circuit diagram of the OpenPilot Revolution available and also in the AP Wiki a documentation or how-to create a Ubuntu building environment, which I could convert to Debian buster (which still works well under bullseye up to 4.4.4). Hardest point was adapting the ‘hwdef.dat’ file …

Then I posted about those successful modifications in the forum, but as those revo-minis are old FCs, no interest at all.

Some weeks ago by chance, I noticed, that someone in that post, asked, if I could give a hand.

I had a look in available FW file 4.4.4 and found for the revo-nano a normal and an I2C file, but no SD file. No problem building with that old Ubuntu > buster > bullseye environment, after a small problem was solved (The ‘hwdef.dat’ including I2C and SD was a little to big for the revo-mini). Build it under 4.4.4, tested it here and did send it to that user. OK so far.

Then I found that thread about building under Debian 12 and before my attempts to get the old Ubuntu > buster > bullseye environment up to bookworm had failed. That started my interest.

But I’ll put aside all my notes and your advises for now. No hurry.

Besides I think, that webside here
https://ardupilot.org/dev/docs/building-setup-linux.html#building-setup-linux
could use an update, as I see it now. Needs an update to that venv thing.

br KH