orpiske edited a comment on pull request #2141: URL: https://github.com/apache/camel-k/pull/2141#issuecomment-800990117
> Cool, do we need CGO in non-fedora? > > Btw, the released `kamel` is usually built on my Fedora laptop (never at latest version) I believe this might be a problem when/if we start building Camel K on any system that uses glibc 2.32 or newer. The reason is that on 2.32 [they moved some of the pthread_*sigmask](https://sourceware.org/pipermail/libc-announce/2020/000029.html) symbols [from libpthread to libc](https://sourceware.org/pipermail/glibc-cvs/2020q2/069412.html). Therefore any binary built against 2.32, that uses pthread_* symbols won't work on older versions. The opposite is not true, though. This is the kamel released: ``` objdump -T kamel | grep pthread 0000000000000000 DO *UND* 0000000000000000 GLIBC_2.2.5 pthread_mutex_lock 0000000000000000 DO *UND* 0000000000000000 GLIBC_2.3.2 pthread_cond_wait 0000000000000000 DO *UND* 0000000000000000 GLIBC_2.2.5 pthread_mutex_unlock 0000000000000000 DO *UND* 0000000000000000 GLIBC_2.3.2 pthread_cond_broadcast 0000000000000000 DO *UND* 0000000000000000 GLIBC_2.2.5 pthread_create 0000000000000000 DO *UND* 0000000000000000 GLIBC_2.2.5 pthread_detach 0000000000000000 DO *UND* 0000000000000000 GLIBC_2.2.5 pthread_attr_init 0000000000000000 DO *UND* 0000000000000000 GLIBC_2.2.5 pthread_attr_getstacksize 0000000000000000 DO *UND* 0000000000000000 GLIBC_2.2.5 pthread_attr_destroy 0000000000000000 DO *UND* 0000000000000000 GLIBC_2.2.5 pthread_sigmask ``` This is the one built on Fedora 33: ``` objdump -T kamel| grep pthread 0000000000000000 DO *UND* 0000000000000000 GLIBC_2.2.5 pthread_mutex_lock 0000000000000000 DO *UND* 0000000000000000 GLIBC_2.3.2 pthread_cond_wait 0000000000000000 DO *UND* 0000000000000000 GLIBC_2.2.5 pthread_mutex_unlock 0000000000000000 DO *UND* 0000000000000000 GLIBC_2.3.2 pthread_cond_broadcast 0000000000000000 DO *UND* 0000000000000000 GLIBC_2.2.5 pthread_create 0000000000000000 DO *UND* 0000000000000000 GLIBC_2.2.5 pthread_detach 0000000000000000 DO *UND* 0000000000000000 GLIBC_2.2.5 pthread_attr_init 0000000000000000 DO *UND* 0000000000000000 GLIBC_2.2.5 pthread_attr_getstacksize 0000000000000000 DO *UND* 0000000000000000 GLIBC_2.2.5 pthread_attr_destroy 0000000000000000 DO *UND* 0000000000000000 GLIBC_2.32 pthread_sigmask ``` So, I am guessing it may be a problem on any/most of the distros where the ABI is incompatible so crossing these version boundaries may be problematic. So, yes, I think we might need to rely on CGO to ensure we have statically-linked binaries for the time being (specially since it looks like more changes like this will happen in the future). ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
