Search code examples
c++linuxposixsolaris

portability of the sys/siginfo.h which approach to use


I am porting old code from Solaris to Linux. in one file I have the include:

#include <sys/siginfo.h>

that of course I can't find it anymore in Linux. So I tried to include the new one in:

#include <asm/siginfo.h>

but I had a lot of problem trying to compile it (of course) and had errors like:

/usr/include/asm-generic/siginfo.h:8:15: error: redefinition of ‘union sigval’
/usr/include/asm-generic/siginfo.h:11:3: error: conflicting declaration ‘typedef int sigval_t’
} sigval_t;

and so on. So I thought that maybe I could be more independent from the operating system and try to use directly the standard:

#include <signal.h>

that it let disappear the errors of before. But of course I got:

error: ‘SIGLOST’ was not declared in this scope

but in this way I could replace it with some new macro.. My question is: what is the best approach to porting an old sys/siginfo.h to the new environment. Using POSIX standard or the asm/siginfo.h? or other?


Solution

  • Definitely #include <signal.h>. If you look into linux/siginfo.h it warns you not to include the file directly, but to use signal.h instead. It is the public API for POSIX signals.

    The manpage shows that on the x86/ARM/most others, SIGLOST is not used. You may be hitting a part of your port that will take more effort than most. You will need to understand what function the SIGLOST handling is accomplishing in your code. In particular, if the code implemented and requires file locking, there are platform-dependent APIs and behaviors. In this case, you might consider rewriting the file locking module altogether to be sure the behavior is correct.

    Unless you can delete it altogether. Be sure you understand the limitations of file locking before spending time here. For example, the difference between advisory and mandatory locks (the latter is unreliable on Linux).