Re: [gentoo-dev] x11-base/xorg-server: No longer enabling suid by default.
Hi, On 26/05/2020 00.34, Philip Webb wrote: > I'ld rather you didn't. You didn't provided any rationale for that. Running X as root is anti pattern, especially nowadays when so little effort is required to not have to run it as root. You can either enable elogind, or you can enable suid if you want to preserve your status quo, we're talking here about defaults that user can change if he has a reason to do so. -- Piotr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Mon, May 25, 2020 at 7:35 PM Alexis Ballier wrote: > > On Mon, 2020-05-25 at 17:04 -0400, Mike Gilbert wrote: > > On Mon, May 25, 2020 at 3:18 PM Michał Górny > > wrote: > > > On Mon, 2020-05-25 at 19:49 +0200, Alexis Ballier wrote: > > > > On Mon, 25 May 2020 11:26:26 -0400 > > > > Mike Gilbert wrote: > > > > > > > > > On Mon, May 25, 2020 at 9:13 AM Alexis Ballier < > > > > > aball...@gentoo.org> > > > > > wrote: > > > > > > On Sun, 24 May 2020 20:25:11 + (UTC) > > > > > > "Thomas Deutschmann" wrote: > > > > > > > > > > > > > commit: 6e149596cc76f1bbcee6720828c8c8c92420f2a3 > > > > > > > Author: Thomas Deutschmann gentoo > > > > > > > org> > > > > > > > AuthorDate: Sun May 24 19:47:08 2020 + > > > > > > > Commit: Thomas Deutschmann gentoo > > > > > > > org> > > > > > > > CommitDate: Sun May 24 20:23:53 2020 + > > > > > > > URL: > > > > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e149596 > > > > > > > > > > > > > > media-libs/x265: drop USE=pic > > > > > > > > > > > > > > Gentoo's toolchain uses PIC by default. Since USE=asm was > > > > > > > added, > > > > > > > we no longer need a USE flag to control that behavior. > > > > > > > > > > > > You got it wrong here it seems: USE=pic does not control > > > > > > whether > > > > > > the toolchain produces PIC or not. Shared libs always are, > > > > > > and have > > > > > > always been, built that way on Gentoo. > > > > > > In this case, USE=pic means "no matter what it costs, I do > > > > > > not want > > > > > > textrels", for the cases of hand written assembly that has to > > > > > > be > > > > > > rewritten to support PIC. And, still in this case, this costs > > > > > > a lot > > > > > > of performance, so it is enabled by default on hardened > > > > > > profiles > > > > > > and not others. > > > > > > Textrels work fine (on some architectures), they disallow W^X > > > > > > and > > > > > > force each process using the shared lib to make a "copy" at > > > > > > runtime > > > > > > in order to resolve relocations, so are not desirable but > > > > > > sometimes > > > > > > the cost outweights the gain. > > > > > > > > > > > > Plus, profiles/features/hardened enables pic by default but > > > > > > knows > > > > > > nothing about USE=asm so this is a regression for them. > > > > > > > > > > The USE flag toggles use of assembly, not use of PIC. The > > > > > default USE > > > > > value in the hardened profile should not drive decisions on > > > > > what we > > > > > name USE flags. > > > > > > > > ... but using a global well documented useflag instead of a local > > > > invention should drive such decisions. > > > > > > What 'global well documented useflag'? > > > > It's neither global, nor well-documented, but several packages do > > define it locally. > > > > https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/profiles/use.desc?id=103236c295aa30e5e42cfc8a7429e4eea5f0d680 > > https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/profiles/use.desc?id=784deb7134b9d430546557a8f8a0877bf35c02ba > > I guess this hasn't been really discussed back then. > > It is also used in a global way in profiles (make.defaults). > > > Personally, I think it should be renamed to "asm" or something > > similar > > in the majority of cases where it actually disables all use of > > assembly code. > > Thankfully these days there's usually no need to disable asm to have > pic. hardened has no mention of that flag, and I think that e.g. for > openssl they would have noticed long ago. > And again, 'asm' as a useflag makes no sense: if it works and simply > replaces a C function by a faster one then it shouldn't even be an > useflag. 'pic' on the other hand conveys the tradeoff idea. If I understand you correctly, we should just drop the USE="pic" logic from the remaining packages that have it? Or are you trying to say something else?
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Mon, 2020-05-25 at 17:04 -0400, Mike Gilbert wrote: > On Mon, May 25, 2020 at 3:18 PM Michał Górny > wrote: > > On Mon, 2020-05-25 at 19:49 +0200, Alexis Ballier wrote: > > > On Mon, 25 May 2020 11:26:26 -0400 > > > Mike Gilbert wrote: > > > > > > > On Mon, May 25, 2020 at 9:13 AM Alexis Ballier < > > > > aball...@gentoo.org> > > > > wrote: > > > > > On Sun, 24 May 2020 20:25:11 + (UTC) > > > > > "Thomas Deutschmann" wrote: > > > > > > > > > > > commit: 6e149596cc76f1bbcee6720828c8c8c92420f2a3 > > > > > > Author: Thomas Deutschmann gentoo > > > > > > org> > > > > > > AuthorDate: Sun May 24 19:47:08 2020 + > > > > > > Commit: Thomas Deutschmann gentoo > > > > > > org> > > > > > > CommitDate: Sun May 24 20:23:53 2020 + > > > > > > URL: > > > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e149596 > > > > > > > > > > > > media-libs/x265: drop USE=pic > > > > > > > > > > > > Gentoo's toolchain uses PIC by default. Since USE=asm was > > > > > > added, > > > > > > we no longer need a USE flag to control that behavior. > > > > > > > > > > You got it wrong here it seems: USE=pic does not control > > > > > whether > > > > > the toolchain produces PIC or not. Shared libs always are, > > > > > and have > > > > > always been, built that way on Gentoo. > > > > > In this case, USE=pic means "no matter what it costs, I do > > > > > not want > > > > > textrels", for the cases of hand written assembly that has to > > > > > be > > > > > rewritten to support PIC. And, still in this case, this costs > > > > > a lot > > > > > of performance, so it is enabled by default on hardened > > > > > profiles > > > > > and not others. > > > > > Textrels work fine (on some architectures), they disallow W^X > > > > > and > > > > > force each process using the shared lib to make a "copy" at > > > > > runtime > > > > > in order to resolve relocations, so are not desirable but > > > > > sometimes > > > > > the cost outweights the gain. > > > > > > > > > > Plus, profiles/features/hardened enables pic by default but > > > > > knows > > > > > nothing about USE=asm so this is a regression for them. > > > > > > > > The USE flag toggles use of assembly, not use of PIC. The > > > > default USE > > > > value in the hardened profile should not drive decisions on > > > > what we > > > > name USE flags. > > > > > > ... but using a global well documented useflag instead of a local > > > invention should drive such decisions. > > > > What 'global well documented useflag'? > > It's neither global, nor well-documented, but several packages do > define it locally. > https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/profiles/use.desc?id=103236c295aa30e5e42cfc8a7429e4eea5f0d680 https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/profiles/use.desc?id=784deb7134b9d430546557a8f8a0877bf35c02ba I guess this hasn't been really discussed back then. It is also used in a global way in profiles (make.defaults). > Personally, I think it should be renamed to "asm" or something > similar > in the majority of cases where it actually disables all use of > assembly code. Thankfully these days there's usually no need to disable asm to have pic. hardened has no mention of that flag, and I think that e.g. for openssl they would have noticed long ago. And again, 'asm' as a useflag makes no sense: if it works and simply replaces a C function by a faster one then it shouldn't even be an useflag. 'pic' on the other hand conveys the tradeoff idea.
Re: [gentoo-dev] x11-base/xorg-server: No longer enabling suid by default.
200525 Piotr Karbowski wrote: > There are 3 common ways the xorg-server is started: ... > - via `startx`, That's how I've always started Xorg. > if systemd or elogind are present, I don't use those. > can work without suid, without them, suid is required. ... > What do you think about turning the current possible opt-out of Xorg as root > into possible opt-in for running Xorg as root ? ... I'ld rather you didn't. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatcadotinterdotnet
[gentoo-dev] x11-base/xorg-server: No longer enabling suid by default.
Hi, For years the xorg-server in Gentoo was defaulting to be running with suid, even those that does not really require it, like systemd users and those who runs elogind still end up with X as uid 0 because of +suid default. Times has changed, we now have +elogind in desktop profile, xorg-server can no longer work without udev (due to input drivers), so there's no real benefit for defaulting to suid. There are 3 common ways the xorg-server is started: - via XDM of some sort, usually forked as root, does not require suid, systemd or elogind. - via better XDM that can into logind interface, started as regular user thanks to logind interface provided by either systemd or elogind. - via `startx`, if systemd or elogind are present, can work without suid, without them, suid is required. Flipping current '+suid (-)elogind' as *default* USE flags on ebuild level into '+elogind (-)suid' will not affect first two use cases, and affect only 3rd one if neither systemd is used, or elogind is enabled. What I'd like to go with is to enable elogind and disable suid on ebuild level. The systemd profiles have use.mask for elogind, meaning it's not a problem for them. and those who do not want to use any logind provider can still opt-out out of it and go back to use suid. It shouldn't really affect most of the users in any negative way, if anything, it will make more users to not run Xorg as root, which is a positive aspect. The alternative way would be to enable elogind on default profile, however it would also affect those who run headless Gentoo, of which a lot refuse to use any login manager. So, dear people of Gentoo, what do you think about turning the current possible opt-out of Xorg as root into possible opt-in for running Xorg as root? People still will have a choice, just the defaults will be more sane. -- Piotr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Mon, May 25, 2020 at 3:18 PM Michał Górny wrote: > > On Mon, 2020-05-25 at 19:49 +0200, Alexis Ballier wrote: > > On Mon, 25 May 2020 11:26:26 -0400 > > Mike Gilbert wrote: > > > > > On Mon, May 25, 2020 at 9:13 AM Alexis Ballier > > > wrote: > > > > On Sun, 24 May 2020 20:25:11 + (UTC) > > > > "Thomas Deutschmann" wrote: > > > > > > > > > commit: 6e149596cc76f1bbcee6720828c8c8c92420f2a3 > > > > > Author: Thomas Deutschmann gentoo org> > > > > > AuthorDate: Sun May 24 19:47:08 2020 + > > > > > Commit: Thomas Deutschmann gentoo org> > > > > > CommitDate: Sun May 24 20:23:53 2020 + > > > > > URL: > > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e149596 > > > > > > > > > > media-libs/x265: drop USE=pic > > > > > > > > > > Gentoo's toolchain uses PIC by default. Since USE=asm was added, > > > > > we no longer need a USE flag to control that behavior. > > > > > > > > You got it wrong here it seems: USE=pic does not control whether > > > > the toolchain produces PIC or not. Shared libs always are, and have > > > > always been, built that way on Gentoo. > > > > In this case, USE=pic means "no matter what it costs, I do not want > > > > textrels", for the cases of hand written assembly that has to be > > > > rewritten to support PIC. And, still in this case, this costs a lot > > > > of performance, so it is enabled by default on hardened profiles > > > > and not others. > > > > Textrels work fine (on some architectures), they disallow W^X and > > > > force each process using the shared lib to make a "copy" at runtime > > > > in order to resolve relocations, so are not desirable but sometimes > > > > the cost outweights the gain. > > > > > > > > Plus, profiles/features/hardened enables pic by default but knows > > > > nothing about USE=asm so this is a regression for them. > > > > > > The USE flag toggles use of assembly, not use of PIC. The default USE > > > value in the hardened profile should not drive decisions on what we > > > name USE flags. > > > > ... but using a global well documented useflag instead of a local > > invention should drive such decisions. > > What 'global well documented useflag'? It's neither global, nor well-documented, but several packages do define it locally. profiles % grep ":pic " use.local.desc app-arch/gzip:pic - disable optimized assembly code that is not PIC friendly app-benchmarks/ramspeed:pic - Force shared libraries to be built as PIC (this is slower) dev-libs/gmp:pic - Force static libraries to be built as PIC to avoid TEXTRELs. gnome-base/orbit:pic - Force libname-server-2 to be built as PIC; needed on hardened systems media-libs/x264:pic - disable optimized assembly code that is not PIC friendly media-libs/x265:pic - Disable optimized assembly code that is not PIC friendly media-libs/xvid:pic - disable optimized assembly code that is not PIC friendly media-video/ffmpeg:pic - Force shared libraries to be built as PIC (this is slower) media-video/transcode:pic - disable optimized assembly code that is not PIC friendly www-client/chromium:pic - Disable optimized assembly code that is not PIC friendly I suspect this flag got copy/pasted between various packages related to ffmpeg. That's certainly how chromium ended up with it. Personally, I think it should be renamed to "asm" or something similar in the majority of cases where it actually disables all use of assembly code.
Re: [gentoo-dev] [PATCH 1/2] toolchain-funcs.eclass: export tc-get*READELF helpers, bug #725304
On Mon, 25 May 2020 11:30:29 -0400 Mike Gilbert wrote: > On Mon, May 25, 2020 at 9:06 AM Sergei Trofimovich wrote: > > > > Bug: https://bugs.gentoo.org/725304 > > Signed-off-by: Sergei Trofimovich > > Both patches look good to me. > > However, I think you should remove the bug number from the summary > line; it makes the summary too long and the Bug tag later in the > commit message is sufficient. Sounds good! Dropped bug number and pushed as: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ccdea417c4a259a03a745e3a977ac56827be5ae4 https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7bd13f6d55a51f2a1f4da69a41df7973fa7503cc -- Sergei
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Mon, 2020-05-25 at 19:49 +0200, Alexis Ballier wrote: > On Mon, 25 May 2020 11:26:26 -0400 > Mike Gilbert wrote: > > > On Mon, May 25, 2020 at 9:13 AM Alexis Ballier > > wrote: > > > On Sun, 24 May 2020 20:25:11 + (UTC) > > > "Thomas Deutschmann" wrote: > > > > > > > commit: 6e149596cc76f1bbcee6720828c8c8c92420f2a3 > > > > Author: Thomas Deutschmann gentoo org> > > > > AuthorDate: Sun May 24 19:47:08 2020 + > > > > Commit: Thomas Deutschmann gentoo org> > > > > CommitDate: Sun May 24 20:23:53 2020 + > > > > URL: > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e149596 > > > > > > > > media-libs/x265: drop USE=pic > > > > > > > > Gentoo's toolchain uses PIC by default. Since USE=asm was added, > > > > we no longer need a USE flag to control that behavior. > > > > > > You got it wrong here it seems: USE=pic does not control whether > > > the toolchain produces PIC or not. Shared libs always are, and have > > > always been, built that way on Gentoo. > > > In this case, USE=pic means "no matter what it costs, I do not want > > > textrels", for the cases of hand written assembly that has to be > > > rewritten to support PIC. And, still in this case, this costs a lot > > > of performance, so it is enabled by default on hardened profiles > > > and not others. > > > Textrels work fine (on some architectures), they disallow W^X and > > > force each process using the shared lib to make a "copy" at runtime > > > in order to resolve relocations, so are not desirable but sometimes > > > the cost outweights the gain. > > > > > > Plus, profiles/features/hardened enables pic by default but knows > > > nothing about USE=asm so this is a regression for them. > > > > The USE flag toggles use of assembly, not use of PIC. The default USE > > value in the hardened profile should not drive decisions on what we > > name USE flags. > > ... but using a global well documented useflag instead of a local > invention should drive such decisions. What 'global well documented useflag'? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Mon, 25 May 2020 11:26:26 -0400 Mike Gilbert wrote: > On Mon, May 25, 2020 at 9:13 AM Alexis Ballier > wrote: > > > > On Sun, 24 May 2020 20:25:11 + (UTC) > > "Thomas Deutschmann" wrote: > > > > > commit: 6e149596cc76f1bbcee6720828c8c8c92420f2a3 > > > Author: Thomas Deutschmann gentoo org> > > > AuthorDate: Sun May 24 19:47:08 2020 + > > > Commit: Thomas Deutschmann gentoo org> > > > CommitDate: Sun May 24 20:23:53 2020 + > > > URL: > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e149596 > > > > > > media-libs/x265: drop USE=pic > > > > > > Gentoo's toolchain uses PIC by default. Since USE=asm was added, > > > we no longer need a USE flag to control that behavior. > > > > > > You got it wrong here it seems: USE=pic does not control whether > > the toolchain produces PIC or not. Shared libs always are, and have > > always been, built that way on Gentoo. > > In this case, USE=pic means "no matter what it costs, I do not want > > textrels", for the cases of hand written assembly that has to be > > rewritten to support PIC. And, still in this case, this costs a lot > > of performance, so it is enabled by default on hardened profiles > > and not others. > > Textrels work fine (on some architectures), they disallow W^X and > > force each process using the shared lib to make a "copy" at runtime > > in order to resolve relocations, so are not desirable but sometimes > > the cost outweights the gain. > > > > Plus, profiles/features/hardened enables pic by default but knows > > nothing about USE=asm so this is a regression for them. > > The USE flag toggles use of assembly, not use of PIC. The default USE > value in the hardened profile should not drive decisions on what we > name USE flags. ... but using a global well documented useflag instead of a local invention should drive such decisions. > > You can add the flag to package.use or package.use.mask in the > hardened profile if necessary. Sure but it was not added there and it's not really relevant here since USE=asm does not make any sense either. (aka: this was better before this series of commits)
Re: [gentoo-dev] [PATCH 1/2] toolchain-funcs.eclass: export tc-get*READELF helpers, bug #725304
On Mon, May 25, 2020 at 9:06 AM Sergei Trofimovich wrote: > > Bug: https://bugs.gentoo.org/725304 > Signed-off-by: Sergei Trofimovich Both patches look good to me. However, I think you should remove the bug number from the summary line; it makes the summary too long and the Bug tag later in the commit message is sufficient.
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Mon, May 25, 2020 at 9:13 AM Alexis Ballier wrote: > > On Sun, 24 May 2020 20:25:11 + (UTC) > "Thomas Deutschmann" wrote: > > > commit: 6e149596cc76f1bbcee6720828c8c8c92420f2a3 > > Author: Thomas Deutschmann gentoo org> > > AuthorDate: Sun May 24 19:47:08 2020 + > > Commit: Thomas Deutschmann gentoo org> > > CommitDate: Sun May 24 20:23:53 2020 + > > URL: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e149596 > > > > media-libs/x265: drop USE=pic > > > > Gentoo's toolchain uses PIC by default. Since USE=asm was added, > > we no longer need a USE flag to control that behavior. > > > You got it wrong here it seems: USE=pic does not control whether > the toolchain produces PIC or not. Shared libs always are, and have > always been, built that way on Gentoo. > In this case, USE=pic means "no matter what it costs, I do not want > textrels", for the cases of hand written assembly that has to be > rewritten to support PIC. And, still in this case, this costs a lot of > performance, so it is enabled by default on hardened profiles and not > others. > Textrels work fine (on some architectures), they disallow W^X and force > each process using the shared lib to make a "copy" at runtime in order > to resolve relocations, so are not desirable but sometimes the cost > outweights the gain. > > Plus, profiles/features/hardened enables pic by default but knows > nothing about USE=asm so this is a regression for them. The USE flag toggles use of assembly, not use of PIC. The default USE value in the hardened profile should not drive decisions on what we name USE flags. You can add the flag to package.use or package.use.mask in the hardened profile if necessary.
[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Sun, 24 May 2020 20:25:11 + (UTC) "Thomas Deutschmann" wrote: > commit: 6e149596cc76f1bbcee6720828c8c8c92420f2a3 > Author: Thomas Deutschmann gentoo org> > AuthorDate: Sun May 24 19:47:08 2020 + > Commit: Thomas Deutschmann gentoo org> > CommitDate: Sun May 24 20:23:53 2020 + > URL: > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e149596 > > media-libs/x265: drop USE=pic > > Gentoo's toolchain uses PIC by default. Since USE=asm was added, > we no longer need a USE flag to control that behavior. You got it wrong here it seems: USE=pic does not control whether the toolchain produces PIC or not. Shared libs always are, and have always been, built that way on Gentoo. In this case, USE=pic means "no matter what it costs, I do not want textrels", for the cases of hand written assembly that has to be rewritten to support PIC. And, still in this case, this costs a lot of performance, so it is enabled by default on hardened profiles and not others. Textrels work fine (on some architectures), they disallow W^X and force each process using the shared lib to make a "copy" at runtime in order to resolve relocations, so are not desirable but sometimes the cost outweights the gain. Plus, profiles/features/hardened enables pic by default but knows nothing about USE=asm so this is a regression for them. Alexis.
[gentoo-dev] [PATCH 2/2] multilib.eclass: populate READELF, bug #725304
For both multilib and non-multilib profiles binutils provides
tools with native CHOST prefix only. For example on amd64 there
is only 'x86_64-pc-linux-gnu-readelf' and 'readelf'.
meson build system uses 'readelf' or $READELF binaries
and relies on meson.eclass to populate READELF.
The change overrides READELF and friends to 'x86_64-pc-linux-gnu-readelf'
for multilib setup similar to other environment variables.
Tested on net-libs/gssdp package.
Closes: https://bugs.gentoo.org/725304
Signed-off-by: Sergei Trofimovich
---
eclass/multilib.eclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
index b79718bb193..ed54568aa2d 100644
--- a/eclass/multilib.eclass
+++ b/eclass/multilib.eclass
@@ -468,6 +468,7 @@ multilib_toolchain_setup() {
NM
OBJDUMP
RANLIB
+ READELF
STRIP
PKG_CONFIG_LIBDIR
PKG_CONFIG_PATH
@@ -510,6 +511,7 @@ multilib_toolchain_setup() {
export NM="$(tc-getNM)" # Avoid 'nm', use '${CHOST}-nm'
export OBJDUMP="$(tc-getOBJDUMP)" # Avoid 'objdump', use
'${CHOST}-objdump'
export RANLIB="$(tc-getRANLIB)" # Avoid 'ranlib', use
'${CHOST}-ranlib'
+ export READELF="$(tc-getREADELF)" # Avoid 'readelf', use
'${CHOST}-readelf'
export STRIP="$(tc-getSTRIP)" # Avoid 'strip', use
'${CHOST}-strip'
export CHOST=$(get_abi_CHOST $1)
export PKG_CONFIG_LIBDIR=${EPREFIX}/usr/$(get_libdir)/pkgconfig
--
2.26.2
[gentoo-dev] [PATCH 1/2] toolchain-funcs.eclass: export tc-get*READELF helpers, bug #725304
Bug: https://bugs.gentoo.org/725304
Signed-off-by: Sergei Trofimovich
---
eclass/toolchain-funcs.eclass | 9 +
1 file changed, 9 insertions(+)
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index 1bc6cbbc108..709c3baca53 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -85,6 +85,10 @@ tc-getNM() { tc-getPROG NM nm "$@"; }
# @USAGE: [toolchain prefix]
# @RETURN: name of the archiver indexer
tc-getRANLIB() { tc-getPROG RANLIB ranlib "$@"; }
+# @FUNCTION: tc-getREADELF
+# @USAGE: [toolchain prefix]
+# @RETURN: name of the ELF enspector
+tc-getREADELF() { tc-getPROG READELF readelf "$@"; }
# @FUNCTION: tc-getOBJCOPY
# @USAGE: [toolchain prefix]
# @RETURN: name of the object copier
@@ -158,6 +162,10 @@ tc-getBUILD_NM() { tc-getBUILD_PROG NM nm "$@"; }
# @USAGE: [toolchain prefix]
# @RETURN: name of the archiver indexer for building binaries to run on the
build machine
tc-getBUILD_RANLIB() { tc-getBUILD_PROG RANLIB ranlib "$@"; }
+# @FUNCTION: tc-getBUILD_READELF
+# @USAGE: [toolchain prefix]
+# @RETURN: name of the ELF enspector for building binaries to run on the build
machine
+tc-getBUILD_READELF() { tc-getBUILD_PROG READELF readelf "$@"; }
# @FUNCTION: tc-getBUILD_OBJCOPY
# @USAGE: [toolchain prefix]
# @RETURN: name of the object copier for building binaries to run on the build
machine
@@ -376,6 +384,7 @@ tc-env_build() {
NM=$(tc-getBUILD_NM) \
PKG_CONFIG=$(tc-getBUILD_PKG_CONFIG) \
RANLIB=$(tc-getBUILD_RANLIB) \
+ READELF=$(tc-getBUILD_READELF) \
"$@"
}
--
2.26.2
[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Sun, 24 May 2020 20:25:11 + (UTC)
"Thomas Deutschmann" wrote:
> commit: eba596db8a926adb18595549c89294ed0a1e929e
> Author: Thomas Deutschmann gentoo org>
> AuthorDate: Sun May 24 15:07:04 2020 +
> Commit: Thomas Deutschmann gentoo org>
> CommitDate: Sun May 24 20:23:50 2020 +
> URL:
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=eba596db
>
> media-libs/x265: rework assembly support
>
> Closes: https://bugs.gentoo.org/681878
> Package-Manager: Portage-2.3.99, Repoman-2.3.22
> Signed-off-by: Thomas Deutschmann gentoo.org>
>
> media-libs/x265/metadata.xml| 1 +
> media-libs/x265/x265-3.3.ebuild | 66
> - 2 files changed, 34
> insertions(+), 33 deletions(-)
>
> diff --git a/media-libs/x265/metadata.xml
> b/media-libs/x265/metadata.xml index 22a07293b83..c585d553631 100644
> --- a/media-libs/x265/metadata.xml
> +++ b/media-libs/x265/metadata.xml
> @@ -5,6 +5,7 @@
> media-vi...@gentoo.org
>
>
> +Enable x86_64 assembly optimizations.
This should not even be an useflag.
Either it works or does not. Individual features support is controlled
by cpu_flags_* (or built-in and autodetected at runtime).
Please fix.
> Add support for producing 10bits HEVC.
> Add support for producing 12bits HEVC.
> Build with support for NUMA nodes.
>
> diff --git a/media-libs/x265/x265-3.3.ebuild
> b/media-libs/x265/x265-3.3.ebuild index 9fc0159bc00..f5c4fee6d97
> 100644 --- a/media-libs/x265/x265-3.3.ebuild
> +++ b/media-libs/x265/x265-3.3.ebuild
> @@ -19,15 +19,17 @@ HOMEPAGE="http://x265.org/
> https://bitbucket.org/multicoreware/x265/wiki/Home"; LICENSE="GPL-2"
> # subslot = libx265 soname
> SLOT="0/188"
> -IUSE="+10bit +12bit cpu_flags_arm_neon numa pic power8 test"
> +IUSE="+asm +10bit +12bit cpu_flags_arm_neon numa pic power8 test"
>
> # Test suite requires assembly support and is known to be broken
> RESTRICT="test"
>
> ASM_DEPEND=">=dev-lang/yasm-1.2.0"
>
> -BDEPEND="abi_x86_32? ( ${ASM_DEPEND} )
> - abi_x86_64? ( ${ASM_DEPEND} )"
> +BDEPEND="asm? (
> + abi_x86_32? ( ${ASM_DEPEND} )
> + abi_x86_64? ( ${ASM_DEPEND} )
> + )"
>
> RDEPEND="numa? ( >=sys-process/numactl-2.0.10-r1[${MULTILIB_USEDEP}]
> )"
> @@ -85,17 +87,6 @@ x265_variant_src_configure() {
> -DENABLE_CLI=OFF
> -DMAIN12=ON
> )
> - if [[ ${ABI} = x86 ]] ; then
> - mycmakeargs+=( -DENABLE_ASSEMBLY=OFF
> )
> - fi
> - if [[ ${ABI} = arm ]] ; then
> - # 589674
> - mycmakeargs+=( -DENABLE_ASSEMBLY=OFF
> )
> - fi
> - if [[ ${ABI} = ppc64 ]] ; then
> - #
> https://bugs.gentoo.org/show_bug.cgi?id=607802#c5
> - mycmakeargs+=( -DENABLE_ASSEMBLY=OFF
> -DENABLE_ALTIVEC=OFF )
> - fi
> ;;
> "main10")
> mycmakeargs+=(
> @@ -104,17 +95,6 @@ x265_variant_src_configure() {
> -DENABLE_SHARED=OFF
> -DENABLE_CLI=OFF
> )
> - if [[ ${ABI} = x86 ]] ; then
> - mycmakeargs+=( -DENABLE_ASSEMBLY=OFF
> )
> - fi
> - if [[ ${ABI} = arm ]] ; then
> - # 589674
> - mycmakeargs+=( -DENABLE_ASSEMBLY=OFF
> )
> - fi
> - if [[ ${ABI} = ppc64 ]] ; then
> - #
> https://bugs.gentoo.org/show_bug.cgi?id=607802#c5
> - mycmakeargs+=( -DENABLE_ASSEMBLY=OFF
> -DENABLE_ALTIVEC=OFF )
> - fi
> ;;
What are you trying to fix here ?
This sounds like a regression to me: some asm will not work for
10/12bits variants while 8bit is fine. You are removing this work here.
> "main")
> if (( "${#MULTIBUILD_VARIANTS[@]}" > 1 )) ;
> then @@ -146,7 +126,6 @@ multilib_src_configure() {
> append-cxxflags -fPIC
>
> local myabicmakeargs=(
> - -DENABLE_TESTS=$(usex test ON OFF)
> $(multilib_is_native_abi || echo "-DENABLE_CLI=OFF")
> -DENABLE_LIBNUMA=$(usex numa ON OFF)
> -DCPU_POWER8=$(usex power8 ON OFF)
> @@ -154,18 +133,39 @@ multilib_src_configure() {
> -DLIB_INSTALL_DIR="$(get_libdir)"
> )
>
> + local supports_asm=yes
> +
> if [[ ${ABI} = x86 ]] ; then
> - # Bug #528202
> - if use pic ; then
> + if use asm && use pic ; then
> + # Bug #528202
> ewarn "PIC has been requested but x86 asm is
> not P
