Ubuntu
krb5 package

krb5-multidev is not multi-arch installable due to differences in /usr/bin/krb5-config.mit

Bug #1980494 reported by Drew Ronneberg
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
krb5 (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

I am trying to build wine in a wow64 configuration and need to install the i386 and amd64 version of the krb5-multidev package on Ubuntu 22.04. The two version are not co-installable due to differences in the /usr/bin/krb5-config.mit file between the two version of the package.

The diff between the two files is:

--- krb5-config.mit-i386 2022-06-18 21:32:44.034889873 -0400
+++ krb5-config.mit-amd64 2022-06-18 21:31:37.302149522 -0400
@@ -40,7 +40,7 @@
 libdir=/usr/lib/${tripple}/mit-krb5
 CC_LINK='$(CC) $(PROG_LIBPATH) $(PROG_RPATH_FLAGS) $(CFLAGS) $(LDFLAGS)'
 KDB5_DB_LIB=
-LDFLAGS='-Wl,-Bsymbolic-functions -Wl,-z,relro'
+LDFLAGS='-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro'
 RPATH_FLAG=''
 PROG_RPATH_FLAGS=''
 PTHREAD_CFLAGS='-pthread'

The krb5-multidev package is co-installable on Debian. It appears that Ubuntu uses different default linker flags for the i386 and amd64 platforms and Debian does not.

This bug is related to https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1970979

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

https://wiki.ubuntu.com/ToolChain/LTO

LTO is not enabled for i386: "Compiler flags for LTO are injected in dpkg-buildflags, and can be overridden in the package build. LTO will be enabled on amd64, arm64, ppc64el and s390x. " I don't even know if lto can be enabled on 32bit architectures.

LTO are linker flags, so it's correct to have them exposed in LDFLAGS.

Foundations take care of build flags and i386, I'm subscribing their team.

Revision history for this message
Sam Hartman (hartmans) wrote : Re: [Bug 1980494] Re: krb5-multidev is not multi-arch installable due to differences in /usr/bin/krb5-config.mit

>>>>> "Andreas" == Andreas Hasenack <email address hidden> writes:
    Andreas> LTO are linker flags, so it's correct to have them exposed
    Andreas> in LDFLAGS.

I agree it is correct to have them exposed, but I'm not sure it is
necessary.
The LDFLAGS in krb5-config are LDFLAGS for the downstream user of the
library to use.
I don't think it is a strict requirement that we include more LDFLAGS
than users of krb5-config need.

On the Debian side I'd be open to a patch that minimized LDFLAGS. One
possibility would be to patch krb5-config.in to statically set LDFLAGS
rather than substituting from autoconf if we can find a value that would
be reasonable for all architectures.

Alternatively, Ubuntu can fix in an Ubuntu-specific manner.

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

> I agree it is correct to have them exposed, but I'm not sure it is necessary.
> The LDFLAGS in krb5-config are LDFLAGS for the downstream user of the library to use.

It depends. For example, there was a situation where a library was built using large file support (LFS) on i386, but another app linking with it did not have the LFS flags set, which created a bug[1].

Does LTO appply to this? I'm unsure.

1. https://www.debian.org/Bugs/#221618

Matthieu Clemenceau (mclemenceau)
tags: added: foundations-triage-discuss
Revision history for this message
Brian Murray (brian-murray) wrote :

@Andreas - you subscribed the Foundations team to his bug report back in July. What were you looking for from the Foundations team?

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

> @Andreas - you subscribed the Foundations team to his bug report back in July. What were you looking for from the Foundations team?

I don't know how this should be fixed, and was hoping Foundations could help, since it's an issue that is happening because of the introduction of LTO, and affects a multiarch package.

Matthieu Clemenceau (mclemenceau)
tags: removed: foundations-triage-discuss
Revision history for this message
Steve Langasek (vorlon) wrote :

I think the right fix here is to strip the output of dpkg-buildflags from the config script output. We've definitely had problems before where leaking dpkg-buildflags into other build tools made it effectively impossible for dependent packages to work around toolchain issues.

Changed in krb5 (Ubuntu):
importance: Undecided → Low
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in krb5 (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.