machinekit / machinekit-hal

Universal framework for machine control based on Hardware Abstraction Layer principle
https://www.machinekit.io
Other
109 stars 63 forks source link

multiple definition of rtapi_message_buffer #350

Closed rene-dev closed 3 years ago

rene-dev commented 3 years ago

Im trying to build on ubuntu 21.04 with gcc 10 and hitting this error:

make: Entering directory '/home/rene/dev/machinekit-hal/src' Compiling rtapi/rtapi.c Creating shared library libhalulapi.so.0 /usr/bin/ld: objects/rtapi/rtapi_support.o:/home/rene/dev/machinekit-hal/src/rtapi/rtapi_support.c:62: multiple definition of `rtapi_message_buffer'; objects/rtapi/rtapi.o:/home/rene/dev/machinekit-hal/src/rtapi/rtapi.c:50: first defined here

I cannot figure out whats going on, possibly this is related to https://github.com/machinekit/machinekit-hal/issues/346?

cerna commented 3 years ago

The #346 is mainly concerned with runtime loading of symbols from compiled shared libraries to the process.

This seems like an issue happening during the link time of the shared library. Frankly, it looks like one of many of Machinekit-HAL's bugs, because as far as I can tell, the linker is right, there really is a redefinition of that symbol.

Odd thing is, it was probably intentional from this piece of code:

#ifdef ULAPI
ringbuffer_t rtapi_message_buffer;   // rtapi_message ring access strcuture
# else
extern ringbuffer_t rtapi_message_buffer;
#endif

At first glance I would think that adding extern should solve the multi-definition issue. I will try looking into it.

rene-dev commented 3 years ago

I already tried that, doesn't work.

cerna commented 3 years ago

Really? I was able to get to the next error in line:

collect2: error: ld returned 1 exit status
make: *** [rtapi/Submakefile:86: ../lib/libhalulapi.so.0] Error 1
make: Leaving directory '/tmp/mk/src'
mk@mars:/tmp/mk/src$ make
All Submakefiles included
Reading 100/179 dependency files
Done reading dependencies
make: Entering directory '/tmp/mk/src'
Compiling rtapi/rtapi_support.c
Creating shared library libhalulapi.so.0
Creating shared library libhal.so.0
Linking haltalk
Compiling rtapi/rtapi_math/s_floor.c
Compiling rtapi/rtapi_math/e_pow.c
Compiling rtapi/rtapi_math/w_pow.c
Compiling rtapi/rtapi_math/s_fabs.c
Compiling rtapi/rtapi_math/e_sqrt.c
Compiling rtapi/rtapi_math/w_sqrt.c
Compiling rtapi/rtapi_math/s_ceil.c
Compiling rtapi/rtapi_math/e_acos.c
Compiling rtapi/rtapi_math/w_acos.c
Compiling rtapi/rtapi_math/e_asin.c
Compiling rtapi/rtapi_math/w_asin.c
Compiling rtapi/rtapi_math/s_tan.c
Compiling rtapi/rtapi_math/k_tan.c
Compiling rtapi/rtapi_math/s_atan.c
Compiling rtapi/rtapi_math/w_atan2.c
Compiling rtapi/rtapi_math/e_atan2.c
Compiling rtapi/rtapi_math/s_sin.c
Compiling rtapi/rtapi_math/k_sin.c
Compiling rtapi/rtapi_math/s_cos.c
Compiling rtapi/rtapi_math/k_cos.c
Compiling rtapi/rtapi_math/e_rem_pio2.c
Compiling rtapi/rtapi_math/k_rem_pio2.c
rtapi/rtapi_math/k_rem_pio2.c: In function '__kernel_rem_pio2':
rtapi/rtapi_math/k_rem_pio2.c:300:10: error: 'fq[0]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
  300 |   fw = fq[0]-fw;
      |        ~~^~~
cc1: all warnings being treated as errors
make: *** [Makefile:378: objects/rtapi/rtapi_math/k_rem_pio2.o] Error 1
make: Leaving directory '/tmp/mk/src'
rene-dev commented 3 years ago

maybe I tried it in the wrong location....

The next one is a simple fix:

diff --git a/src/rtapi/rtapi_math/k_rem_pio2.c b/src/rtapi/rtapi_math/k_rem_pio2.c index f237d1470..35470db3c 100644 --- a/src/rtapi/rtapi_math/k_rem_pio2.c +++ b/src/rtapi/rtapi_math/k_rem_pio2.c @@ -172,7 +172,7 @@ twon24 = 5.96046447753906250000e-08; / 0x3E700000, 0x00000000 /

endif

{ int32_t jz,jx,jv,jp,jk,carry,n,iq[20],i,j,k,m,q0,ih;

  • double z,fw,f[20],fq[20],q[20];
  • double z,fw,f[20],fq[20] = {0},q[20];
 /* initialize jk*/
    jk = init_jk[prec];
rene-dev commented 3 years ago

This is what I get next with adding extern:

Linking rtapi_msgd /usr/bin/ld: objects/rtapi/rtapi_support.o: in function vs_ringlogfv': /home/rene/dev/machinekit-hal/src/rtapi/rtapi_support.c:98: undefined reference tortapi_message_buffer' /usr/bin/ld: /home/rene/dev/machinekit-hal/src/rtapi/rtapi_support.c:99: undefined reference to rtapi_message_buffer' /usr/bin/ld: /home/rene/dev/machinekit-hal/src/rtapi/rtapi_support.c:100: undefined reference tortapi_message_buffer' /usr/bin/ld: /home/rene/dev/machinekit-hal/src/rtapi/rtapi_support.c:105: undefined reference to rtapi_message_buffer' /usr/bin/ld: /home/rene/dev/machinekit-hal/src/rtapi/rtapi_support.c:107: undefined reference tortapi_message_buffer' /usr/bin/ld: objects/rtapi/rtapi_support.o:/home/rene/dev/machinekit-hal/src/rtapi/rtapi_support.c:108: more undefined references to `rtapi_message_buffer' follow

cerna commented 3 years ago

Hmm, getting it compiled it still seems to not work, respective the process quietly dies. Looking at the rtapi_support.c it looks like the rtapi_message_buffer is defined there only when the flag ULAPI is defined. The rtapi_support.c is directly compiled into the rtapi_app executable.

In other words, it looks like that memory is allocated only once for rtapi_message_buffer in the so-called ULAPI part and the rtapi.so HAL module is dynamically connected to it via the loader run.

And it seems to be the truth on Debian Buster:

nm libexec/rtapi_app | grep rtapi_message_buffer
000000000001fb40 B rtapi_message_buffer
nm rtlib/modules/rtapi.so | grep rtapi_message_buffer
0000000000049060 b rtapi_message_buffer

But when just adding extern on Ubuntu 21.04 we get:

nm ../libexec/rtapi_app | grep rtapi_message_buffer
0000000000020540 B rtapi_message_buffer
nm ../rtlib/modules/rtapi.so | grep rtapi_message_buffer
                 U rtapi_message_buffer

(BTW, that being said one global buffer seems to me like no-so-good code...)

cerna commented 3 years ago

@rene-dev, Been able to build and run on Ubuntu 21.04 with branch ubuntu-21.04.

(Took me a while to remember/discover that the error I am seeing in the rtapi_msgd daemon is because I am in Docker container and do not have DBus there. The error propagation is terrible.)

(The solution still seems like a bug, but that is for another time.)