Changes made in kernel aren't reflected in the application even after rebuilding

Tools Waf
1

Let’s say you have built rtems under $(PREFIX)/out/7. So inside $(PREFIX)/out/7/$(ARCH)/$(BSP)/lib you should be able to find the following files:

librtemsbsp.a
librtemscpu.a
librtemscxx.a
librtemsdefaultconfig.a
librtemstest.a
...

in my case:

❯ pwd
$(PREFIX)/out/7

❯ fd --glob 'libr*' .
./arm-rtems7/xilinx_zynq_a9_qemu/lib/librtemsbsp.a
./arm-rtems7/xilinx_zynq_a9_qemu/lib/librtemscpu.a
./arm-rtems7/xilinx_zynq_a9_qemu/lib/librtemscxx.a
./arm-rtems7/xilinx_zynq_a9_qemu/lib/librtemsdefaultconfig.a
./arm-rtems7/xilinx_zynq_a9_qemu/lib/librtemstest.a

Lets say you have your application which just initializes rtems shell inside:

$(PREFIX)/app/hello

so building it would generate

$(PREFIX)/app/hello/build/$(ARCH)-$(BSP)/hello.exe
# in my case
$(PREFIX)/app/hello/build/arm-rtems7-xilinx_zynq_a9_qemu/hello.exe

After building tools, bsp, application and then running it with rtems-run I see what you woud expect:

RTEMS Testing - Run, 7 ()

 Command Line: ./out/7/bin/rtems-run --rtems-bsp=xilinx_zynq_a9_qemu ./app/hello/build/arm-rtems7-xilinx_zynq_a9_qemu/hello.exe
 Host: Linux thorfinn 6.12.59 #1-NixOS SMP PREEMPT_DYNAMIC Mon Nov 24 09:36:08 UTC 2025 x86_64
 Python: 3.13.9 (main, Oct 14 2025, 13:52:31) [GCC 14.3.0]

Host: Linux-6.12.59-x86_64-with-glibc2.40 (Linux thorfinn 6.12.59 #1-NixOS SMP PREEMPT_DYNAMIC Mon Nov 24 09:36:08 UTC 2025 x86_64 )

Hello World



RTEMS Shell on /dev/foobar. Use 'help' to list commands.

SHLL [/] # help ls

ls         - ls [dir]     # list files in the directory

now lets say I modify rtems/cpukit/libmisc/shell/main_ls.c

 rtems_shell_cmd_t rtems_shell_LS_Command = {
   .name = "ls",
-  .usage = "ls [dir]     # list files in the directory",
+  .usage = "ls [dir]     # TEST list files in the directory",
   .topic = "files",
   .command = rtems_shell_main_ls,
   .alias = NULL,

I rebuild and install rtems libraries and I can immediately see the changes inside librtemscpu.a

❯ strings librtemscpu.a | rg 'list files'
ls [dir]     # TEST list files in the directory```

But even after rebuilding my shell application I don’t see the changes getting reflected

❯ strings hello.exe | rg 'list files'
ls [dir]     # list files in the directory

The only way I could find in order to reflect these changes are to either delete hello.exe or just modify any of the application source files.

I am guessing this happens because the build system for applications considers rtems libraries static, so it doesn’t check whether they’ve been modified or not.

2

Yes, if you’re building an application against an installed BSP, the application build under waf/rtems_waf does not expect the libraries it’s building against to change, so it does not track them for that purpose. This means that if you’re doing RTEMS kernel development and you’re building a test application against it, you’ll need to run ./waf clean build instead of just ./waf build or ./waf.

1 Like
3

ya I did figure that out but shouldn’t it also consider kernel as a direct dependency? and check if they have been modified

4

I see system level dependencies as an optional addition to an application build system and something you can add. I do not add Linux, Windows or FreeBSD headers or libraries as dependencies to any apps I build on those hosts.

My experience is this is only an issue when starting a project or integrating a new version. Most application development teams use stable system libraries and they should not be changing.

As a short cut if I have a file in a system library I need to play with I sometimes copy it to the app and directly link it overriding the code in the .a files.

1 Like
5

Ya that makes sense. And do you think explicitly mentioning this behviour and the use of ./waf clean build in the build your application page would be a nice addition?