Linuxcnc installation: Run In Place vs Nn Run In Place: Litex 11-add-external-extensions-to-litexcnc

[ozzyrob]

Debian Bookworm linuxcnc 2.9, installed via package manager.

When loading litexcnc the module is trying to load the extra modules from /usr/rtlib , which is fine I think for a RIP install.

For a version of Linuxcnc installed via packages the extra modules needed to be loaded from /usr/lib/linuxcnc/modules/ (which is where the build process copies them to)

It would appear litexcnc's halcompile.py is defining EMC2_RTLIB_DIR from the first instance of rtlib it finds Makefile.modinc, from what I can gather from reading the code.

I've used this hack (litexcnc.c at top of file) to get the behavior I want for a non RIP install of linuxcnc. Is there a way of checking if the installation is RIP or non RIP ?

//hack for building when not a RIP
#ifdef EMC2_RTLIB_DIR
#undef EMC2_RTLIB_DIR
#endif

#define EMC2_RTLIB_DIR "/usr/lib/linuxcnc/modules"

[Peter-van-Tol]

Have to investigate on this. I'm running LinuxCNC 2.8 and before this post I've never heard of Run-in-Place. Check questions:

• are you using Run-in-Place (or did you use it prior on this system)?
• does the error occur on a Run-in-place install or in the normal install?

If the error is in the Run-in-Place install, did you already try the rip-environment, which is part of LinuxCNC:

. @EMC2_HOME@/scripts/rip-environment

I will check whether there is a difference between the versions of halcompile for LinuxCNC and LitexCNC. They should be equal (except for some custom additions, but they don't affect the path).

[ozzyrob]

As I said I using Debian Bookworm with packages installed via the Debian package manager. So not using run in place. I think the issue of the wrong path maybe coming the parsing of this section of /usr/share/Makefile.modinc

ifeq ($(RUN_IN_PLACE),yes)
EXTRA_CFLAGS := $(RTFLAGS) -D__MODULE__ -I$(EMC2_HOME)/include
RTLIBDIR := /usr/rtlib
LIBDIR := /usr/lib
else
prefix := /usr
EXTRA_CFLAGS := $(RTFLAGS) -D__MODULE__ -I${prefix}/include/linuxcnc
RTLIBDIR := /usr/lib/linuxcnc/modules
LIBDIR := ${exec_prefix}/lib
endif

[Peter-van-Tol]

I've verified the halcompile from LinuxCNC. It has changed a lot from 2.8 to 2.9. I want to propose the following steps:

• remove halcompile from LitexCNC, so the latest version is always used.
• move the logic which I added to halcompile to the build-command of the CLI.
• give the user an option in the CLI to set the EMC2_RTLIB_DIR in case it uses the wrong folder.

[ozzyrob]

Yep sounds like the idea.

Really appreciating your work. I've ordered some of these https://oshpark.com/projects/FfXNZDNq/view_design to replace the buffers that are assigned to pins 1,2,3,5,6,7.
Some more info here: https://github.com/Disasm/hc245t-bypass

Once they arrive DownUnder I'll get into some real testing. I have some breakout boards that I used with my BeagleBone Black that will handle to translation from 3.3v to 5v and 5v to 3.3v.

[Peter-van-Tol]

This issue has been solved in 11-add-external-extensions-to-litexcnc:

• [X] Dependency on custom halcompile has been dropped;
• [X] On can override the location where LitexCNC looks for the modules with the rtlib option.

If after this change the files are still installed in the wrong directory, you can use the following command:

poetry install_driver -rtlib /usr/lib/linuxcnc/modules/