Created attachment 467014 [details] gcc-build-logs It is reproducible with a fresh-downloaded stage3 with the following: echo "=sys-devel/gcc-5.4.0-r3" /etc/portage/package.keywords USE="cxx fortran gcj nls nptl objc openmp sanitize vtv" emerge -avq1 gcc /usr/lib/portage/python3.4/ebuild-helpers/xattr/install -c -m 644 libgcj-5.4.0.jar libgcj-tools-5.4.0.jar /var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/libjava/../ecj.jar '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/image//usr/share/gcc-data/x86_64-pc-linux-gnu/5.4.0/java' install-xattr: setxattr() failed: Operation not supported make[6]: *** [Makefile:10195: install-jarDATA] Error 1 make[6]: Leaving directory '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build/x86_64-pc-linux-gnu/32/libjava' make[5]: *** [Makefile:10382: install-am] Error 2 make[5]: Leaving directory '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build/x86_64-pc-linux-gnu/32/libjava' make[4]: *** [Makefile:10240: install-recursive] Error 1 make[4]: Leaving directory '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build/x86_64-pc-linux-gnu/32/libjava' make[3]: *** [Makefile:12804: multi-do] Error 1 make[3]: Leaving directory '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build/x86_64-pc-linux-gnu/libjava' make[2]: *** [Makefile:12770: install-multi] Error 2 make[2]: Leaving directory '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build/x86_64-pc-linux-gnu/libjava' make[1]: *** [Makefile:18256: install-target-libjava] Error 2 make[1]: Leaving directory '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build' make: *** [Makefile:2301: install] Error 2 * ERROR: sys-devel/gcc-5.4.0-r3::gentoo failed (install phase): * emake failed
looks like an install-xattr problem what are your mounts exactly ?
Ago can you post the trace that you did show me? For it looks like some of the files you have is having a xattr and then install-xattr trying to copy it to image dir and fail for user.xdg.origin.url is not allowed in tmpfs. If you have /var/tmp/portage as tmpfs.
Created attachment 467104 [details] strace (In reply to Magnus Granberg from comment #2) >If you have /var/tmp/portage as tmpfs. Yes, it is on tmpfs
Created attachment 467140 [details] mounts (In reply to SpanKY from comment #1) > looks like an install-xattr problem > > what are your mounts exactly ? I printed what is outside the chroot. The issue happens only if $PORTAGE_TMPDIR is on tmpfs
asked from Zorry on irc: (chroot) vh distfiles # getfattr ecj-4.5.jar # file: ecj-4.5.jar user.xdg.origin.url So, as a workaround, the failure does not happen if If I delete it via: # setfattr --remove=user.xdg.origin.url ecj-4.5.jar
This is not a gcc problem. Something on youre end is adding user.xdm... to downloded files. user.XXXXXX exept user.pax don't work on tmpfs and install-xattr just try to copy the xattr and fail for the tmpfs don't support it.
Created attachment 470360 [details] build logs of failed gcc emerge I'm getting this as well, updating an existing install now that gcc 5.4 is stable. Also building on tmpfs. Comment 6 says that the problem is on my end; where? (GCJ is pulled in by app-text/pdftk-2.02.)
Same here. Can this be worked around?
Does portage's xattr use flag have anything to do with it?
This only happens if built on tmpfs as it does not support the xattr, even when the kernel is compiled with this support: CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_TMPFS_XATTR=y A temporary workaround is to create environment definition for gcc or any other package which wants to make use of xattr to be compiled outside of the tmpfs mountpoint. ie: >sys-devel/gcc-5.4 notmpfs.conf The problem comes from line 10195 in the Makefile (/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build/x86_64-pc-linux-gnu/libjava/Makefile) install-jarDATA: $(jar_DATA) @$(NORMAL_INSTALL) test -z "$(jardir)" || $(MKDIR_P) "$(DESTDIR)$(jardir)" @list='$(jar_DATA)'; test -n "$(jardir)" || list=; \ for p in $$list; do \ if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \ echo "$$d$$p"; \ done | $(am__base_list) | \ while read files; do \ echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(jardir)'"; \ $(INSTALL_DATA) $$files "$(DESTDIR)$(jardir)" || exit $$?; \ done the INSTALL_DATA is defined as: INSTALL_DATA = /usr/lib/portage/python2.7/ebuild-helpers/xattr/install -c -m 644 which tells the installer to use the xattr install(why not the doins?). This is wrong for tmpfs. What makes the decision which helper to use for install when creating the Makefile? In my case the files in question have no extended attributes, ie: /var/tmp/portage/sys-devel/gcc-5.4.0-r3/image/usr/share/gcc-data/x86_64-pc-linux-gnu/5.4.0/java $ getfattr libgcj-5.4.0.jar returns nothing and of course this is correct as tmpfs does not support it! Thank you, -Nikolay
(In reply to Erik Quaeghebeur from comment #9) > Does portage's xattr use flag have anything to do with it? emerging portage with -xattr and then emerging gcc indeed provides a workaround (I tested it).
(In reply to Nikolay Kichukov from comment #10) > This only happens if built on tmpfs as it does not support the xattr, even > when the kernel is compiled with this support: > > CONFIG_TMPFS=y > CONFIG_TMPFS_POSIX_ACL=y > CONFIG_TMPFS_XATTR=y > > A temporary workaround is to create environment definition for gcc or any > other package which wants to make use of xattr to be compiled outside of the > tmpfs mountpoint. ie: > > >sys-devel/gcc-5.4 notmpfs.conf > > The problem comes from line 10195 in the Makefile > (/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build/x86_64-pc-linux-gnu/ > libjava/Makefile) > > install-jarDATA: $(jar_DATA) > @$(NORMAL_INSTALL) > test -z "$(jardir)" || $(MKDIR_P) "$(DESTDIR)$(jardir)" > @list='$(jar_DATA)'; test -n "$(jardir)" || list=; \ > for p in $$list; do \ > if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \ > echo "$$d$$p"; \ > done | $(am__base_list) | \ > while read files; do \ > echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(jardir)'"; \ > $(INSTALL_DATA) $$files "$(DESTDIR)$(jardir)" || exit $$?; \ > done > > the INSTALL_DATA is defined as: INSTALL_DATA = > /usr/lib/portage/python2.7/ebuild-helpers/xattr/install -c -m 644 > > > which tells the installer to use the xattr install(why not the doins?). This > is wrong for tmpfs. What makes the decision which helper to use for install > when creating the Makefile? > > In my case the files in question have no extended attributes, ie: > > /var/tmp/portage/sys-devel/gcc-5.4.0-r3/image/usr/share/gcc-data/x86_64-pc- > linux-gnu/5.4.0/java $ getfattr libgcj-5.4.0.jar > > returns nothing and of course this is correct as tmpfs does not support it! > > Thank you, > -Nikolay Do ecj-4.5.jar have any extended attributes?
*** Bug 622486 has been marked as a duplicate of this bug. ***
*** Bug 624850 has been marked as a duplicate of this bug. ***
fwiw, just ran into this with 5.4.0-r3 as well, /var/tmp on tmpfs test -z "/usr/share/gcc-data/x86_64-pc-linux-gnu/5.4.0/java" || /bin/mkdir -p "/var/tmp/portage/sys-devel/gcc-5.4.0-r3/image//usr/share/gcc-data/x86_64-pc-linux-gnu/5.4.0/java" /usr/lib/portage/python3.4/ebuild-helpers/xattr/install -c -m 644 libgcj-5.4.0.jar libgcj-tools-5.4.0.jar /var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/libjava/../ecj.jar '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/image//usr/share/gcc-data/x86_64-pc-linux-gnu/5.4.0/java' install-xattr: setxattr() failed: Operation not supported make[6]: *** [Makefile:10195: install-jarDATA] Error 1 make[6]: Leaving directory '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build/x86_64-pc-linux-gnu/32/libjava' make[5]: *** [Makefile:10382: install-am] Error 2 make[5]: Leaving directory '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build/x86_64-pc-linux-gnu/32/libjava' make[4]: *** [Makefile:10240: install-recursive] Error 1
(In reply to Kristian Fiskerstrand from comment #15) > fwiw, just ran into this with 5.4.0-r3 as well, /var/tmp on tmpfs > > test -z "/usr/share/gcc-data/x86_64-pc-linux-gnu/5.4.0/java" || /bin/mkdir > -p > "/var/tmp/portage/sys-devel/gcc-5.4.0-r3/image//usr/share/gcc-data/x86_64-pc- > linux-gnu/5.4.0/java" > /usr/lib/portage/python3.4/ebuild-helpers/xattr/install -c -m 644 > libgcj-5.4.0.jar libgcj-tools-5.4.0.jar > /var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/libjava/../ecj.jar > '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/image//usr/share/gcc-data/x86_64-pc- > linux-gnu/5.4.0/java' > install-xattr: setxattr() failed: Operation not supported > make[6]: *** [Makefile:10195: install-jarDATA] Error 1 > make[6]: Leaving directory > '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build/x86_64-pc-linux-gnu/32/ > libjava' > make[5]: *** [Makefile:10382: install-am] Error 2 > make[5]: Leaving directory > '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build/x86_64-pc-linux-gnu/32/ > libjava' > make[4]: *** [Makefile:10240: install-recursive] Error 1 Do ecj-4.5.jar have any extended attributes?
(In reply to Magnus Granberg from comment #16) > Do ecj-4.5.jar have any extended attributes? The distfile (not on tmpfs) lsattr /usr/portage/distfiles/ecj-4.5.jar --------------e---- /usr/portage/distfiles/ecj-4.5.jar From /var/tmp/portage... # ls -l ecj.jar lrwxrwxrwx 1 portage portage 34 Sep 30 16:15 ecj.jar -> /usr/portage/distfiles/ecj-4.5.jar # lsattr ecj.jar lsattr: Operation not supported While reading flags on ecj.jar
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=8401685e8d03c8d3ba0e2c7fc432f430880a4c8c commit 8401685e8d03c8d3ba0e2c7fc432f430880a4c8c Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2017-12-10 09:17:33 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2017-12-10 09:21:40 +0000 PORTAGE_XATTR_EXCLUDE: add common user.* attributes (bug 640290) Common user.* attributes should be safe to exclude, and they are not supported on tmpfs, except for user.pax.* attributes that are supported with the patch from bug 470644. See: https://www.freedesktop.org/wiki/CommonExtendedAttributes/ Bug: https://bugs.gentoo.org/612612 Bug: https://bugs.gentoo.org/640290 cnf/make.globals | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)}
Let's assume it's fixed given we have a commit into install-xattr and have no reports. gcj is also masked for removal in all toolchain.
