librsvg fails to cross build from source for a fair number of reasons.

The first issue to run into is the locales dependency. The package is
Arch: all and not Multi-Arch: foreign. Rather than figuring out how to
make it work, I observe that it is only used inside dh_auto_test, so
annotating the dependency <!nocheck> is feasible. At that point, it
becomes irrelevant to cross building.

With that change in place, librsvg's dependencies become theoretically
satisfiable. Unfortunately, apt sees a difference to practice. The rustc
and cargo dependencies are interpreted has host architecture
dependencies, so they would get us tools that cannot be run. Since they
are multi-target tools, we need their native version. While the rustc
dependency normally includes libstd-rust-dev, it gets us the wrong
libstd-rust-dev once rustc is annotated :native, so libstd-rust-dev must
be added to Build-Depends explicitly.

At this point, Build-Depends can be installed. Unfortunately, meson
refuses to configure. It objects to enabling the introspection and vala
features as we cannot run host binaries. Indeed, there is no known way
to run the g-ir-scanner without actually running host binaries, but on
Debian the tool hides this fact and transparently uses qemu when needed,
so meson doesn't actually get to run host binaries. For vala, the story
is different. It actually doesn't require running host binaries. I'm not
sure whether removing the "meson.can_run_host_binaries()" calls is
acceptable upstream, but it certainly is not generally correct.

With that change, meson manages to configure librsvg. Unfortunately, it
does not pass a host triplet to cargo, so the Rust components are built
for the build architecture. librsvg's meson.build expect that you pass
the relevant triplet via -Dtriplet= and to be precise, a Rust triplet
rather than a GNU triplet is expected here.
/usr/share/rustc/architecture.mk can compute the relevant value.

Then, the build proceeds quite far until meson launches the wrong
vapigen. This is not a bug in librsvg but in meson itself and it is
reported as #1126007.

Please consider applying the attached patch.

Helmut

Hello,

Bug #1152880 in librsvg reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/gnome-team/librsvg/-/commit/00d5e89fe23e4594cbcbbea56500f05deb4938ae
------------------------------------------------------------------------
Improve cross building

+ Mark locales as only needed for build tests
+ Use a native Rust toolchain
+ Pass the triplet option to meson
+ Add cross.patch: Reduce introspection and vala requirements

Closes: #1152880

Gbp-Dch: Full
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1152880

Actually we can, if `meson env2mfile` is used to generate a cross-file
that sets exe_wrapper to the Debian-specific
MULTIARCH-cross-exe-wrapper. This is a long-standing feature request for
debhelper, which currently uses the deprecated debcrossgen tool, which
the meson maintainer doesn't want to improve any further (see also
#1111001, https://salsa.debian.org/debian/debhelper/-/merge_requests/127)
but `export MESON_USE_NEW_CROSSGEN=1` in debian/rules should be enough
to make this work.

I think using `meson env2mfile` would be preferable to patching the
upstream build system to pretend that introspection can work without the
ability to run host binaries.

If the build uses `meson env2mfile`, then recent Meson should resolve
this without necessarily needing to look up vapigen via pkg-config,
because https://github.com/mesonbuild/meson/pull/15056 was merged.

(Or the cross-file
/usr/share/meson/cross/${DEB_HOST_GNU_TYPE}-vala.ini is also available.)

     smcv

We believe that the bug you reported is fixed in the latest version of
librsvg, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1152880@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Jeremy Bícha <jbicha@ubuntu.com> (supplier of updated librsvg package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Tue, 03 Nov 2026 00:40:04 +0100
Source: librsvg
Built-For-Profiles: derivative.ubuntu noudeb
Architecture: source
Version: 2.63.4+dfsg-2
Distribution: unstable
Urgency: medium
Maintainer: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Changed-By: Jeremy Bícha <jbicha@ubuntu.com>
Closes: 1038252 1152880
Changes:
 librsvg (2.63.4+dfsg-2) unstable; urgency=medium
 .
   [ Helmut Grohne ]
   * Improve cross building (Closes: #1152880)
     + Mark locales as only needed for build tests
     + Use a native Rust toolchain
     + Pass the triplet option to meson
     + Add cross.patch: Reduce introspection and vala requirements
 .
   [ Jeremy Bícha ]
   * Remove 2 i386 workaround patches that are no longer needed
     (Closes: #1038252)
   * Remove some reftest workarounds
Checksums-Sha1:
 0eb78dff3ddba35ca9a5891a74ca1a502e6963d0 8773 librsvg_2.63.4+dfsg-2.dsc
 dd58d9076cd6b3685160ebedae3041eb927683dd 14230244 librsvg_2.63.4+dfsg-2.debian.tar.xz
 47572a26aeb47a6deaa41eaa35da14e78f4b6107 9806 librsvg_2.63.4+dfsg-2_source.buildinfo
Checksums-Sha256:
 9d846ad7c1abdcd380beb25c68ef3ff00a5f1a04cd23b2c729a49df2445f8a9e 8773 librsvg_2.63.4+dfsg-2.dsc
 bf0c6228cdc6017a74f3b9e11897595789f88af61061ed2c250957567b69d39f 14230244 librsvg_2.63.4+dfsg-2.debian.tar.xz
 198ae0d723d0d23c46435f2f900bb78c93abb7bb572c7ada7edd149425218c5c 9806 librsvg_2.63.4+dfsg-2_source.buildinfo
Files:
 696d1a7ea9ac0bb3f2fe8dbf333df894 8773 libs optional librsvg_2.63.4+dfsg-2.dsc
 06693d554839194acd785f3a5cb26724 14230244 libs optional librsvg_2.63.4+dfsg-2.debian.tar.xz
 982c2e6bdfb2e9ddec44e67776ab4a9d 9806 libs optional librsvg_2.63.4+dfsg-2_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEETQvhLw5HdtiqzpaW5mx3Wuv+bH0FAmrpH7YACgkQ5mx3Wuv+
bH1nYw/+IY2O3FotOsHVO46gpfId9zWRjwu4miW0Y4AMfHbkbPpHRS/BmeKiw3X8
n+2HQOJYY7dXzvlRhYWKYWMK8ENM1APv6iSU/qzScA/OoCdoT5jvEG931+rTLBTL
ldG9jVTZqbPtkHXcayfA4+bVHyriWiB7a4iZrMbboeT+rqim8/mPkskrFALMDRqe
0pABXxEHvbgwvctsUxB8kciFtxBAxPlSE90fd4UKExtoNkfElkjuTXeXwAhsBZyR
fz+BnKg7IyiZLyXfmg7QV/inL1B4sSb1OsJo9KBciqFV8P+6aIPuYWivRq2jF9fD
KD+JY+uOenC0MZIReb8usZdQ+GNsISwSmBO1a2L7+StYFOaEcKZ3SJeii5w3/Z+z
ueq8xbEXiZvxYhrhzNJB+Dcfk76wlHyeeyBOoNfuuvNDKPQOPriG/U3h9Nt4sIeA
RbjyEq2wxkAgZ5KUx6Exaatrp6DYLVREDh49cQ3ejif/v285mMviVjMlHdaN4no9
tyQ40a15z5X8wul/DXFKM77sHvcoWlUr3Fh7ELGYC+y5b2/wA+icvRNQ/MyexQhp
GB9sB6Q8jTeG2qUNp/EbQFpf+cewTRqANKadZDAQUeKxA4p61qDe7yMHJMxgXkXj
RqOEtYDDHh0KWWvwrKb1yVfBvOh1Qlh++RA7Bboa34fCToO0SXk=
=KEVq
-----END PGP SIGNATURE-----

Hi Simon,

I agree that improving meson would be preferable, but that does not seem
to be a practical option with an uncooperative meson maintainer and an
upstream that we angered in social interaction.

I agree that the patch likely is not upstreamable. It was meant more as
a stop-gap solution demonstrating the cause and also highlighting
existsing meson bugs. At least in the vala case, I believe the upstream
way is technically wrong, but I'm not sure what a good solution is.

In any case, I won't object to using other solutions and shall continue
to work towards making env2mfile available.

Be that as it may be, but meson should default to a way that just works.
Requiring all packages to provide such aspects via a cross-file when
pkg-config can readily discover it is backwards. I therefore see this as
a meson problem, not as a librsvg problem. The sheer amount of packages
affected by this very bug (I count at least 53) makes it clear that it
should be fixed there.

Given that Jeremy uploaded my patch already, I would like to know
whether I should rework the patch to use MESON_USE_NEW_CROSSGEN or
whether we should keep the new status quo until meson gets fixed.

Helmut