Problems with building rtems-tools on OpenSUSE

Hello,

I try to build a powerpc RTEMS toolchain using the rtems source builder (revision 21446e6af24b17) on a current OpenSUSE 15.6. That fails during the rtems-tools build. Basically waf is complaining about No module named 'doxygen'. My host system has a doxygen installed. Any idea what could be missing?

Detailed information

Call to RSB:

../source-builder/sb-set-builder --prefix=/home/EB/christian_m/Projekte/RTEMS-divers/rtems-simulation-env//rtems-install/7 --log=/home/EB/christian_m/Projekte/RTEMS-divers/rtems-simulation-env//external/rtems-source-builder/b-rsb-toolchain-powerpc.log 7/rtems-powerpc

The log shows the following:

+ ./waf distclean configure --prefix=/home/EB/christian_m/Projekte/RTEMS-divers/rtems-simulation-env/rtems-install/7
'distclean' finished successfully (0.000s)
Setting top to                           : /home/EB/christian_m/Projekte/RTEMS-divers/rtems-simulation-env/external/rtems-source-builder/rtems/build/rtems-tools-7e6ba9aaad4361e9b3ab0991d87904ddb835c634-1/rtems-tools-7e6ba9aaad4361e9b3ab0991d87904ddb835c634 
Setting out to                           : /home/EB/christian_m/Projekte/RTEMS-divers/rtems-simulation-env/external/rtems-source-builder/rtems/build/rtems-tools-7e6ba9aaad4361e9b3ab0991d87904ddb835c634-1/rtems-tools-7e6ba9aaad4361e9b3ab0991d87904ddb835c634/build 
invalid version file: __init__() got an unexpected keyword argument 'text'
(complete log in /home/EB/christian_m/Projekte/RTEMS-divers/rtems-simulation-env/external/rtems-source-builder/rtems/build/rtems-tools-7e6ba9aaad4361e9b3ab0991d87904ddb835c634-1/rtems-tools-7e6ba9aaad4361e9b3ab0991d87904ddb835c634/build/config.log)
shell cmd failed: /bin/sh -ex  /home/EB/christian_m/Projekte/RTEMS-divers/rtems-simulation-env/external/rtems-source-builder/rtems/build/rtems-tools-7e6ba9aaad4361e9b3ab0991d87904ddb835c634-1/do-build
error: building rtems-tools-7e6ba9aaad4361e9b3ab0991d87904ddb835c634-1
  See error report: rsb-report-rtems-tools-7e6ba9aaad4361e9b3ab0991d87904ddb835c634-1.txt
  Note: In some cases the error appears only in
  the complete build log (see --log option)

The details in the rsb-report-rtems-tools are:

# project  configured on Thu Aug  7 16:03:51 2025 by
# waf 2.1.4 (abi 20, python 3060ff0 on linux)
# using ./waf distclean configure --prefix=/home/EB/christian_m/Projekte/RTEMS-divers/rtems-simulation-env/rtems-install/7
#
----------------------------------------
Setting top to
/home/EB/christian_m/Projekte/RTEMS-divers/rtems-simulation-env/external/rtems-source-builder/rtems/build/rtems-tools-7e6ba9aaad4361e9b3ab0991d87904ddb835c634-1/rtems-tools-7e6ba9aaad4361e9b3ab0991d87904ddb835c634
----------------------------------------
Setting out to
/home/EB/christian_m/Projekte/RTEMS-divers/rtems-simulation-env/external/rtems-source-builder/rtems/build/rtems-tools-7e6ba9aaad4361e9b3ab0991d87904ddb835c634-1/rtems-tools-7e6ba9aaad4361e9b3ab0991d87904ddb835c634/build
from /home/EB/christian_m/Projekte/RTEMS-divers/rtems-simulation-env/external/rtems-source-builder/rtems/build/rtems-tools-7e6ba9aaad4361e9b3ab0991d87904ddb835c634-1/rtems-tools-7e6ba9aaad4361e9b3ab0991d87904ddb835c634: Could not load the Waf tool 'doxygen' from ['waf-tools', '/home/EB/christian_m/Projekte/RTEMS-divers/rtems-simulation-env/external/rtems-source-builder/rtems/build/rtems-tools-7e6ba9aaad4361e9b3ab0991d87904ddb835c634-1/rtems-tools-7e6ba9aaad4361e9b3ab0991d87904ddb835c634/.waf3-2.1.4-72787ce48f227ac42c4b0da24e780694', '/home/EB/christian_m/Projekte/RTEMS-divers/rtems-simulation-env/external/rtems-source-builder/rtems/build/rtems-tools-7e6ba9aaad4361e9b3ab0991d87904ddb835c634-1/rtems-tools-7e6ba9aaad4361e9b3ab0991d87904ddb835c634', '/usr/lib/python36.zip', '/usr/lib64/python3.6', '/usr/lib64/python3.6/lib-dynload', '/home/EB/christian_m/.local/lib/python3.6/site-packages', '/usr/lib64/python3.6/site-packages', '/usr/lib64/python3.6/site-packages/PIL', '/usr/lib64/python3.6/_import_failed', '/usr/lib/python3.6/site-packages']
No module named 'doxygen'
from /home/EB/christian_m/Projekte/RTEMS-divers/rtems-simulation-env/external/rtems-source-builder/rtems/build/rtems-tools-7e6ba9aaad4361e9b3ab0991d87904ddb835c634-1/rtems-tools-7e6ba9aaad4361e9b3ab0991d87904ddb835c634: invalid version file: __init__() got an unexpected keyword argument 'text'

Thanks.
Best regards
Christian

It looks like the issue is in the version check:
invalid version file: __init__() got an unexpected keyword argument 'text'

My rtems-tools config.log also displays the doxygen module issue and configures correctly.

I’ll take a closer look to see if I can reproduce it on latest main.

That’s an interesting error @kiwichris will have to help with this one as he added doxygen support.

That file is located in ./linkers/waf-tools/doxygen.py and it’s loaded by the wscript. I tried here locally on FreeBSD and it worked fine.

If you go into rtems-tools itself does configure work OK? Does it print the same error? What version of Python are you on? I tried with 3.13 here and it worked as well.

Oh, interesting mine gives the same error for doxygen in the config.log but doesn’t print it to the console that’s interesting. I wonder if this ever worked because the wscript has

ctx.load("doxygen", tooldir = 'waf-tools')

Which is inside the linkers directory I figured it was added to the syspath since there were no errors printed.

Created an MR to fix the tool directory the doxygen error is no longer printed:

Are you using python prior to 3.7? It appears that the text keyword argument was added to subprocess.Popen in that version as an alias for universal_newlines and we use text in rtemstoolkit/execute.py. This should probably be changed for wider support.

I have created rtemstoolkit/execute.py: Use old name for keyword argument (!68) · Merge requests · RTEMS / Tools / RTEMS Tools · GitLab to address this build issue.

Python 3.6 is EOL and 3.9 is EOL 2025-10. Full table:

3.6 was EOL 2016.

Thanks @opticron and @amar for the detailled answers.

The python version is most likely the problem. OpenSUSE unfortunately is really bad at providing up to date versions of some packages, while others are really up to date. A plain python is still Python 3.6.15. They provide a Python 3.11 and 3.12. But it’s only available via explicit python3.11 and python3.12 commands. Seems that I now need a python venv even just to build the tools due to that.

Thank you again.

Best regards

Christian

Just for information:

  • Creating a symlink somwhere in the PATH to have python3 pointing to /usr/bin/python3.11 doesn’t work either. That includes a python venv that basically does just that. In that case building gdb fails with the following error:
    config: tools/rtems-gdb-16.2.cfg
    error: shell macro failed: /home/EB/christian_m/Projekte/RTEMS-divers/rtems-simulation-env/external/rtems-source-builder/source-builder/sb/rtems-build-dep -c gcc   -l : 2: error: no library (-l) provided
    Build FAILED
    Build Set: Time 0:00:59.534122
    error: shell macro failed: /home/EB/christian_m/Projekte/RTEMS-divers/rtems-simulation-env/external/rtems-source-builder/source-builder/sb/rtems-build-dep -c gcc   -l : 2: error: no library (-l) provided
    Build Set: Time 0:00:59.536340
    Build FAILED
    
  • Using the source builder with a --with-python-version=python3.11 also doesn’t work. It’s used in gdb. But it seems to be ignored for the rtems-tools.

I’m still investigating what works.

Seems that a python venv doesn’t work. RSB is still using the system python3-config. If I create a symlink for that in the venv, the libpython headers are missing, which seems to be a design choice: venv does not install libpython · Issue #87500 · python/cpython · GitHub

I think I’ll give up to build the tools on OpenSUSE and will use a podman container instead. Containers are a bit limited but at the moment it seems to be the faster option to somehow reach my goal (which was to analyze some of the warnings that Joel asked about).

I was able to build the tools with RSB using these symbolic links:

/usr/bin/python3 → python3.11

/usr/bin/python3-config → python3.11-config

Thank you. I’ll try that on the next toolchain.