[p-m] Mir FTBFS on arm64

[Simon Quigley]

Mir FTBFS in plucky-proposed. The version there is 2.14.1, but I just uploaded 2.19.3 to Debian Experimental.

I'd like to get this in for Plucky and turn this into an FFE bug, but for now, please don't sync from Debian Experimental without asking me, someone from the Mir Team, or Mike Gabriel, and please either remove the upload from proposed to clear the report or fix the arm64 failure in 2.14.1.

[Mike Gabriel (sunweaver)]

Please note that FTBFSes on arm* have been resolved in mir 2.14.1-8 (Debian unstable). Maybe sync that version first?

@tsimonq2 I'd go with a well tested Mir 2.14 for 25.04 and wait with Mir 2.19 for 25.10.

On the Lomiri part, Mir 2.19 and the not yet even public qtmir counterpart are so bleeding edge they are not fit for a distro release imho. This might be a problem for Lubuntu, though. So let's get everything (Mir 2.19, qtmir with Mir 2.19 API compliance) staged in Debian experimental and test how everything goes on the Lomiri side.

[Simon Quigley (tsimonq2)]

> Please note that FTBFSes on arm* have been resolved in mir 2.14.1-8 (Debian unstable). Maybe sync that version first?

Unfortunately, that's the exact version having the issue: https://launchpad.net/ubuntu/+source/mir/2.14.1-8

> This might be a problem for Lubuntu, though.

With my Release Manager hat on, we want to strike a balance between stability and features. If it's more "green" than it should be, that's okay if it at least functions, in a non-LTS.

Let's wait until we have test builds going for all of it, and make the call at that point with more information.

[Simon Quigley (tsimonq2)]

The bug still stands for Mir, but it looks like QtMir gained support for dual Mir versions. This is great, thanks!

[Christian Ehrhardt (paelzer)]

Hey, we've been discussing this in the release sprint.
While it is a goal to get all buildable, but it is probably too late for this.
If it needs an SRU it would need to be fixed as part of that.

FYI -8 also was FTBFS https://launchpad.net/ubuntu/+source/mir/2.14.1-8
The request then was to remove it, see https://bugs.launchpad.net/ubuntu/+source/mir/+bug/2103888

Let us therefore drop it from blocking milestones, reach out if you think totally different on this

[Rik Mills (rikmills)]

mir 2.20.2-2 in questing-proposed still FTBFS on arm64

[Rik Mills (rikmills)]

This is now causing qtmir 0.8.0~git20250407.ea2f477-1 to be blocked in questing-proposed

Missing build dependencies: libmircommon-dev (>= 2.20.0~), libmirserver-dev (>= 2.20.0~), mir-renderer-gl-dev (>= 2.20.0~), mirtest-dev (>= 2.20.0~), libmiroil-dev (>= 2.20.0~), libmirwayland-dev (>= 2.20.0~)

which in turn is blocking lomiri updating from 0.3.0-4build1 to 0.5.0-2

Missing build dependencies: libqtmirserver-dev (>= 0.8.0~git20250305.794fa12-2~), qml-module-qtmir (>= 0.8.0~git20250305.794fa12-2~)

[Alan Griffiths (alan-griffiths)]

I assume this is the failure?

```
/usr/bin/ld: ../libmir-test-assist.a(mmap_wrapper.cpp.o): in function `std::literals::string_literals::operator"" s[abi:cxx11](char const*, unsigned long)':
/usr/include/c++/14/bits/basic_string.h:4696:(.text+0x650): undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, unsigned long, std::allocator<char> const&)'
/usr/bin/ld: /usr/include/c++/14/bits/basic_string.h:4696:(.text+0xa68): undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, unsigned long, std::allocator<char> const&)'
collect2: error: ld returned 1 exit status
```

We also see that on the Mir PPA arm64 build: https://launchpad.net/~mir-team/+archive/ubuntu/rc/+packages

This error (an undefined reference to `std::string::string(char const*, unsigned long, std::allocator<char> const&)`) comes from a failure to resolve one "standard library" function calling another "standard library" function.

I'm not sure that Mir contributes to this failure (other than by calling the first function). (I don't have an arm64 system to hand for investigation, will try later...)

[Rik Mills (rikmills)]

Just found that the issue is also discussed in: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/2070302

where it is claimed to be LTO related.

[Rik Mills (rikmills)]

Can confirm that disabling LTO on a ppa build does result in a successful build on arm64

[Sebastien Bacher (seb128)]

The debian/rules has a check to disable LTO on ld 2.43.1 but it seems that is still needed for newer ld version so I've uploaded an update removing the version check for now

[Launchpad Janitor (janitor)]

This bug was fixed in the package mir - 2.20.2-2ubuntu2

---------------
mir (2.20.2-2ubuntu2) questing; urgency=medium

  * debian/rules:
    - update the disable LTO hack to not apply to a specific ld version
      we got an update and the build issue is still there (lp: #2099790)

 -- Sebastien Bacher <email address hidden> Tue, 08 Jul 2025 15:11:14 +0200