-
-
Notifications
You must be signed in to change notification settings - Fork 209
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Armel link error #51
Comments
I can't help with compile issues on weird platforms, unless it involves actual information on how to fix it so as to allow me to commit changes. |
Closed
anthonyryan1
pushed a commit
to anthonyryan1/libtorrent
that referenced
this issue
Oct 29, 2016
signal() is known to have portability problems. Some systems such as old Unix systems and System V employ a behavior in which the signal disposition is reset to SIG_DFL (default) upon invocation of a signal handler by the delivery of a signal. See issue rakshasa#51 in which Solaris users experience signal-based issues. Solaris is a system which employs the SIG_DFL reset behavior even in version 11.1. See http://docs.oracle.com/cd/E26502_01/html/E29034/signal-3c.html > If signal() is used, disp is the address of a signal handler, and sig is not SIGILL, > SIGTRAP, or SIGPWR, the system first sets the signal's disposition to SIG_DFL before > executing the signal handler. On Solaris the default signal disposition for SIGUSR1 is to exit the application. See http://docs.oracle.com/cd/E26502_01/html/E29033/signal.h-3head.html If I'm correct in assuming this is the problem Solaris users are encountering, the solution to this (and likely any other portability issues that may arise) is to use sigaction() which has explicitly defined behavior as per the POSIX standards. As you can see, it's a pretty drop-in solution. In fact, on some systems such as Linux, glibc defines signal() as a wrapper around sigaction() to use BSD semantics (i.e. not the behavior detailed above), which is likely why few others have experienced these problems. See http://man7.org/linux/man-pages/man2/signal.2.html
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
I tried to compile directly on qemu-arm libtorrent for armel but I got the following problem:
../src/protocol/.libs/libsub_protocol.a(request_list.o): In function torrent::RequestList::delegate():/home/buildd/coding/libtorrent/src/protocol/request_list.cc:159: undefined reference to torrent::Delegator::delegate(torrent::PeerChunks_, int)
collect2: ld returned 1 exit status
make[3]: *_* [LibTorrentTest] Error 1
My configure parameters:
. / configure - build = arm-linux-gnueabi - prefix = / usr - includedir = $ {prefix} / include - mandir = $ {prefix} / share / man - INFODIR = $ {prefix} / share / info - sysconfdir = / etc - localstatedir = / var - libdir = $ {prefix} / lib / arm-linux-gnueabi - libexecdir = $ {prefix} / lib / arm-linux-gnueabi - disable-maintainer-mode - disable-dependency-tracking - enable-ipv6 - disable-instrumentation
how to solve?
thanks
The text was updated successfully, but these errors were encountered: