Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 511832 - toolchain.eclass: gcj multilib and dependency issues
Summary: toolchain.eclass: gcj multilib and dependency issues
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard: masked in 17.0 profiles
Keywords: QAbaddep
: 518972 (view as bug list)
Depends on: PR61552
Blocks: 444762 513576
  Show dependency tree
 
Reported: 2014-05-30 07:28 UTC by Michał Górny
Modified: 2019-12-29 11:04 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Patch to the eclass (toolchain.diff,1.37 KB, patch)
2014-05-30 07:28 UTC, Michał Górny
Details | Diff
toolchain.eclass.patch (toolchain.eclass.patch,6.14 KB, patch)
2014-06-20 19:55 UTC, Arfrever Frehtes Taifersar Arahesis
Details | Diff
toolchain.eclass.patch (toolchain.eclass.patch,6.14 KB, patch)
2014-10-19 09:29 UTC, Arfrever Frehtes Taifersar Arahesis
Details | Diff
toolchain.eclass.patch (toolchain.eclass.patch,6.28 KB, patch)
2014-11-19 21:47 UTC, Arfrever Frehtes Taifersar Arahesis
Details | Diff
toolchain.eclass.patch (toolchain.eclass.patch,7.95 KB, patch)
2014-12-08 22:04 UTC, Arfrever Frehtes Taifersar Arahesis
Details | Diff
toolchain.eclass.patch (toolchain.eclass.patch,5.35 KB, patch)
2015-06-02 07:49 UTC, Arfrever Frehtes Taifersar Arahesis
Details | Diff
toolchain.eclass.patch (toolchain.eclass.patch,5.42 KB, patch)
2015-06-02 08:05 UTC, Arfrever Frehtes Taifersar Arahesis
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-05-30 07:28:38 UTC
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?
Comment 1 Arfrever Frehtes Taifersar Arahesis 2014-06-12 18:13:30 UTC
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
Comment 2 Arfrever Frehtes Taifersar Arahesis 2014-06-18 21:48:12 UTC
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.
Comment 3 Arfrever Frehtes Taifersar Arahesis 2014-06-20 19:55:25 UTC
Created attachment 379336 [details, diff]
toolchain.eclass.patch

Patch for bug #511832, bug #513576, bug #513578 and bug #513716.
Comment 4 Ryan Hill (RETIRED) gentoo-dev 2014-06-21 06:57:47 UTC
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.
Comment 5 Arfrever Frehtes Taifersar Arahesis 2014-06-21 07:34:30 UTC
(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.
Comment 6 Arfrever Frehtes Taifersar Arahesis 2014-06-21 07:38:34 UTC
If sys-devel/gcc had proper USE flags (e.g. abi_x86_32, abi_x86_64), then dependencies could be simpler and accurater...
Comment 7 Mike Gilbert gentoo-dev 2014-08-03 22:52:13 UTC
*** Bug 518972 has been marked as a duplicate of this bug. ***
Comment 8 Arfrever Frehtes Taifersar Arahesis 2014-10-19 09:29:04 UTC
Created attachment 386934 [details, diff]
toolchain.eclass.patch

Patch for bug #511832, bug #513576, bug #513578 and bug #513716.
Comment 9 Ian Stakenvicius (RETIRED) gentoo-dev 2014-11-12 21:38:03 UTC
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 10 SpanKY gentoo-dev 2014-11-13 05:48:13 UTC
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 11 SpanKY gentoo-dev 2014-11-13 05:52:15 UTC
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"
Comment 12 Arfrever Frehtes Taifersar Arahesis 2014-11-13 10:02:29 UTC
(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.
Comment 13 JohnLM 2014-11-13 11:30:26 UTC
(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.
Comment 14 Arfrever Frehtes Taifersar Arahesis 2014-11-13 12:06:50 UTC
(In reply to JohnLM from comment #13)

REQUIRED_USE is recommended solution in situations when one USE flag requires another USE flag.
Comment 15 Ian Stakenvicius (RETIRED) gentoo-dev 2014-11-13 14:51:39 UTC
(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?
Comment 16 SpanKY gentoo-dev 2014-11-14 02:56:25 UTC
(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.
Comment 17 Arfrever Frehtes Taifersar Arahesis 2014-11-14 07:05:04 UTC
(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?
Comment 18 Ian Stakenvicius (RETIRED) gentoo-dev 2014-11-14 14:51:51 UTC
(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".
Comment 19 SpanKY gentoo-dev 2014-11-14 17:51:22 UTC
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #17)

i haven't started work on abi_xxx yet
Comment 20 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-11-16 10:33:26 UTC
@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.
Comment 21 Arfrever Frehtes Taifersar Arahesis 2014-11-19 21:47:23 UTC
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)
Comment 22 Pacho Ramos gentoo-dev 2014-12-01 09:49:24 UTC
(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 :/)
Comment 23 Pacho Ramos gentoo-dev 2014-12-01 09:55:14 UTC
(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)
Comment 24 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-12-01 12:44:53 UTC
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.
Comment 25 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-12-07 14:23:56 UTC
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.
Comment 26 Anthony Basile gentoo-dev 2014-12-08 13:21:17 UTC
(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.
Comment 27 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-12-08 19:33:37 UTC
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.
Comment 28 Arfrever Frehtes Taifersar Arahesis 2014-12-08 22:04:46 UTC
Created attachment 391244 [details, diff]
toolchain.eclass.patch

Updates:
- Pseudosupport for EAPI="0" and EAPI="1".
Comment 29 Anthony Basile gentoo-dev 2014-12-09 13:52:55 UTC
(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.
Comment 30 Anthony Basile gentoo-dev 2014-12-09 13:55:55 UTC
(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?
Comment 31 tokiclover 2014-12-09 14:30:29 UTC
(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.
Comment 32 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-12-09 14:34:11 UTC
(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'.
Comment 33 Anthony Basile gentoo-dev 2014-12-10 12:06:54 UTC
(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.
Comment 34 tokiclover 2014-12-10 13:13:05 UTC
(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.
Comment 35 Ryan Hill (RETIRED) gentoo-dev 2014-12-15 04:23:46 UTC
(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.
Comment 36 Christoph Junghans gentoo-dev 2015-05-26 15:20:58 UTC
I think Bug #540392 is related.
Comment 37 Arfrever Frehtes Taifersar Arahesis 2015-06-02 07:49:29 UTC
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.
Comment 38 Arfrever Frehtes Taifersar Arahesis 2015-06-02 08:05:57 UTC
Created attachment 404448 [details, diff]
toolchain.eclass.patch

Updates:
- [abi_x86_32] added to dependencies on virtual/pkgconfig.
Comment 39 Ulrich Müller gentoo-dev 2015-06-19 11:21:05 UTC
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
Comment 40 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-06-19 14:15:49 UTC
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.
Comment 41 Sergei Trofimovich gentoo-dev 2019-12-29 11:04:34 UTC
Let's close it as non-masked versions of gcc don't have gcj and related
libraries.