On Thu, Jun 09, 2022 at 11:23:26AM +0500, Andrey Rahmatullin wrote:
> On Wed, Jun 08, 2022 at 10:43:57PM +0100, Julian Gilbey wrote:
> > I'd like to ask for some help. I'm working on packaging pydevd, which
> > builds a private .so library. Ordinary extensions built using cython
> > or similar end up being called "foo.cpython-310-x86_64-linux-gnu.so",
> > but this library, which is not dependent on the Python version, should
> > presumably be called "bar.x86_64-linux-gnu.so".
> If it's just a private library and not a Python module it should be called
> bar.so.
>
> > Question 1: How do I determine (within Python) the triplet to use when
> > building the library?
> You don't.
>
> > Question 2: How do I determine (within Python) the triplet to use when
> > loading the library at runtime?
> You don't, but also how are you actually loading it?
Well, the upstream wanted to compile two versions of the library, one
for 64 bit architectures and one for 32 bit architectures. I don't
really want to build two different arch libraries in a single build,
because that seems very contrary to the way the Debian architectures
work, and would also limit it to the amd64/i386 architectures for no
obviously good reason. I had imagined that if there is some sort of
multiarch setup, one might have the amd64 and i386 packages installed
simultaneously, hence the need for different names. But I've never
done that myself, so I've no idea if it's even meaningful to do this.
The library is loaded into gdb using this code:
cmd.extend([
"--eval-command='call (void*)dlopen(\"%s\", 2)'" % target_dll,
"--eval-command='sharedlibrary %s'" % target_dll_name,
"--eval-command='call (int)DoAttach(%s, \"%s\", %s)'" % (
is_debug, python_code, show_debug_info)
])
where cmd is a list containing the gdb call, and target_dll and
target_dll_name point to the shared library.
Best wishes,
Julian
