On Fri, Apr 29, 2022 at 10:50 PM Steve Langasek
<steve.langasek@ubuntu.com> wrote:
> I think your main question has been addressed. But I want to ask, why is it a
> problem to have part of this code with LTO enabled? Generally we disable
> LTO only when it is causing build failures. Was that the case here?
I don't think it's related to *part* of the build using LTO, and the
rest not. That was just an observation I made when I saw that
krb5-config --libs was also exporting lto flags, and I filed [4] for
it.
What prompted disabling lto is that mariadb was crashing[1] when it
couldn't initialize the io_uring queue due to a low RLIMIT_MEMLOCK
value we have by default. That baffled upstream, as the code should be
treating that exception[5], but instead we get an abort. They
investigated[2] and suspected lto was to blame. I tried a build
without lto, and it worked.
Two things out of this, at least:
- why wasn't the exception caught when lto was enabled? gcc bug,
mariadb bug, or something else?
- should we bump our RLIMIT_MEMLOCK value from 64kbytes to something
higher? There is an upstream commit[3] in systemd to bump it to 8Mb. I
added a systemd task to the bug[1] about this
1. https://launchpad.net/bugs/1970634
2. https://jira.mariadb.org/browse/MDEV-25633
3. https://github.com/systemd/systemd/commit/852b62507b2
4. https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1970979
5. https://bugs.launchpad.net/ubuntu/+source/mariadb-10.6/+bug/1970634/comments/7
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
