qnx build error on 1.13.3 release: 'sighandler_t' was not declared in this scope

[Michael-Fridman]

build env: building on Ubuntu 18.04.5 LTS to QNX 7.1.0 (SDP toolchain) Poco 1.13.3

Error: I'm trying to build Poco 1.13.3, but getting the following error: poco-1.13.3-all/Net/src/SocketImpl.cpp: In member function 'Poco::Int64 Poco::Net::SocketImpl::sendFile(Poco::FileInputStream&, Poco::UInt64)': poco-1.13.3-all/Net/src/SocketImpl.cpp:1443:2: error: 'sighandler_t' was not declared in this scope sighandler_t sigPrev = signal(SIGPIPE, SIG_IGN); ^~~~~~~~~~~~ poco-1.13.3-all/Net/src/SocketImpl.cpp:1443:2: note: suggested alternative: 'sa_handler' sighandler_t sigPrev = signal(SIGPIPE, SIG_IGN); ^~~~~~~~~~~~ sa_handler poco-1.13.3-all/Net/src/SocketImpl.cpp:1449:18: error: 'sigPrev' was not declared in this scope signal(SIGPIPE, sigPrev != SIG_ERR ? sigPrev : SIG_DFL); ^~~~~~~ poco-1.13.3-all/Net/src/SocketImpl.cpp:1449:18: note: suggested alternative: 'strrev' signal(SIGPIPE, sigPrev != SIG_ERR ? sigPrev : SIG_DFL);

Reason and proposed solution: from signal(2) — Linux manual page: The use of sighandler_t is a GNU extension, exposed if _GNU_SOURCE is defined

I've tried to pass the flag ' -D_GNU_SOURCE' to C and C++ flags, and in toolchain.cmake, but it didn't work. also tried to define it in poco-1.13.3-all/Net/src/SocketImpl.cpp: #define _GNU_SOURCE

but it didn't solve the error.

the only thing that helped was to define sigPrev as void (*sigPrev)(int); (which is the definition of sighandler_t). method after fix: Poco::Int64 SocketImpl::sendFile(FileInputStream &fileInputStream, Poco::UInt64 offset) { FileIOS::NativeHandle fd = fileInputStream.nativeHandle(); Poco::UInt64 fileSize = fileInputStream.size(); std::streamoff sentSize = fileSize - offset; Poco::Int64 sent = 0; void (*sigPrev)(int); sigPrev = signal(SIGPIPE, SIG_IGN); while (sent == 0) { errno = 0; sent = _sendfile(_sockfd, fd, offset, sentSize); } signal(SIGPIPE, sigPrev != SIG_ERR ? sigPrev : SIG_DFL); return sent; }

with this change, Poco compiled successfully.

it is also mentioned in the man file that: "WARNING: the behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. See Portability below." so, maybe it is worth considering switching to sigaction.

bottom line: can you add the fix or suggest a better approach?

Thanks, Michael

[aleks-f]

I'm not sure how much effort would it be to switch, but if you send a proposal in the form of pul request, it would help to speed the process

[github-actions[bot]]

This issue is stale because it has been open for 365 days with no activity.