On Mon, Feb 19, 2024 at 11:26 PM Eli Schwartz <eschwartz93@gmail.com> wrote:

meson's builtin LTO support allows meson to introspect whether LTO is
enabled and do some fancy things, such as forcing LTO off for a single
target that is known to be special(ly bad) and not support LTO.

Please make sure to test this change with a multilib-enabled ebuild
with multiple ABIs enabled. I suspect the filter-lto call will cause
differing results for the ABIs after the first.

If that is the case, we may need to declare the relevant FLAGS
variables with "local -x".

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Eli Schwartz <eschwartz93@gmail.com> writes:

[[PGP Signed Part:Undecided]]
On 2/20/24 1:24 AM, Mike Gilbert wrote:

I'm afraid I get different results. Build log attached. Happy to help
figure this out tomorrow.

To test, I applied this patch and ran this:

ABI_X86="32 x32 64" CFLAGS="-O2 -pipe -march=amdfam10 -flto=2" ebuild
zstd-1.5.5-r1.ebuild clean configure

Yikes. I wonder if this is also a problem for ffmpeg:

multilib_src_configure() {

[...]

# LTO support, bug #566282, bug #754654, bug #772854
if [[ ${ABI} != x86 ]] && tc-is-lto; then
# Respect -flto value, e.g -flto=thin
local v="$(get-flag flto)"
[[ -n ${v} ]] && myconf+=( "--enable-lto=${v}" ) || myconf+=( "--enable-lto" )
fi
filter-lto

It is indeed.. https://bugs.gentoo.org/923491.

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZdRJZl8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZBxAQEA6QYNiPmoI6dZPF71fVHdYTOoDdcqL69zn3yw b4V6mxUBANZ82hoyKXsman2TlNNRPZL0DAaTz7u3QakKt1ctZEkP
=nX4+
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)