Trouble with StateTag

Hi,

for my java app I have a little C/C++-library that handles NML-interface.
Most of library stuff works as expected.
But when I issue a TRAJ_SET_SCALE command, my app traps with
Searching linuxcnc sources leads to constructor StateTag::StateTag declared in file src/emc/rs274ngc/modal_state.hh and defined in src/emc/rs274ngc/modal_state.cc
A closer look to src/emc/rs274ngc/modal_state.hh shows, that the struct containing the constructors is declared as extern "C".

I'm not an expert with name mangling, but as far as I understand it, when a function is declared as extern "C" its name should not be mangled.
Having an unresolved external for the mangled name means, that StateTag is used in some files, without using the header modal_state.hh, so that the constructor is treaten as standard C++ ...

From my understanding, StateTag is used on the backend side to use halpins for interpreter-/motionstates, so any user application should not have to bother with it. Right?

Any hint is appreciated.

I found the source of evil.

I have to confess, I was a bit stupid. I thought, when I use the same code as halui and compile it with the same command, it should work the same way.
But that's not the case. May be cause I use a shared library and not an executable.

So I digged for dependencies in linuxcnc. Lot of files use StateTag but don't include the definition file. So I thought, fixing that would bring my world in orden ...
Not true.
So I searched, which lib contained the StateTag constructor - and found librs274.so.0
but adding that lib to the linker options lets the screen explode for the tons of unresolved externals.

So I added "modal_state.o" to the dependenylist of my lib - and now it works

Its a long time since I looked at it but if you look in motion.h (/src/emc/motion/motion.h)
The state tags structure is added to the command structure (emcmot_command_t)
So the intent was to save the interpreter state with  a motion segment.
I never really worked out what was the intended use of State Tags because it was not published to useful pins. I think it was designed to be used from userspace.
From what I could see the copy of state tags was to allow the interpreter written in C++ access to the C structure in motion.
Statetags from memory are updated by the interpreter in Interp::write_state_tag here
github.com/LinuxCNC/linuxcnc/blob/master...interp_write.cc#L210
It seemed a bit kludgy to me.
Hope that helps.

Hi rod,

i still remember your work well. That and statetag and some others stuff was just a workaround for poor data management in the backend.
But instead of addressing the error, one workaround after another is created, then a workaround for the workaround ...

It really hurts to see how linuxcnc degenerates.

Anyway - NML is the border between backend and frontend. Interpreter, motion, statetag and all that belongs to the backend.

A client sending a message should never have to worry about the interpreter or any other part of the backend, or get trapped by them
The dependencies in LC are so convoluted that no library can be used other than what is currently already in use.

This is more than sad.

I'm actually working to find some kind of client library with reduced dependecies, but its hard to fiddle out

As said, I wanted to find out the minimal dependencies for using nml-messages.
It looks like this can't be done, working on a shared lib.
So I wrote a c-client, that reads and writes nml-messages. NO gui, no special access to other linuxcnc features. Just nml-message.

So I removed all libs from linker command and then searched for each unresolved externals. Using libnml is obvious.
Beside that I had to add

• emc/nml_intf/emc.o
• emc/nml_intf/emcops.o
• emc/rs274ngc/modal_state.o
• emc/tooldata/tooldata_common.o
• emc/tooldata/tooldata_mmap.o
• emc/tooldata/tooldata_db.o

Then I looked at required shared libs (ldd myApp):The first group might be ok. I didn't use threads, so pthread is unexpected.
libGL* might be ok too, but libX* are completely unexpected.
I haven't used any GUI element ...

Same is true for librt and liblinuxcnchal - I wrote my own sleep function, for not using any rt-function, but that library got bounded anyway.

So there are lot more silently imported dependencies than expected.