the definition of the type sem_t in /usr/include/semaphore.h was in glibc-2.3.2 a struct: /* System specific semaphore definition. */ typedef struct { struct _pthread_fastlock __sem_lock; int __sem_value; _pthread_descr __sem_waiting; } sem_t; and now it's a union (now it's actually in /usr/include/bist/semaphore.h, included from /usr/include/semaphore.h): typedef union { char __size[__SIZEOF_SEM_T]; long int __align; } sem_t; whereas this might not seem a big deal, some code fails to compile after this change. for example, I'm having problem with the helix community source code at https://helixcommunity.org/ , where they are subclassing sem_t: struct HXsem_t : public sem_t { char padding[64]; /* Flawfinder: ignore */ // different linux versions have different binary reps blechhhh! }; which works with sem_t being a struct, but does not work with sem_t being a union. Reproducible: Always Steps to Reproduce: 1. emerge glibc-2.3.3 2. try to compile helix sources (or just the class HXsem_t listed above) 3. see the error message: error: base type `sem_t' fails to be a struct or class type Actual Results: the code fails to compile, which compiled fine with glic-2.3.2 Expected Results: the code should compile I don't really know whos fault is this. I looked at the GNU libc documentation at http://www.gnu.org/software/libc/manual/html_mono/libc.html , and it does not say anything about sem_t, other than lists it as a parameter type for semaphore calls. OTOH, glibc-2.3.3 is still not officially out, and there may be a reason for that. this it's strange that it's already x86, not ~x86.
it seems that the difference in the semaphore.h header file is not related to the glibc version, but it's related to the nptl USE flag - if nptl is set, the union declaration is used, if not set, the old one is used. still, it's an issue that causes compilation problems.
I cannot see that that is going to change soon - get the helix people to fix their code for nptl.
the question is: is there a macro or any other compile-time method the tell if the glibc was compiled with NPTL support? in this case, it would be fairly easy to fix the helix code, with #ifdefs, for example.
yeah, the way sem_t is defined should not affect compilation of code if it does, that code is wrong linuxthreads made sem_t a struct, nptl uses union in terms of checking NPTL vs linuxthreads, i dont believe any official thing exists since the two should be drop-in replacements for each other
