Created attachment 377834 [details, diff] Patch to the eclass Patch attached. The idea is that in EAPI 4+, multilib packages (with abi_x86_32) can be used to satisfy the multilib deps instead of emul-linux. It should be noted that I have no idea what those DEPENDs do, so I just assumed all the libraries in GCJ_GTK_DEPS are supposed to go multilib. It all looks like a big pile of black magic with no comments to me, especially that it doesn't land in RDEPEND and java libs don't link to it... and what is multilib about java anyway?
Actually some files are linked against libraries provided by packages in ${GCJ_GTK_DEPS}. Results on my system: $ scanelf -qF "%F: %n" /usr/lib@(32|64)/gcj-*/*.so /usr/lib32/gcj-4.7.3-13/libgjsmalsa.so: libasound.so.2,libc.so.6 /usr/lib32/gcj-4.7.3-13/libgtkpeer.so: libgtk-x11-2.0.so.0,libgdk-x11-2.0.so.0,libpangocairo-1.0.so.0,libatk-1.0.so.0,libcairo.so.2,libgio-2.0.so.0,libgthread-2.0.so.0,libgdk_pixbuf-2.0.so.0,libpangoft2-1.0.so.0,libpango-1.0.so.0,libgobject-2.0.so.0,libglib-2.0.so.0,libfontconfig.so.1,libfreetype.so.6,libSM.so.6,libICE.so.6,libXrender.so.1,libXrandr.so.2,libXtst.so.6,libpthread.so.0,libc.so.6 /usr/lib32/gcj-4.7.3-13/libjavamath.so: libgmp.so.10,libc.so.6 /usr/lib32/gcj-4.7.3-13/libjawt.so: libgtkpeer.so,libgtk-x11-2.0.so.0,libgdk-x11-2.0.so.0,libpangocairo-1.0.so.0,libatk-1.0.so.0,libcairo.so.2,libgio-2.0.so.0,libgthread-2.0.so.0,libgdk_pixbuf-2.0.so.0,libpangoft2-1.0.so.0,libpango-1.0.so.0,libgobject-2.0.so.0,libglib-2.0.so.0,libfontconfig.so.1,libfreetype.so.6,libSM.so.6,libICE.so.6,libXrender.so.1,libXrandr.so.2,libXtst.so.6,libpthread.so.0,libc.so.6 /usr/lib32/gcj-4.7.3-13/libjvm.so: libgcj.so.13,libpthread.so.0,librt.so.1,libdl.so.2,libz.so.1,libc.so.6,libgcc_s.so.1 /usr/lib32/gcj-4.8.2-14/libgjsmalsa.so: libasound.so.2,libc.so.6 /usr/lib32/gcj-4.8.2-14/libgtkpeer.so: libgtk-x11-2.0.so.0,libgdk-x11-2.0.so.0,libpangocairo-1.0.so.0,libatk-1.0.so.0,libcairo.so.2,libgio-2.0.so.0,libgthread-2.0.so.0,libgdk_pixbuf-2.0.so.0,libpangoft2-1.0.so.0,libpango-1.0.so.0,libgobject-2.0.so.0,libglib-2.0.so.0,libfontconfig.so.1,libfreetype.so.6,libSM.so.6,libICE.so.6,libXrender.so.1,libXrandr.so.2,libXtst.so.6,libpthread.so.0,libc.so.6 /usr/lib32/gcj-4.8.2-14/libjavamath.so: libgmp.so.10,libc.so.6 /usr/lib32/gcj-4.8.2-14/libjawt.so: libgtkpeer.so,libgtk-x11-2.0.so.0,libgdk-x11-2.0.so.0,libpangocairo-1.0.so.0,libatk-1.0.so.0,libcairo.so.2,libgio-2.0.so.0,libgthread-2.0.so.0,libgdk_pixbuf-2.0.so.0,libpangoft2-1.0.so.0,libpango-1.0.so.0,libgobject-2.0.so.0,libglib-2.0.so.0,libfontconfig.so.1,libfreetype.so.6,libSM.so.6,libICE.so.6,libXrender.so.1,libXrandr.so.2,libXtst.so.6,libpthread.so.0,libc.so.6 /usr/lib32/gcj-4.8.2-14/libjvm.so: libgcj.so.14,libpthread.so.0,librt.so.1,libdl.so.2,libz.so.1,libc.so.6,libgcc_s.so.1 /usr/lib64/gcj-4.7.3-13/libgjsmalsa.so: libasound.so.2,libc.so.6 /usr/lib64/gcj-4.7.3-13/libgtkpeer.so: libgtk-x11-2.0.so.0,libgdk-x11-2.0.so.0,libpangocairo-1.0.so.0,libatk-1.0.so.0,libcairo.so.2,libgio-2.0.so.0,libgthread-2.0.so.0,libgdk_pixbuf-2.0.so.0,libpangoft2-1.0.so.0,libpango-1.0.so.0,libgobject-2.0.so.0,libglib-2.0.so.0,libfontconfig.so.1,libfreetype.so.6,libSM.so.6,libICE.so.6,libXrender.so.1,libXrandr.so.2,libXtst.so.6,libpthread.so.0,libc.so.6 /usr/lib64/gcj-4.7.3-13/libjavamath.so: libgmp.so.10,libc.so.6 /usr/lib64/gcj-4.7.3-13/libjawt.so: libgtkpeer.so,libgtk-x11-2.0.so.0,libgdk-x11-2.0.so.0,libpangocairo-1.0.so.0,libatk-1.0.so.0,libcairo.so.2,libgio-2.0.so.0,libgthread-2.0.so.0,libgdk_pixbuf-2.0.so.0,libpangoft2-1.0.so.0,libpango-1.0.so.0,libgobject-2.0.so.0,libglib-2.0.so.0,libfontconfig.so.1,libfreetype.so.6,libSM.so.6,libICE.so.6,libXrender.so.1,libXrandr.so.2,libXtst.so.6,libpthread.so.0,libc.so.6 /usr/lib64/gcj-4.7.3-13/libjvm.so: libgcj.so.13,libpthread.so.0,librt.so.1,libdl.so.2,libz.so.1,libc.so.6,libgcc_s.so.1 /usr/lib64/gcj-4.8.2-14/libgjsmalsa.so: libasound.so.2,libc.so.6 /usr/lib64/gcj-4.8.2-14/libgtkpeer.so: libgtk-x11-2.0.so.0,libgdk-x11-2.0.so.0,libpangocairo-1.0.so.0,libatk-1.0.so.0,libcairo.so.2,libgio-2.0.so.0,libgthread-2.0.so.0,libgdk_pixbuf-2.0.so.0,libpangoft2-1.0.so.0,libpango-1.0.so.0,libgobject-2.0.so.0,libglib-2.0.so.0,libfontconfig.so.1,libfreetype.so.6,libSM.so.6,libICE.so.6,libXrender.so.1,libXrandr.so.2,libXtst.so.6,libpthread.so.0,libc.so.6 /usr/lib64/gcj-4.8.2-14/libjavamath.so: libgmp.so.10,libc.so.6 /usr/lib64/gcj-4.8.2-14/libjawt.so: libgtkpeer.so,libgtk-x11-2.0.so.0,libgdk-x11-2.0.so.0,libpangocairo-1.0.so.0,libatk-1.0.so.0,libcairo.so.2,libgio-2.0.so.0,libgthread-2.0.so.0,libgdk_pixbuf-2.0.so.0,libpangoft2-1.0.so.0,libpango-1.0.so.0,libgobject-2.0.so.0,libglib-2.0.so.0,libfontconfig.so.1,libfreetype.so.6,libSM.so.6,libICE.so.6,libXrender.so.1,libXrandr.so.2,libXtst.so.6,libpthread.so.0,libc.so.6 /usr/lib64/gcj-4.8.2-14/libjvm.so: libgcj.so.14,libpthread.so.0,librt.so.1,libdl.so.2,libz.so.1,libc.so.6,libgcc_s.so.1
GCC >=4.4 provides libjavamath.so, which needs libgmp.so.* from || ( dev-libs/gmp app-emulation/emul-linux-x86-baselibs ). libjvm.so needs libz.so.* from || ( sys-libs/zlib app-emulation/emul-linux-x86-baselibs ). Also /usr/lib/gcc/x86_64-pc-linux-gnu/*/32/*.so files should be considered: $ scanelf -qF "%F: %n" /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32/*.so /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32/libasan.so: libpthread.so.0,libdl.so.2,libstdc++.so.6,libm.so.6,libc.so.6,ld-linux.so.2,libgcc_s.so.1 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32/libatomic.so: libpthread.so.0,libc.so.6 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32/libcilkrts.so: libpthread.so.0,libdl.so.2,libstdc++.so.6,libm.so.6,libc.so.6,libgcc_s.so.1 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32/libgcc_s.so: libc.so.6 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32/libgcj_bc.so: libc.so.6,libgcc_s.so.1 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32/libgcj.so: libpthread.so.0,librt.so.1,libdl.so.2,libz.so.1,libc.so.6,ld-linux.so.2,libgcc_s.so.1 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32/libgcj-tools.so: libm.so.6,libgcj.so.15,libpthread.so.0,librt.so.1,libdl.so.2,libz.so.1,libc.so.6,libgcc_s.so.1 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32/libgfortran.so: libquadmath.so.0,libm.so.6,libgcc_s.so.1,libc.so.6 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32/libgij.so: libgcj.so.15,libpthread.so.0,librt.so.1,libdl.so.2,libz.so.1,libc.so.6,libgcc_s.so.1 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32/libgomp.so: libpthread.so.0,libc.so.6 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32/libitm.so: libpthread.so.0,libc.so.6 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32/libquadmath.so: libm.so.6,libc.so.6 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32/libstdc++.so: libm.so.6,libc.so.6,ld-linux.so.2,libgcc_s.so.1 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32/libubsan.so: libpthread.so.0,libdl.so.2,libstdc++.so.6,libm.so.6,libc.so.6,libgcc_s.so.1 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32/libvtv.so: libc.so.6,libgcc_s.so.1 It seems that only libz.so.* from || ( sys-libs/zlib app-emulation/emul-linux-x86-baselibs ) is the only library from outside of GCC / glibc.
Created attachment 379336 [details, diff] toolchain.eclass.patch Patch for bug #511832, bug #513576, bug #513578 and bug #513716.
Comment on attachment 379336 [details, diff] toolchain.eclass.patch Yeesh, that's ugly. But thanks for doing the research. First off I really don't want to add any more USE flags. If jack/dssi/alsa were required for awt then they should probably be made unconditional dependencies, but considering that not one person has ever requested or filed a bug about it I think it'd be simpler to just disable them. >+ if tc_version_is_at_least 4.4 ; then >+ GCC_GCJ_GMP_DEPS=" >+ amd64? ( multilib? ( || ( >+ dev-libs/gmp[abi_x86_32] >+ app-emulation/emul-linux-x86-baselibs[-abi_x86_32] >+ ) ) )" >+ DEPEND+=" ${GCC_GCJ_GMP_DEPS}" >+ RDEPEND+=" ${GCC_GCJ_GMP_DEPS}" >+ fi We already have if tc_version_is_at_least 4 ; then GMP_MPFR_DEPS=">=dev-libs/gmp-4.3.2 >=dev-libs/mpfr-2.4.2" if tc_version_is_at_least 4.3 ; then RDEPEND+=" ${GMP_MPFR_DEPS}" elif in_iuse fortran ; then RDEPEND+=" fortran? ( ${GMP_MPFR_DEPS} )" fi fi Can you merge these? >+if in_iuse awt ; then >+ DEPEND+=" awt? (" >+ RDEPEND+=" awt? (" >+ GCC_GCJ_GTK_DEPS="x11-libs/gtk+:2 >+ amd64? ( multilib? ( || ( >+ x11-libs/gtk+:2[abi_x86_32] >+ app-emulation/emul-linux-x86-gtklibs[-abi_x86_32] >+ ) ) )" >+ DEPEND+=" ${GCC_GCJ_GTK_DEPS} >+ virtual/pkgconfig >+ x11-libs/libX11 >+ x11-proto/xproto >+ amd64? ( multilib? ( || ( >+ ( >+ x11-libs/libX11[abi_x86_32] >+ x11-proto/xproto[abi_x86_32] >+ ) >+ app-emulation/emul-linux-x86-xlibs[-abi_x86_32] >+ ) ) )" [etc] >+ if tc_version_is_at_least 4.2 ; then >+ GCC_GCJ_XRANDR_XRENDER_DEPS="x11-libs/libXrandr >+ x11-libs/libXrender >+ amd64? ( multilib? ( || ( >+ ( >+ x11-libs/libXrandr[abi_x86_32] >+ x11-libs/libXrender[abi_x86_32] >+ ) >+ app-emulation/emul-linux-x86-xlibs[-abi_x86_32] >+ ) ) )" >+ DEPEND+=" ${GCC_GCJ_XRANDR_XRENDER_DEPS}" >+ RDEPEND+=" ${GCC_GCJ_XRANDR_XRENDER_DEPS}" >+ fi >+ DEPEND+=" )" >+ RDEPEND+=" )" >+ fi There's really no reason to do all this version checking. All these X libs and headers are going to get pulled in regardless. gtk+ alone covers almost everything here, and I think cairo and pango pick up the rest.
(In reply to Ryan Hill from comment #4) > First off I really don't want to add any more USE flags. If jack/dssi/alsa > were required for awt libgjsmalsa.so and libgjsmdssi.so are independent from AWT's libgtkpeer.so and libjawt.so. > then they should probably be made unconditional > dependencies, but considering that not one person has ever requested or > filed a bug about it I think it'd be simpler to just disable them. These features were automatically enabled, so users did not have to file bugs requesting enabling of them. One USE flag per feature (requiring additional dependencies) is a good idea. > There's really no reason to do all this version checking. All these X libs > and headers are going to get pulled in regardless. gtk+ alone covers almost > everything here, and I think cairo and pango pick up the rest. I only listed directly, explicitly used dependencies found by me. 2 x11-proto/* packages and 3 x11-libs/libX* packages were already in dependencies specified in toolchain.eclass.
If sys-devel/gcc had proper USE flags (e.g. abi_x86_32, abi_x86_64), then dependencies could be simpler and accurater...
*** Bug 518972 has been marked as a duplicate of this bug. ***
Created attachment 386934 [details, diff] toolchain.eclass.patch Patch for bug #511832, bug #513576, bug #513578 and bug #513716.
Bug ping -- gx86-multilib would like to get these bugs addressed. Accompanying attachment 386934 [details, diff] would be changes in profiles related to the new use-flags, as per https://people.apache.org/~Arfrever/profiles_gcc.patch Final comments, please -- if anyone has any alternative suggestions we would like to hear them so that we could provide an updated solution. Otherwise, if there are no objections, I will commit attachment 386934 [details, diff] in 7 days.
Comment on attachment 377834 [details, diff] Patch to the eclass if we're going to fix this, we probably should cover all the targets and not just continue special casing amd64. i.e. why isn't this using $MULTILIB_USEDEP ?
Comment on attachment 386934 [details, diff] toolchain.eclass.patch multiple problems here: - shouldn't be special casing amd64/32bit ABI - we're not going to hack libart that way - building up the depend string in pieces like that makes it god awful to read - "gcj-alsa" should be "alsa" - "gcj-dssi" should be "dssi"
(In reply to SpanKY from comment #10) > if we're going to fix this, we probably should cover all the targets and not > just continue special casing amd64. i.e. why isn't this using > $MULTILIB_USEDEP ? (In reply to SpanKY from comment #11) > - shouldn't be special casing amd64/32bit ABI MULTILIB_USEDEP has value "[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]". These "?" mean that it is required to have given flag in IUSE of current package. sys-devel/gcc currently has not these flags in IUSE and instead uses "multilib" flag. Do you plan to introduce "abi_x86_32", "abi_x86_64", "abi_x86_x32" etc. USE flags in sys-devel/gcc? (In reply to SpanKY from comment #11) > - we're not going to hack libart that way What solution do you suggest? > - building up the depend string in pieces like that makes it god awful to > read What coding style do you suggest? Please give an example and I can rewrite patch. Before my patch, toolchain.eclass already has e.g. GCJ_GTK_DEPS="..." and DEPEND+=" gcj? ( awt? ( ${GCJ_GTK_DEPS} )...", so I was just adhering to already used style. > - "gcj-alsa" should be "alsa" > - "gcj-dssi" should be "dssi" I can make these changes in next version of patch. However using "gcj-"-prefixed flags has the advantage of not forcing these users, who globally have "alsa" USE flag enabled and "gcj" USE flag not enabled, to add "sys-devel/gcc -alsa" to /etc/portage/package.use (or to enable "gcj"). This includes all users of "desktop" profiles, since "alsa" USE flag is enabled in gentoo-x86/profiles/targets/desktop/make.defaults, but "gcj" is not enabled in any profile.
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #12) > [...] > (In reply to SpanKY from comment #11) > > [...] > > - "gcj-alsa" should be "alsa" > > - "gcj-dssi" should be "dssi" > > I can make these changes in next version of patch. > However using "gcj-"-prefixed flags has the advantage of not forcing these > users, who globally have "alsa" USE flag enabled and "gcj" USE flag not > enabled, to add "sys-devel/gcc -alsa" to /etc/portage/package.use (or to > enable "gcj"). > This includes all users of "desktop" profiles, since "alsa" USE flag is > enabled in gentoo-x86/profiles/targets/desktop/make.defaults, but "gcj" is > not enabled in any profile. If I can throw in my two cents, I agree with Arfrever on this. I don't think sys-devel/gcc should "by default" depend on ALSA in any case. Although the USE flag naming can be addressed to pull in dependencies and set configure flags only when *both* flags of 'alsa'/'gcj' and 'dssi'/'gcj' pairs are set.
(In reply to JohnLM from comment #13) REQUIRED_USE is recommended solution in situations when one USE flag requires another USE flag.
(In reply to SpanKY from comment #11) > - shouldn't be special casing amd64/32bit ABI The issue here is that amd64/32bit ABI *is* a special case, though, until the emul-* packages are gone. That's the only case where a binary-built emul-* package will satisfy the RDEPEND, and said dep is already automagic on most amd64-multilib systems. We certainly can make sure that the deps are there for all other multilib arches, of course, but doing so is going to require knowledge of that arch (ie -- does this alsa dep have meaning on mips or ppc multilib?) I would personally prefer to fix amd64 now and improve for the other platforms later, rather than continue to hold up amd64 until the other platforms can be sorted out. The other platforms won't be any worse off than they are now, with this patch, right? Also, I like 'gcj-alsa' , it tells me immediately that the alsa flag is for gcj support and not for something else randon within gcc. gcj is the only thing that needs alsa, right? go, fortran, none of the others do?
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #12) > - shouldn't be special casing amd64/32bit ABI yes, if the tree has standardized on the abi_xxx flags, then gcc should also > - we're not going to hack libart that way if you want to avoid libart, then write a patch for gcc itself that we'd send upstream and include in the gcc patchset > - building up the depend string in pieces like that makes it god awful to read you were not adhering to the style. nowhere does the eclass build DEPEND strings like you were -- all () are matched. trying to track open ( and closed ) across multiple assignments is a nightmare. the eclass does build small logical chunks together in dedicated vars, and then expands them into DEPEND in one go. > - "gcj-alsa" should be "alsa" > - "gcj-dssi" should be "dssi" if the alsa/dssi logic is under gcj?(...) (and i see no reason it wouldn't be considering these features are only used when gcj is being compiled), then i don't see why it'd have any bearing on existing users.
(In reply to SpanKY from comment #16) > yes, if the tree has standardized on the abi_xxx flags, then gcc should also Are you working on implementing abi_* flags for GCC? > if you want to avoid libart, then write a patch for gcc itself that we'd > send upstream and include in the gcc patchset I attached patch in bug #513716. > > - "gcj-alsa" should be "alsa" > > - "gcj-dssi" should be "dssi" > > if the alsa/dssi logic is under gcj?(...) (and i see no reason it wouldn't > be considering these features are only used when gcj is being compiled), > then i don't see why it'd have any bearing on existing users. Do you suggest to not use REQUIRED_USE?
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #17) > (In reply to SpanKY from comment #16) > > > - "gcj-alsa" should be "alsa" > > > - "gcj-dssi" should be "dssi" > > > > if the alsa/dssi logic is under gcj?(...) (and i see no reason it wouldn't > > be considering these features are only used when gcj is being compiled), > > then i don't see why it'd have any bearing on existing users. > > Do you suggest to not use REQUIRED_USE? REQUIRED_USE wouldn't really work here, at all, especially if the flags are just 'alsa' and 'dssi'. Since the only REQUIRED_USE that makes sense to me would be to force-on gcj (or is it that at least one of alsa and dssi need to be enabled?), we'd just end up with USE=gcj being forced-on for everyone that has USE=alsa enabled in profiles. As it is, with the flag name being 'alsa', this is still going to mean that if that flag changes (and i assume people do set USE="-alsa pulseaudio" when switching to PA??) then gcc is going to be triggered for rebuild, which will be entirely useless if USE="-gcj".
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #17) i haven't started work on abi_xxx yet
@vapier: I agree with most of your points. However, we need to special-case amd64 for some more time so that we can help stable users switch from emul-linux-x86 to abi_x86_32 flag. I believe we should take small steps here -- first, fix the existing dependency strings so that we're able to drop emul-linux-x86. Once we get rid of that, we can improve gcc further.
Created attachment 389818 [details, diff] toolchain.eclass.patch Updates: - "gcj-alsa" -> "alsa" - "gcj-dssi" -> "dssi" - Dedicated GCJ_*_DEPEND and GCJ_*_RDEPEND variables whose contents are appended to DEPEND and RDEPEND only once - Libart workaround deleted (Bug #513716 must be fixed first)
(In reply to Ian Stakenvicius from comment #18) [...] > As it is, with the flag name being 'alsa', this is still going to mean that > if that flag changes (and i assume people do set USE="-alsa pulseaudio" when > switching to PA??) You shouldn't do that with moving to PA, "alsa pulseaudio" is fine ;) >then gcc is going to be triggered for rebuild, which will > be entirely useless if USE="-gcj". But I agree this could trigger useless rebuilds as I think we don't have any way to indicate PMs that some USE flag should only be taken into account when a "parent" one is enabled (no idea if there has been any suggestion to PMS ever about this :/)
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #21) > Created attachment 389818 [details, diff] [details, diff] > toolchain.eclass.patch Apart of the wondering about the "gcj-" USE flags (that in this last patch are handled as you preferred :)), any downsides blocking this? (and bug 513716 that should be applied before)
CC-ing qa@ since this is yet another case where we have a lot of bugs and a patch, and maintainer doesn't really care about applying them.
Another option is to force-disable all those extra deps. We have only one real reverse dependency for this, and it rather doesn't need ALSA or other fancy stuff. Or leave them as automagic, I don't care that much really.
(In reply to Michał Górny from comment #25) > Another option is to force-disable all those extra deps. We have only one > real reverse dependency for this, and it rather doesn't need ALSA or other > fancy stuff. Or leave them as automagic, I don't care that much really. I prefer force disabling. The automagic is different here because gcc and g++ will still work and that's sufficient to not cripple a system, but if gcj[awt] is there, then the correct dependencies should be there too.
Of course one more thing is that we have completely zero use for 32-bit gcj runtime. But I don't think it'd be easy to disable multilib only for one of the languages.
Created attachment 391244 [details, diff] toolchain.eclass.patch Updates: - Pseudosupport for EAPI="0" and EAPI="1".
(In reply to Michał Górny from comment #27) > Of course one more thing is that we have completely zero use for 32-bit gcj > runtime. But I don't think it'd be easy to disable multilib only for one of > the languages. Do you mean because we have other runtimes JVMs or because its broken. afaik gcj works on 32-bits. My understanding is that we're saving gcj just not gcj + the windowing toolkit.
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #28) > Created attachment 391244 [details, diff] [details, diff] > toolchain.eclass.patch > > Updates: > - Pseudosupport for EAPI="0" and EAPI="1". Arfrever, I get your patch, but let's just mask gcj[awt] and be done with it. I don't know of any package that needs gcj in particular over other JDKs/JVMs. Why are we saving it?
(In reply to Anthony Basile from comment #30) > Arfrever, I get your patch, but let's just mask gcj[awt] and be done with > it. I don't know of any package that needs gcj in particular over other > JDKs/JVMs. Why are we saving it? Please do not! I had a hard time with that gcj[awt]! I cannot recollect exactly the conditions because I spent a few days solving this in the past, and more importantly, to get rid f emul-* cruft. What is sure is that I had/have gtk, jack and alsa set globaly and then I needed gcj to build icedtead to have java/script enabled mainly for libreoffice. What a mess! especially with getting rid of emul-linux-x86-* cruft in mind. That combination pulled in alsa/gtk emul-linux-x86 cruft to satisfy gcj[awt] required mainly by alsa/gtk USE flags set globally. I don't remember anymore how I managed this but first, I removed emul-* cruft; And then enabled abi_x86_32 where needed; And then rebuild everything but gcc istself which I had to build with ebuild helper because despite the real dependecies/libraries being there, toolchain eclass was pulling in emul-* cruft. So, in short, do not mask gcj[awt] which mean headaches for a few users.
(In reply to Anthony Basile from comment #29) > (In reply to Michał Górny from comment #27) > > Of course one more thing is that we have completely zero use for 32-bit gcj > > runtime. But I don't think it'd be easy to disable multilib only for one of > > the languages. > > Do you mean because we have other runtimes JVMs or because its broken. > afaik gcj works on 32-bits. My understanding is that we're saving gcj just > not gcj + the windowing toolkit. I mean because we have no use for 32-bit gcj runtime on amd64 :). We only support native gcj-jdk, and we only build native pdftk. IOW, there's no package doing 'gcj -m32'.
(In reply to tokiclover from comment #31) > I had a hard time with that gcj[awt]! > So, in short, do not mask gcj[awt] which mean headaches for a few users. These two statements contradict one another. I'm not sure you understand what we are up to here. It is precisely to remove the emul-* that we are working on this.
(In reply to Anthony Basile from comment #33) > These two statements contradict one another. I'm not sure you understand > what we are up to here. It is precisely to remove the emul-* that we are > working on this. So, because _you_ understand what at stake you advice to mask gcj[awt] and be done with it? Come on, let's leave the discussion to those who understand then.
(In reply to Michał Górny from comment #27) > Of course one more thing is that we have completely zero use for 32-bit gcj > runtime. But I don't think it'd be easy to disable multilib only for one of > the languages. We had gcj multilib disabled for as long as I can remember. We only started building it about a year ago for reasons I don't understand.
I think Bug #540392 is related.
Created attachment 404446 [details, diff] toolchain.eclass.patch Updates: - Support for EAPI="0" and EAPI="1" dropped. - Support for app-emulation/emul-linux-x86-* dropped since these packages were deleted yesterday.
Created attachment 404448 [details, diff] toolchain.eclass.patch Updates: - [abi_x86_32] added to dependencies on virtual/pkgconfig.
Any progress here? sys-devel/gcc[awt,gcj] still depends on the following packages which are no longer in the tree: app-emulation/emul-linux-x86-gtklibs app-emulation/emul-linux-x86-xlibs
I think the simplest solution here would be to disable multilib on gcj (if that's possible). That would save us the trouble of getting the big patch accepted, and save gcj for those who need it.
Let's close it as non-masked versions of gcc don't have gcj and related libraries.
