Build Failure on OSX 10.6.8 about luaposix HOT 9 CLOSED

SIGPOLL is POSIX-mandated, so it's not a bug in luaposix.

You're welcome to supply a workaround patch for Darwin.

from luaposix.

(I'd prefer a patch that takes into account however Darwin gets around the lack of SIGPOLL, and hence provides equivalent functionality, but if that's too much work or not possible, then simply not having SIGPOLL on Darwin is OK.)

from luaposix.

(Edited signal names)

I suppose thats why they provide it if "_DARWIN_C_SOURCE" is not set.

How about this workaround. Judging from their signal.h SIGIOTand SIGEMT seem to be their replacement, whatever it means.

#if (!defined(_DARWIN_C_SOURCE))
set_const("SIGPOLL", SIGPOLL);
#else
set_const("SIGIOT", SIGIOT);
set_const("SIGEMT", SIGEMT);
#endif

Or we teach configure to not set _DARWIN_C_SOURCE, then apples headers seem to try to be more POSIX compliant.

from luaposix.

SIGABRT is already defined. (Again, it's POSIX-mandated.) The bit of header file you quote is defining SIGIOT to be SIGABRT, not defining SIGABRT.

SIGEMT seems to do something else entirely (it's about an emulated instruction; is this to do with Rosetta?) So it's not a replacement. I have no desire to support non-POSIX signals in luaposix.

As to not setting _DARWIN_C_SOURCE, what are the downsides of doing that? I presume it's set by default for a reason...

I'm sorry, I don't have time to learn about an OS I don't use; perhaps you could seek guidance elsewhere? I suggest the autoconf or gnulib mailing lists, as there seems to be a general point of interest here, namely, what is one supposed to do about the lack of SIGPOLL on Darwin, and hence there should really be a patch to autotools, or at least a gnulib module to handle the problem.

from luaposix.

I got my stuff sorted with commenting out SIG_POLL I don't use it eitherway, only wanted to help to get luaposix be more compatible and make the life for others easier. If you don't care, then lets just stop and forget it.

from luaposix.

I certainly do care, but I would rather this issue were fixed where it should be fixed, not in luaposix. (Of course, really it should be fixed in Darwin, but in the absence of that, a fix that helps all GNU autotools-based software is the best we can do.)

If you don't want to do that, then can you please just supply a simple patch that tests #ifdef SIGPOLL, with a comment explaining this is a workaround for Darwin, and then at least you've helped Darwin users of luaposix.

from luaposix.

I don't think its apple's nor gnulib's problem.

Gnulibs point of view: By default lets turn on all System extenstions ( http://fossies.org/unix/privat/metalog-2.tar.gz:a/metalog-2/gnulib/m4/extensions.m4 ) Whatever that got them into this autoconf default policy. But they turn on _DARWIN_C_SOURCE like they turn on everything the system can do. Similar happens with all GNU extensions. I suppose most often people come complaining this or that doesn't work, because a system extension feature macro is not set.

Apples point of view: programs can either chose to have a standards compliant environment emulation, or can announce they know of our dirty tricks and extensions and say so with Macro (_DARWIN_C_SOURCE). Again GNU is not much different in this regard.

I suppose configure.ac needs to be taught not to include AC_USE_SYSTEM_EXTENSIONS if our full aim is to stick to the standard and not do with system extensions. Thats what we wand, no? I just don't yet see how. I use autoconf in my project myself, but I hate it, since I'm not even close to understand albeit many years of programming experience.

from luaposix.

Thanks for the analysis. I'll ask the gnulib folk what they think.

from luaposix.

Turns out that SIGPOLL (and also SIGPROF) are marked obsolescent, so I've removed them from luaposix in git master. This should cure your build problem. Thanks again for the report.

from luaposix.