When several non-interactive inkscape processes are started at the same
time, e.g. by a parallel "make -j", a good fraction of them abort:

  terminate called after throwing an instance of 'Gio::DBus::Error'
  Aborted

A command-line export should not depend on, or be able to fail because
of, the D-Bus session bus.  In practice this breaks any parallel build
that rasterizes SVG with inkscape, including indirectly: ImageMagick's
"convert foo.svg foo.png" delegates to inkscape whenever it is
installed.  That is how I hit it; usbview fails to build with -j28 on a
machine that has inkscape installed.

Reproducer (any SVG):

  for i in $(seq 1 20); do
    inkscape some.svg --export-filename=out$i.png >log$i 2>&1 &
  done; wait
  grep -l terminate log* | wc -l

Here 5-13 of the 20 processes abort on each run.  Run serially, all
succeed.

The GError being thrown (from gdb, catch throw Gio::DBus::Error) is:

  GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown:
    The name is not activatable

and the backtrace is:

  #0  __cxa_throw () from libstdc++.so.6
  #1  Gio::DBus::Error::throw_func(_GError*) () from libgiomm-2.4.so.1
  #2  Glib::Error::throw_exception(_GError*) () from libglibmm-2.4.so.1
  #3  Gio::Application::register_application() () from libgiomm-2.4.so.1
  #4  InkscapeApplication::InkscapeApplication() () from libinkscape_base.so.1.4.3.0
  #5  main ()

That is, the InkscapeApplication constructor registers the application
as a unique GApplication (org.inkscape.Inkscape) on the session bus,
even for a pure command-line export.  A second process sees the name
already owned, tries to act as a remote instance, the owning process
exits in the meantime, and the resulting exception is never caught, so
std::terminate aborts the process.

Observations:

 * Giving each process its own bus (dbus-run-session -- inkscape ...)
   makes all 20 succeed.
 * Unsetting DBUS_SESSION_BUS_ADDRESS does not help (13/20 failed),
   because GLib still finds the bus via $XDG_RUNTIME_DIR/bus.
 * Setting SELF_CALL=1 in the environment, which makes inkscape
   register as NON_UNIQUE, makes all 20 succeed.  This is the
   workaround barebox adopted:
https://lists.infradead.org/pipermail/barebox/2025-August/052403.html

Suggested fix: use G_APPLICATION_NON_UNIQUE whenever inkscape runs
non-interactively (export, --actions, --batch-process, --shell, or no
GUI), and at minimum catch the error from register_application() and
fall back to running locally instead of aborting.

Inkscape 1.4.3 (0d15f75042, 2025-12-25)
  GLib 2.90.1, GTK 3.24.52, glibmm 2.66.10, gtkmm 3.24.11
  Debian GNU/Linux forky/sid, amd64