Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Armel link error #51

Closed
sccplg opened this issue Mar 1, 2014 · 1 comment
Closed

Armel link error #51

sccplg opened this issue Mar 1, 2014 · 1 comment

Comments

@sccplg
Copy link

sccplg commented Mar 1, 2014

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
@rakshasa
Copy link
Owner

rakshasa commented Mar 1, 2014

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.

@rakshasa rakshasa closed this as completed Mar 1, 2014
@rileymat rileymat mentioned this issue May 24, 2014
Closed
anthonyryan1 pushed a commit to anthonyryan1/libtorrent that referenced this issue Oct 29, 2016
replace signal() call with sigaction() for better portability
2cd70f4 
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
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@rakshasa @sccplg