[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Build and run-time triplets



Well, here's an update on this old thread...

On Thu, Jun 09, 2022 at 01:03:25PM +0500, Andrey Rahmatullin wrote:
> On Thu, Jun 09, 2022 at 08:42:28AM +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.
> The normal way for this is putting it into
> /usr/lib/<triplet>/pkgname/foo.so, and according to the code below you'll
> need the full path at the run time so you indeed need the triplet at both
> build and run time. You can get the triplet in d/rules, not sure how
> should you pass it to the build system as that depends on the build system
> used. For the run time, https://wiki.debian.org/Python/MultiArch suggests
> sys.implementation._multiarch (note that you cannot use it during the
> build as that would break cross-compilation etc.), not sure if there are
> better ways. 

I got all of the triplets working, but was then stymied when I tried
to specify Multi-Arch: same in the control file.  I got a lintian
warning: multi-arch-same-package-calls-pycompile
It seems that since the pybuild system (via dh_python3) adds a
py3compile command to the postinst of the package, then I can't safely
use Multi-Arch: same.

I don't know if this is the case for all python3 Arch: any packages
with compiled extensions; are they all effectively Multi-Arch: no?  Is
this worth thinking about in the longer term?

Best wishes,

   Julian


Reply to: