Difficulty building RTAI linuxcnc from source

I did sudo apt-get install on each of the unmet dependencies until there were none left. Wow! ... didn't think it would work ...

OK. I went to linuxcnc-dev\src and did ./autogen.sh then did ./configure
but (groan) configure returned the same error as before

robert@debian:~/linuxcnc-dev/src$ ./configure
checking for c++... c++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether c++ accepts -g... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether c++ supports C++17 features with -std=gnu++17... yes
checking build toplevel... /home/robert/linuxcnc-dev
checking installation prefix... run in place
checking for grep... /usr/bin/grep
checking for egrep... /usr/bin/egrep
checking for pkg-config... /usr/bin/pkg-config
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... (cached) /usr/bin/grep
checking for egrep... (cached) /usr/bin/egrep
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking rpc/rpc.h usability... yes
checking rpc/rpc.h presence... yes
checking for rpc/rpc.h... yes
checking for rtai-config... /usr/realtime-4.19.195-rtai-amd64/bin/rtai-config
checking for xeno-config... none
checking for realtime API(s) to use... /usr/realtime-4.19.195-rtai-amd64/bin/rtai-config
checking for location of kernel headers... using value from RTS: /usr/src/linux-headers-4.19.195-rtai-amd64
checking for cc version... found gcc in rtai-config
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking how to run the C preprocessor... gcc -E
checking for usability of linux/hidraw.h... yes
checking for usability of rpc/rpc.h... yes
checking for libmodbus3... yes - version 3.1.4
checking for libusb-1.0... yes
checking for kernel version string... gcc: error: /usr/src/linux-headers-4.19.195-rtai-amd64/include/linux/version.h: No such file or directory
gcc: fatal error: no input files
compilation terminated.
configure: error: Kernel version string not found
robert@debian:~/linuxcnc-dev/src$

The only theory I have is that the code is set up for a non-realtime build, the user space build. When I was following directions for taking care of dependencies, the first instruction was to run ./debian/configure. When I did that, the return was "successfully configured for uspace-Debian".
Maybe if the configure files think I'm not wanting a realtime build, they don't take care of the realtime headers. Just a guess.

Hi -
Thank you very much. Sometimes I get so wrapped up in this process I forget to say that.
I ran your two sudo apt-get installs, then re-ran configure. Configure had a little problem at the end, having to do with licensing. It suggested an option to append to the ./configure call, which I implemented. Then configure ran through to the end! !!
It put up a congratulatory summary box surrounded by asterisks, told me to run make.
I ran make. The computer chugged away for what felt like several minutes, putting up all kinds of verbiage. Then it stumbled at the end, saying a for loop could only be handled correctly by C99 or C11. It suggested a -std=c99 option, so I did "make -std=c99" and it busted me immediately with multiple invalid option errors. I'm attaching the end of the make output.
One thing that occurred to me: If make had been successful, would there have been a linuxcnc executable someplace? Where? Would I just do ./linuxcnc to run it?

LD [M] /home/robert/linuxcnc-dev/src/tof.o
CC [M] /home/robert/linuxcnc-dev/src/objects/hal/components/match8.o
LD [M] /home/robert/linuxcnc-dev/src/match8.o
CC [M] /home/robert/linuxcnc-dev/src/objects/hal/components/timedelay.o
LD [M] /home/robert/linuxcnc-dev/src/timedelay.o
CC [M] /home/robert/linuxcnc-dev/src/objects/hal/components/limit_axis.o
hal/components/limit_axis.comp: In function ‘_’:
hal/components/limit_axis.comp:67:3: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
hal/components/limit_axis.comp:67:3: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
make[2]: *** [scripts/Makefile.build:304: /home/robert/linuxcnc-dev/src/objects/hal/components/limit_axis.o] Error 1
make[1]: *** [Makefile:1547: _module_/home/robert/linuxcnc-dev/src] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.19.195-rtai-amd64'
make: *** [Makefile:547: modules] Error 2
robert@debian:~/linuxcnc-dev/src$

Hi -
Thank you.
I looked at limit_axis.comp. It appeared to be a generic anti-collision utility that I would probably be okay without, so, as you did, I deleted it.
Then make returned an error having to do with files raster.c, raster.comp and raster.o. Figuring your guidance was to delete files that caused errors, I deleted all the raster.xxx files.
But they returned on subsequent attempts to make.
I tried restarting, thinking that might make the files stay away after being deleted, but they returned.
I'm attaching the output from make.

The larger question is how to compile for a three-axis mill using a Motenc-Lite board. Just that one simple machine. LinuxCNC attempts to have something for everyone, but that makes it voluminous and complex. I wonder if there is a way to restrict configure and make in order to reduce the number of files that have to be correct.

robert@debian:~/linuxcnc-dev/src$ make
Reading 205/205 dependency files
Done reading dependencies
MAKEFLAGS="" \
/usr/bin/python3.7 modsilent.py make KBUILD_EXTRA_SYMBOLS=/usr/realtime-4.19.195-rtai-amd64/modules/Module.symvers -C /usr/src/linux-headers-4.19.195-rtai-amd64 M=/home/robert/linuxcnc-dev/src CC=gcc V=0 modules
make[1]: Entering directory '/usr/src/linux-headers-4.19.195-rtai-amd64'
CC [M] /home/robert/linuxcnc-dev/src/objects/hal/components/raster.o
/home/robert/linuxcnc-dev/src/objects/hal/components/raster.c:14:10: fatal error: stdlib.h: No such file or directory
#include <stdlib.h>
^~~~~~~~~~
compilation terminated.
make[2]: *** [scripts/Makefile.build:304: /home/robert/linuxcnc-dev/src/objects/hal/components/raster.o] Error 1
make[1]: *** [Makefile:1547: _module_/home/robert/linuxcnc-dev/src] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.19.195-rtai-amd64'
make: *** [Makefile:547: modules] Error 2
robert@debian:~/linuxcnc-dev/src$

Thank you for your help.
I cd to my linuxcnc-dev directory, and when I do git checkout 2.8 it returns
error pathspec "2.8" did not match any files known to git
My linuxcnc-dev directory includes a .git directory.
I've tried cd-ing to linuxcnhc-dev/src and doing git checkout 2.8 from there. The result was the same, i.e. the pathspec error.

Thank you for continuing to suggest things ... I feel I'm missing something fundamental and it's preventing these suggested actions from working.

I'm pasting in the output I get from doing git fetch and git pull.
I'm typing those things in a command window from my linuxcnc-dev directory.

robert@debian:~/linuxcnc-dev$ git fetch
robert@debian:~/linuxcnc-dev$ git pull
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.

git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

git branch --set-upstream-to=<remote>/<branch> master

robert@debian:~/linuxcnc-dev$