Created attachment 361608 [details, diff] gtk+-2.24.22.ebuild.patch I'm currently running gtk+:2 built using this patch (with USE=-cups, see below) and the 32-bit GTK+ programs I have seem to work fine. This needs net-print/cups to be multilibbed for USE=cups. gtk+:3 has more base dependencies which still need to be multilibbed, so I don't have a patch for it yet.
The only things, which depends on cups is printbackends/libprintbackend-cups.so ($ equery f gtk+:2 | grep "so$" | xargs scanelf -n | grep cups) Is that actually needed by wine to print?
Huh? Wine doesn't depend on GTK+ to begin with. I guess acroread might need GTK+ printing stuff, though grepping the distribution for gtk_print gives nothing, so maybe not? I'd be happy with disabling cups for non-native builds, but how would you go about it? You can't have different USE flags for different ABIs; maybe just force-disable it in econf and ewarn "cups was disabled for non-native ABIs"?
(In reply to Andrew Church from comment #2) > Huh? Wine doesn't depend on GTK+ to begin with. I guess acroread might > need GTK+ printing stuff, though grepping the distribution for gtk_print > gives nothing, so maybe not? > > I'd be happy with disabling cups for non-native builds, but how would you go > about it? You can't have different USE flags for different ABIs; maybe just > force-disable it in econf and ewarn "cups was disabled for non-native ABIs"? I guess, the same as for introspection, $(multilib_is_native_abi && use_enable cups cups auto || echo --disable-cups).
Created attachment 369842 [details, diff] gtk+-2.24.22.ebuild.patch Patch updated with --disable-cups for non-native as you suggested. I've also changed multilib_is_native_abi to multilib_build_binaries per multilib team's guidance. PTAL.
This looks like a bad idea to me. Diverging options just because it's faster without CUPS is not really a good idea, especially that the resulting issues will be hidden until user actually tries to print and fails.
That was my original concern as well, but the point was that there's a limited, well-defined set of programs depending on the non-native library and (as far as I can tell, anyway) none of them rely on GTK+ to print, so the lack of cups support will make no practical difference.
(In reply to Andrew Church from comment #6) > That was my original concern as well, but the point was that there's a > limited, well-defined set of programs depending on the non-native library > and (as far as I can tell, anyway) none of them rely on GTK+ to print, so > the lack of cups support will make no practical difference. What about app-text/acroread? Does it use gtk's printing support or its own infrastructure?
(In reply to Alexandre Rostovtsev from comment #7) > (In reply to Andrew Church from comment #6) > > That was my original concern as well, but the point was that there's a > > limited, well-defined set of programs depending on the non-native library > > and (as far as I can tell, anyway) none of them rely on GTK+ to print, so > > the lack of cups support will make no practical difference. > > What about app-text/acroread? Does it use gtk's printing support or its own > infrastructure? (In reply to Andrew Church from comment #2) > Huh? Wine doesn't depend on GTK+ to begin with. I guess acroread might > need GTK+ printing stuff, though grepping the distribution for gtk_print > gives nothing, so maybe not?
I have a working ebuild in my overlay below for this; along with it's dependencies: https://github.com/sjnewbury/gentoo-gx86-staging
Committed p.masked.
