Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

162
Vistas
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?

over 4 years ago · Santiago Trujillo
1 Respuestas
Responde la pregunta

0

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).

over 4 years ago · Santiago Trujillo Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda