On Thu, 09 Jun 2022 at 09:56:42 +0100, Julian Gilbey wrote:
> OK (and yes, it does require the full path at runtime). What triplet
> do I use in d/rules? dpkg-architecture offers 6 different ones:
> DEB_{BUILD,HOST,TARGET}_{GNU_TYPE,MULTIARCH}? I'm guessing
> DEB_TARGET_MULTIARCH, but I'm really not certain, so it would be great
> to confirm that.
You'd want DEB_HOST_MULTIARCH here (or use ${LIB} as I mentioned in a
previous message to this thread).
DEB_BUILD_* is the architecture you are building *on*. For example,
if you cross-build ARM packages on an x86 machine, DEB_BUILD_* is x86.
Only use this rarely, for instance if you are compiling a program that
you will run during the build but not install into the package. If you
don't know that this is the correct choice then it probably isn't.
DEB_HOST_* is the architecture you will run the built code on. For example,
if you cross-build ARM packages on an x86 machine, DEB_HOST_* is ARM.
This is usually the interesting one in practice.
DEB_TARGET_* is almost never relevant: it only matters if you are
compiling a compiler.
*_MULTIARCH is the normalized multiarch tuple, for example i386-linux-gnu
on the i386 architecture.
*_GNU_TYPE is the GNU tuple to be used by Autotools build systems and
to choose a cross-compiler, for example i686-linux-gnu on the i386
architecture.
> About the location, though: why do compiled Python libraries live in
> /usr/lib/python3/dist-packages/<pkgname> and not
> /usr/lib/<triplet>/<pkgname>?
The Python jargon for a native C/C++ library that can be loaded to
provide a Python module is an *extension*.
If a program will load a shared object as a plugin, then the shared object
needs to be installed into whatever directory the program has chosen as
the location where it looks for plugins, otherwise the program will not
find it: it is the program's choice, not the plugin's choice.
Python extensions are like plugins for Python, and Python has chosen
/usr/lib/python3/dist-packages as one of several locations where it looks
for extensions (specifically, extensions that come from a package other
than Python itself), so that is where you have to put them. If the extension
that implements the "foo" module is somewhere else, then Python code that
does "import foo" won't find it.
(Analogous: if a package wants to provide a plugin for GStreamer, it has
to put it in /usr/lib/<triplet>/gstreamer-1.0. If it puts the plugin
anywhere else, GStreamer will not find it and the plugin will be useless.)
The shared object also needs to follow the naming convention and API that
the program that will load it has chosen. The naming convention that Python
has chosen is that if you will load the module with "import foo", then
the filename is something like "foo.cpython-310-x86_64-linux-gnu.so" or
"foo.abi3.so", and it must export a symbol named "PyInit_foo" with a
particular signature.
Something that might be confusing you is that for a lot of Python modules
that are implemented in C, the thing that API users are meant to import
directly is Python code, and the Python code internally imports an
extension with a different name. For instance, to use python3-dbus,
you "import dbus", but the lower-level C code that implements that is
actually in a private extension named "_dbus_bindings" (so the filename is
_dbus_bindings.cpython-310-x86_64-linux-gnu.so). As an API user, you are
not meant to "import _dbus_bindings", but the Python code in python3-dbus
needs to be able to do that in order to do its job.
> And is there a good reason not to do
> the same with this Python-package-specific library?
If it isn't a Python extension (cannot be loaded into Python with
"import foo" to provide a module API to Python code) then it would seem
inappropriate to put it in the directory that is reserved for Python
extensions.
> It's not for
> general use, so I can't see why I shouldn't put it in the python3
> directory with the other compiled Python module libraries.
Because it isn't a Python extension (what you are calling a "compiled
Python module library"), but instead some other sort of library with a
different purpose (from your other messages, it seems like it's being
injected into a program that is being debugged with gdb).
smcv
