|
From: | Kenneth Loafman |
Subject: | Re: [Duplicity-talk] Duplicity 1.0.1 Released |
Date: | Tue, 18 Oct 2022 12:43:43 -0500 |
Ken,I am sure I am confused! Thanks for the pointers setting me straight.But your comment made me realize that I had competing versions of python here. I have now adjusted things so that it should always be using Python 3.8.13 by replacing references to "/usr/bin/env python3” to “/opt/sw/bin/python3.8” which is my target version of python. I may try upgrading to python3.10 sometime in the indefinite future.This now builds "_librsync.cpython-38-darwin.so” and moves it to the duplicity directory. However, I am still having issues with the tests. They seem unable to load the _rsyncmodule.By finding and substiting python3.8 for all the /bin/env python3 lines, it now passes the tests as it should and builds the deb package.Thanks for your help. Sorry about my confusion on which python I was running!-ScottOn Oct 17, 2022, at 11:22 AM, Kenneth Loafman <kenneth@loafman.com> wrote:Scott,I think you are confused.When I refer to _librsync.so it is really _librsync.cpython-39-darwin.so that I'm referring to. The middle part will change depending on which python and its version it's compiled against. And no, _librsyncmodule.o is not needed at all once the compile and link have finished. The build directory is strictly transitory.librsync is a requirement for duplicity. See README.md. So yes, testing would fail, but setup would fail before that._librsyncmodule.c is the C interface to librsync.so in the system libraries. It is compiled and linked against the system librsync.so producing duplicity/_librsync.so as a shim to the library. On most systems, both /usr/lib and /usr/local/lib are in the path for linker. On the Mac and some other systems, only /usr/lib is in the path for the linker, thus we add LIBRSYNC_DIR during setup to account for that. This is passed to setup.py to add extra dirs to link against and include in compiles....Ken
[Prev in Thread] | Current Thread | [Next in Thread] |