-
-
Notifications
You must be signed in to change notification settings - Fork 996
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
Python binding fails to build: can't create dynamic relocation R_X86_64_32 against local symbol in readonly segment #6890
Comments
I think this is the problem.
https://www.libtorrent.org/building.html#build-features With |
Shouldn't this be a default in the project? |
I don't know about that that but if you used the flag when building it's in the build path like Try it and see if it works. |
I use setup.py to build, How do I pass |
According to the docs here https://www.libtorrent.org/python_binding.html I think it's like this, maybe @AllSeeingEyeTolledEweSew can confirm, since I only build it using b2
|
Adding |
|
arvid added the feature It conditionally defaults on: libtorrent/bindings/python/Jamfile Lines 157 to 162 in 34c75eb
If the defaults aren't working on FreeBSD, I believe this block should probably be updated. @arvidn? In the meantime, try
|
Same with |
there's already a
|
But it doesn't solve the problem. |
|
If the Op has already built Or will that lib have no effect on the outcome of the binding? I'm not sure how the python build works to be honest and I only build it using b2 + boost source in docker and using fpic just works. |
Shared libraries can only be built with fpic option. |
Then maybe do this and use the debug to see if there is more helpful info?
I think using
To be honest I can't test anything on that OS as i only used Debian based or Alpine. |
passing |
The link command is what's failing, but we need to know what's passed to clang. It should be passing (or something else is going on, like build artifacts are staying around when they should be rebuilt) |
Here is a log with |
the command line I see in that log does not have
|
Sorry, this was due to a typo. |
it looks like the extension is built twice: The first time:
That does the tight thing. In fact However, that invocation won't produce a binary, it just prints the command lines that would have run. The second time:
This is the one that fails. Note how it does not have Where does this second invocation come from? perhaps the python stack trace at the bottom is a clue:
|
Hello, are there any news on setup.py build? |
No fix since the 28th of May ? what shall we do to install Deluge then ? |
For Python bindings pybind11 is really great. Yesterday I created a binding for an unrelated project and it was a breeze. It only requires 1 C++ source file and 1 cmake script. Why can't this project use pybind11? |
I'm not sure what the underlying script is doing, but it looks like it's invoking
Looks like it may be doing It's important to note that TL;DR I think the script should be doing Since this looks like a distro build script though, you might also want to build the python bindings with dynamic linking. By default, they statically link libtorrent. You'd need something like:
I haven't used pybind11, but I've looked at it, and I like it MUCH more than boost.python. It's on my long-term list to convert the python bindings to pybind11. But libtorrent's API surface is huge (much more than "only 1 source file"), and we really need to backport our test suite from This issue isn't about boost.python though. It's about the build system. Arvid supports b2 as the primary build system of libtorrent, for better or worse. |
@arvidn |
or maybe you want |
It's beyond my knowledges and understanding here. I tried the setup.py b2 commands but ... https://www.truenas.com/community/threads/issues-with-deluge-on-truenas-12-u2.92105/post-720208 |
@yozart I tried sorting through those scripts but it's a bunch of freebsd-specific stuff, some of it declarative. I don't know anything about freebsd. Can you point me to the thing that tries to build libtorrent? |
@AllSeeingEyeTolledEweSew - TL;DR is that the key is downgrading the "py39-libtorrent-rasterbar" package/port to an older version pre-dating this bug (version 1.2.16). This was enough for me to get deluge working. If anyone working on this from the project needs a) a FreeBSD VM and b) a quick conversation to get the basics of the FreeBSD ports/packages systems down I can provide that. |
I have been working on this a bit on the FreeBSD ports side and got things to build and run at least but it is a bit hacky since I am not proficient at writing ports or configuring boost/Jamfile things. I would gladly take any help on this. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264970 (patch also updates deluge but you can ignore that part) Direct link to diff/patch in question (up to date as of right now but may break if/when further patches are pushed) https://bugs.freebsd.org/bugzilla/attachment.cgi?id=238177&action=diff The problems I couldn't really solve in a nice way:
Thanks to everyone in the thread for pointers and especially @AllSeeingEyeTolledEweSew for your comment, that helped a lot #6890 (comment) 👍 |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Revision: 2.0.6-27-g34c75eb5f
clang-13.3
FreeBSD 13.1
The text was updated successfully, but these errors were encountered: