Closed rene-dev closed 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.
I already tried that, doesn't work.
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'
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];
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 to
rtapi_message_buffer' /usr/bin/ld: /home/rene/dev/machinekit-hal/src/rtapi/rtapi_support.c:99: undefined reference tortapi_message_buffer' /usr/bin/ld: /home/rene/dev/machinekit-hal/src/rtapi/rtapi_support.c:100: undefined reference to
rtapi_message_buffer' /usr/bin/ld: /home/rene/dev/machinekit-hal/src/rtapi/rtapi_support.c:105: undefined reference tortapi_message_buffer' /usr/bin/ld: /home/rene/dev/machinekit-hal/src/rtapi/rtapi_support.c:107: undefined reference to
rtapi_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
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...)
@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.)
Im trying to build on ubuntu 21.04 with gcc 10 and hitting this error:
I cannot figure out whats going on, possibly this is related to https://github.com/machinekit/machinekit-hal/issues/346?