Both flags are behind multilib_native_use_enable so they are only enabled for amd64. If one enables abi_x86_32 those flags are disabled. Please enable those flags for all targets.
This is intentional like this (only enabled for native) for all vala and introspection files, and this would need some very serious justification to change.
(In reply to Thomas Sachau from comment #0) > Both flags are behind multilib_native_use_enable so they are only enabled > for amd64. If one enables abi_x86_32 those flags are disabled. Please enable > those flags for all targets. A number of people have expressed a lot of frustration that you file bugs that are only problems when using your multilib portage fork but without mentioning that. I don't know if that's the case here, but I suspect it is. It's really not acceptable to neglect to mention that, and it happens so consistently that I feel the need to comment.
So first: @leio: Could you explain, why vala and introspection are intentionally disabled for none-default ABIs for all vala and introspection files? @matst88: If people have an issue with me, they should come to me and tell me about it. Expressing something in the back to other people will never change anything. In addition, just because i find an issue with multilib-portage it does not mean that the issue is related to it or caused by it (for example multilib-portage is an easy test, if a package fully respects *FLAGS, an issue respecting *FLAGS is no multilib-portage issue, but an issue in the package itself). @dilfridge: I did never state, that this is a multilib-portage only issue or did anyone else clearly say it. Please stop claiming things that are not true.
(In reply to Thomas Sachau from comment #3) > So first: > > @leio: Could you explain, why vala and introspection are intentionally > disabled for none-default ABIs for all vala and introspection files? Typically we do this because it's unnecessary to build ABI-independent things multiple times (e.g. for each ABI). > @matst88: If people have an issue with me, they should come to me and tell > me about it. Expressing something in the back to other people will never > change anything. In addition, just because i find an issue with > multilib-portage it does not mean that the issue is related to it or caused > by it (for example multilib-portage is an easy test, if a package fully > respects *FLAGS, an issue respecting *FLAGS is no multilib-portage issue, > but an issue in the package itself). You haven't been on IRC in more than a month as far as I can tell. I told you this to avoid further confusion. I don't know why you have reacted as if you're under attack. > @dilfridge: I did never state, that this is a multilib-portage only issue or > did anyone else clearly say it. Please stop claiming things that are not > true. So... just state it clearly?
(In reply to Matt Turner from comment #4) > (In reply to Thomas Sachau from comment #3) > > So first: > > > > @leio: Could you explain, why vala and introspection are intentionally > > disabled for none-default ABIs for all vala and introspection files? > > Typically we do this because it's unnecessary to build ABI-independent > things multiple times (e.g. for each ABI). There are some variable issues with those enabled (vala eclass sets PKG_CONFIG_PATH in src_prepare and multilib eclass overwrites it at the beginning of src_configure for none-default ABI), but since i dont see any ABI-specific content in the files, this works for me. > > > @matst88: If people have an issue with me, they should come to me and tell > > me about it. Expressing something in the back to other people will never > > change anything. In addition, just because i find an issue with > > multilib-portage it does not mean that the issue is related to it or caused > > by it (for example multilib-portage is an easy test, if a package fully > > respects *FLAGS, an issue respecting *FLAGS is no multilib-portage issue, > > but an issue in the package itself). > > You haven't been on IRC in more than a month as far as I can tell. I told > you this to avoid further confusion. I don't know why you have reacted as if > you're under attack. I have random crashes for several weeks now, so i am currently only running a minimal set of applications. Will see in the next week or two, if i found the cause. > > > @dilfridge: I did never state, that this is a multilib-portage only issue or > > did anyone else clearly say it. Please stop claiming things that are not > > true. > > So... just state it clearly? In fact, all bugs are not an issue in multilib-portage (as i could just fix them myself), i just find them while using multilib-portage. And some are just not seen with default portage (e.g. if *FLAGS are not respected, packages just compile fine with normal portage while they will fail or result in the wrong libraries/binaries with multilib-portage). So multilib-portage is not the reason for the issue, just a tool to find the issue. Anyway, this bug was obviously and totally independent from any package manager since it was a question about ebuild internals. So there was no point in adding a "multilib-portage" label to it.
Introspection files ARE arch-dependent, despite one part of them (the GIR files) being in arch-independent location. See for example https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/323 So we have two main reasons of never installing these for non-native ABI: 1. It simply wouldn't work right when the gir gets used (maybe it works in general case from the typelibs in $libdir/girepository-1.0), as it would be specific to the native ABI (because non-multilib-portage multilib eclasses ensure that native gets src_install ran last, so that clashing files would end up from native build) 2. We don't add multilib support just for the sake of it, for anything, and nothing has needed it, because I haven't seen a proprietary app that is both in non-native ABI and uses gir-based bindings Anyhow, I still don't see a reason for the original request, so tackling any of these technical issues is not something we're going to do without a reason to do so.
