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 32 (:
   
   ```
   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


Reply via email to