>>> Install thunderbird-60.5.3 into /mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.5.3/image/ category mail-client * PT_PAX marking -m /mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.5.3/work/thunderbird-60.5.3/tbird/dist/bin/xpcshell with scanelf * XATTR_PAX marking -me /mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.5.3/work/thunderbird-60.5.3/tbird/dist/bin/xpcshell with setfattr 0:00.71 /usr/bin/gmake -C . -j8 -s -w install 0:00.72 gmake: Entering directory '/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.5.3/work/thunderbird-60.5.3/tbird' 0:00.79 gmake[1]: Entering directory '/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.5.3/work/thunderbird-60.5.3/tbird/comm/mail/installer' 0:17.89 terminate called after throwing an instance of 'std::__ios_failure' 0:17.89 what(): basic_ios::clear: iostream error 0:18.31 Traceback (most recent call last): 0:18.31 File "/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.5.3/work/thunderbird-60.5.3/toolkit/mozapps/installer/packager.py", line 343, in <module> 0:18.31 main() 0:18.31 File "/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.5.3/work/thunderbird-60.5.3/toolkit/mozapps/installer/packager.py", line 337, in main 0:18.32 copier.copy(args.destination) 0:18.32 File "/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.5.3/work/thunderbird-60.5.3/python/mozbuild/mozpack/copier.py", line 431, in copy 0:18.32 copy_results.append((destfile, f.copy(destfile, skip_if_older))) 0:18.32 File "/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.5.3/work/thunderbird-60.5.3/python/mozbuild/mozpack/files.py", line 296, in copy 0:18.32 elfhack(dest) 0:18.32 File "/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.5.3/work/thunderbird-60.5.3/python/mozbuild/mozpack/executables.py", line 124, in elfhack 0:18.32 errors.fatal('Error executing ' + ' '.join(cmd)) 0:18.32 File "/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.5.3/work/thunderbird-60.5.3/python/mozbuild/mozpack/errors.py", line 103, in fatal 0:18.32 self._handle(self.FATAL, msg) 0:18.32 File "/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.5.3/work/thunderbird-60.5.3/python/mozbuild/mozpack/errors.py", line 98, in _handle 0:18.32 raise ErrorMessage(msg) 0:18.32 mozpack.errors.ErrorMessage: Error: Error executing /mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.5.3/work/thunderbird-60.5.3/tbird/build/unix/elfhack/elfhack ../../../dist/thunderbird/libxul.so 0:18.38 gmake[1]: *** [/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.5.3/work/thunderbird-60.5.3/toolkit/mozapps/installer/packager.mk:22: stage-package] Error 1 0:18.38 gmake[1]: Leaving directory '/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.5.3/work/thunderbird-60.5.3/tbird/comm/mail/installer' 0:18.38 gmake: *** [/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.5.3/work/thunderbird-60.5.3/comm/mail/build.mk:16: install] Error 2 0:18.39 gmake: Leaving directory '/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.5.3/work/thunderbird-60.5.3/tbird' * ERROR: mail-client/thunderbird-60.5.3::gentoo failed (install phase): * (no error message)
Created attachment 570364 [details] emerge --info
Created attachment 570366 [details] build.log
Sat Mar 23 12:24 anarchy@bull Downloads $ cat /etc/portage/env/elf-hack.conf EXTRA_ECONF="--disable-elf-hack" Sat Mar 23 12:24 anarchy@bull Downloads $ cat /etc/portage/package.env/elf-hack mail-client/thunderbird elf-hack.conf please setup the two files and test. I am also seeing issues with elf-hack on musl and I am working to debug them already there.
Yes, that fixes it. I'm not using musl on this machine though, but glibc.
(In reply to Alexey from comment #4) > Yes, that fixes it. > I'm not using musl on this machine though, but glibc. yeah is same issue no matter the libc, at least you have a work around while I finish debugging and fixing it.
*** Bug 663816 has been marked as a duplicate of this bug. ***
I have added 60.6.1-r1 to the mozilla overlay, I have tested it and works smoothly with elfhack on my machine again. I ended up backporting elfhack from 67.0b11 and updated a single header to address the issue. Please test from the overlay and provide your results here.
>>> Install thunderbird-60.6.1-r1 into /mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/image/ category mail-client * PT_PAX marking -m /mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/thunderbird-60.6.1/tbird/dist/bin/xpcshell with scanelf * XATTR_PAX marking -me /mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/thunderbird-60.6.1/tbird/dist/bin/xpcshell with setfattr 0:00.52 /usr/bin/gmake -C . -j8 -s -w install 0:00.53 gmake: Entering directory '/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/thunderbird-60.6.1/tbird' 0:00.57 gmake[1]: Entering directory '/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/thunderbird-60.6.1/tbird/comm/mail/installer' 0:12.10 terminate called after throwing an instance of 'std::__ios_failure' 0:12.10 what(): basic_ios::clear: iostream error 0:12.45 Traceback (most recent call last): 0:12.45 File "/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/thunderbird-60.6.1/toolkit/mozapps/installer/packager.py", line 343, in <module> 0:12.45 main() 0:12.45 File "/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/thunderbird-60.6.1/toolkit/mozapps/installer/packager.py", line 337, in main 0:12.45 copier.copy(args.destination) 0:12.45 File "/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/thunderbird-60.6.1/python/mozbuild/mozpack/copier.py", line 431, in copy 0:12.45 copy_results.append((destfile, f.copy(destfile, skip_if_older))) 0:12.45 File "/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/thunderbird-60.6.1/python/mozbuild/mozpack/files.py", line 296, in copy 0:12.45 elfhack(dest) 0:12.45 File "/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/thunderbird-60.6.1/python/mozbuild/mozpack/executables.py", line 124, in elfhack 0:12.45 errors.fatal('Error executing ' + ' '.join(cmd)) 0:12.45 File "/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/thunderbird-60.6.1/python/mozbuild/mozpack/errors.py", line 103, in fatal 0:12.45 self._handle(self.FATAL, msg) 0:12.45 File "/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/thunderbird-60.6.1/python/mozbuild/mozpack/errors.py", line 98, in _handle 0:12.45 raise ErrorMessage(msg) 0:12.45 mozpack.errors.ErrorMessage: Error: Error executing /mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/thunderbird-60.6.1/tbird/build/unix/elfhack/elfhack ../../../dist/thunderbird/libxul.so 0:12.51 gmake[1]: *** [/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/thunderbird-60.6.1/toolkit/mozapps/installer/packager.mk:22: stage-package] Error 1 0:12.51 gmake[1]: Leaving directory '/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/thunderbird-60.6.1/tbird/comm/mail/installer' 0:12.51 gmake: *** [/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/thunderbird-60.6.1/comm/mail/build.mk:16: install] Error 2 0:12.51 gmake: Leaving directory '/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/thunderbird-60.6.1/tbird' Do you need the full build log?
Please show us the output of configure step, no complete build.log needed yet.
Created attachment 573126 [details] 60.6.1-r1 configure log
Created attachment 573128 [details] 60.6.1-r1 config.log
(In reply to Alexey from comment #8) > >>> Install thunderbird-60.6.1-r1 into /mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/image/ category mail-client > * PT_PAX marking -m > /mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/ > thunderbird-60.6.1/tbird/dist/bin/xpcshell with scanelf > > * XATTR_PAX marking -me > /mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/ > thunderbird-60.6.1/tbird/dist/bin/xpcshell with setfattr > > 0:00.52 /usr/bin/gmake -C . -j8 -s -w install > 0:00.53 gmake: Entering directory > '/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/ > thunderbird-60.6.1/tbird' > 0:00.57 gmake[1]: Entering directory > '/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/ > thunderbird-60.6.1/tbird/comm/mail/installer' > > 0:12.10 terminate called after throwing an instance of 'std::__ios_failure' > 0:12.10 what(): basic_ios::clear: iostream error > 0:12.45 Traceback (most recent call last): > 0:12.45 File > "/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/ > thunderbird-60.6.1/toolkit/mozapps/installer/packager.py", line 343, in > <module> > > 0:12.45 main() > 0:12.45 File > "/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/ > thunderbird-60.6.1/toolkit/mozapps/installer/packager.py", line 337, in main > > 0:12.45 copier.copy(args.destination) > 0:12.45 File > "/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/ > thunderbird-60.6.1/python/mozbuild/mozpack/copier.py", line 431, in copy > > 0:12.45 copy_results.append((destfile, f.copy(destfile, skip_if_older))) > 0:12.45 File > "/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/ > thunderbird-60.6.1/python/mozbuild/mozpack/files.py", line 296, in copy > > 0:12.45 elfhack(dest) > 0:12.45 File > "/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/ > thunderbird-60.6.1/python/mozbuild/mozpack/executables.py", line 124, in > elfhack > > 0:12.45 errors.fatal('Error executing ' + ' '.join(cmd)) > 0:12.45 File > "/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/ > thunderbird-60.6.1/python/mozbuild/mozpack/errors.py", line 103, in fatal > > 0:12.45 self._handle(self.FATAL, msg) > 0:12.45 File > "/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/ > thunderbird-60.6.1/python/mozbuild/mozpack/errors.py", line 98, in _handle > > 0:12.45 raise ErrorMessage(msg) > 0:12.45 mozpack.errors.ErrorMessage: Error: Error executing > /mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/ > thunderbird-60.6.1/tbird/build/unix/elfhack/elfhack > ../../../dist/thunderbird/libxul.so > > 0:12.51 gmake[1]: *** > [/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/ > thunderbird-60.6.1/toolkit/mozapps/installer/packager.mk:22: stage-package] > Error 1 > > 0:12.51 gmake[1]: Leaving directory > '/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/ > thunderbird-60.6.1/tbird/comm/mail/installer' > > 0:12.51 gmake: *** > [/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/ > thunderbird-60.6.1/comm/mail/build.mk:16: install] Error 2 > > 0:12.51 gmake: Leaving directory > '/mnt/ssdhome/portage-tmp/portage/mail-client/thunderbird-60.6.1-r1/work/ > thunderbird-60.6.1/tbird' > > Do you need the full build log? Yes I need the full build.log please.
Created attachment 573130 [details] 60.6.1-r1 build.log
Alexey do you have firefox installed by chance? If so what version and are you seeing a similiar failure in it?
www-client/firefox-65.0.2:0 No, it didn't fail.
60.6.1-r1 doesn't work for me, either. I have noticed that Alexey and I have two things in common, though: first, we're using -ggdb3 by default (and I am additionally also using -gdwarf-4, -g3 and -fno-omit-frame-pointer) and secondly our system compilers are GCC 8.x (8.2 for him, 8.3 for me). On a hunch, I disabled -g3 -ggdb3 -gdwarf-4 (but not -fno-omit-frame-pointer) for 60.6.1-r1 and that seems to have worked. ALexey, can you please test 60.6.1-r1 with -ggdb3 disabled? Maybe 60.6.1 would have worked as well without -ggdb3; didn't test, but it's possible. I'm not included to run another round of building this rather huge package just to find out. If my suspicion is right, the ebuild will need to strip out debugging compiler flags - at least for now.
I confirm: mail-client/thunderbird-60.6.1::gentoo builds successfully without -ggdb3.
Also happening with 60.7.0. What's the maintainers take on this? I'd accept marking this bug report as invalid (because it's obviously user-inflicted), though it could be cumbersome to not have debugging symbols in thunderbird.
Yes this is a user caused issue. You should only be enabling debugging useflag and no strip on mozilla packages if you really need to debug anything.
> Yes this is a user caused issue. You should only be enabling debugging useflag and no strip on mozilla packages if you really need to debug anything. Ok, is it documented anywhere that it's the case? If it's not, I think it should be said to the user in the warning from ebuild itself.
Yeah, a warning message would be good - at least to let users know that there are known problems with -ggdb* (maybe just level 3, but who knows what other levels are also affected, also maybe -gdwarf-* and generally -g*). Especially since searching for closed bug reports is... difficult in this bugzilla instance.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=27fd29a909b99e3873042f881921f6315844d33b commit 27fd29a909b99e3873042f881921f6315844d33b Author: Jory Pratt <anarchy@gentoo.org> AuthorDate: 2019-05-26 20:05:43 +0000 Commit: Jory Pratt <anarchy@gentoo.org> CommitDate: 2019-05-26 20:07:07 +0000 mozcoreconf-v6.eclass: filter flag ggdb3 Closes: https://bugs.gentoo.org/681438 Signed-off-by: Jory Pratt <anarchy@gentoo.org> eclass/mozcoreconf-v6.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
*** Bug 686760 has been marked as a duplicate of this bug. ***
(In reply to Larry the Git Cow from comment #22) > The bug has been closed via the following commit(s): > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=27fd29a909b99e3873042f881921f6315844d33b Please re-open, since this does not fix the bug. Should be: filter-flags '-O* -g*' This break DOES occur with -g and -ggdb (without the "3", i.e., preprocessor debug info). Further, this is a very imperfect solution. What if we want to have debug symbols available? The better solution would be to detect if -g* is used and configure with --disable-elf-hack. I have opened an upstream report for this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1554428 It is caused by using the wrong data type for ELF64 in this line, as well as others: build/unix/elfhack/elfxx.h:284: ElfSection *getSectionAt(unsigned int offset); For ELF32, this should be 32-bit, but all offsets are 64-bit in ELF64. Should maybe also notify the user about -g* being stripped? (In reply to Jory A. Pratt from comment #19) > Yes this is a user caused issue. You should only be enabling debugging > useflag and no strip on mozilla packages if you really need to debug > anything. Jory, this is absurd to me. I build EVERYTHING with -ggdb (except for grub) because I AM one of those compulsive people who will debug something if it crashes. I use split-debug and I store all of my debug info on a separate device I mount on /usr/lib/debug. But I don't build everything with -g*3, lol, that's even overboard for me! :)
(In reply to Larry the Git Cow from comment #22) > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=27fd29a909b99e3873042f881921f6315844d33b > > commit 27fd29a909b99e3873042f881921f6315844d33b > Author: Jory Pratt <anarchy@gentoo.org> > AuthorDate: 2019-05-26 20:05:43 +0000 > Commit: Jory Pratt <anarchy@gentoo.org> > CommitDate: 2019-05-26 20:07:07 +0000 > > mozcoreconf-v6.eclass: filter flag ggdb3 > - filter-flags '-O*' > + filter-flags '-O* -ggdb3' ... Actually DISABLES any filtering, because it is treating '-O* -ggdb3' as a single flag, not 2 separate flags. The call which would actually filter out -O* flags and -ggdb3 flags would be: filter-flags '-O*' '-ggdb3' However I agree with comment #24: (In reply to Daniel Santos from comment #24) > The better solution would be to detect if -g* is used > and configure with --disable-elf-hack. is-flagq() function can be used to detect flags. So the following can be used: filter-flags '-O*' if is-flagq '-g*' ; then mozconfig_annotate 'elf-hack broken with -g* flags' --disable-elf-hack fi
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #25) Thank you for reopening this *in addition to* the education. The upstream bug is now at https://bugzilla.mozilla.org/show_bug.cgi?id=1495733 Although I started work on a fix, I don't have plans for any further work at this time, so I'm leaving it to somebody else to fix the root cause. The upstream report is on the "Firefox Build System", but I'm not sure what all products that affects aside from Firefox and Thunderbird. Since the upstream report was on a Firefox build, I would suggest marking this as also a Firefox: "Elfhack crashes on Fedora 29 when building optimized Firefox." I may (?) be possible to also get this with -flto and USE=custom-cflags, but I guess that would be the user's fault anyway. :)
For what it's worth, I've encountered this with just the following C/CXXFLAGS: CFLAGS="-march=native -O2 -ggdb -pipe" CXXFLAGS="-march=native -O2 -ggdb -pipe" Nothing else unusual going on to my knowledge, just --as-needed enabled: LDFLAGS="-Wl,-O1 -Wl,--as-needed" using gcc x86_64-pc-linux-gnu-9.1.0. The libxul.so does come out at > 2Gb, meaning this can be hit using just -ggdb, rather than -ggdb3 or anything like that. @mozilla team: It seems there was a proposed fix in comment #25 since June. Has this been reviewed/is there any issue with it? It would save anyone with -g* flags from wasting hours of their time compiling these large projects only to have them die at the very last step because of some broken elf-meddling by Mozilla?
From cf29bfea148f8a2fe960c495bd1887eab42e6599 Mon Sep 17 00:00:00 2001 From: Jory Pratt <anarchy@gentoo.org> Date: Wed, 17 Jul 2019 20:41:37 -0500 Subject: [PATCH] mozcoreconf-v6: Disable elf-hack when debug cflags enabled Closes: https://bugs.gentoo Signed-off-by: Jory Pratt <anarchy@gentoo.org> --- eclass/mozcoreconf-v6.eclass | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/eclass/mozcoreconf-v6.eclass b/eclass/mozcoreconf-v6.eclass index b844a3591..074b2da9f 100644 --- a/eclass/mozcoreconf-v6.eclass +++ b/eclass/mozcoreconf-v6.eclass @@ -196,7 +196,13 @@ mozconfig_init() { fi # Strip optimization so it does not end up in compile string - filter-flags '-O* -ggdb3' + filter-flags '-O*' + + filter-flags '-O*' + + if is-flagq '-g*' ; then + mozconfig_annotate 'elf-hack broken with -g* flags' --disable-elf-hack + fi # Strip over-aggressive CFLAGS use custom-cflags || strip-flags -- 2.22.0
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4b1b9bbd44e6afaebc16b483c75928da66d5c2ae commit 4b1b9bbd44e6afaebc16b483c75928da66d5c2ae Author: Jory Pratt <anarchy@gentoo.org> AuthorDate: 2019-07-18 01:49:21 +0000 Commit: Jory Pratt <anarchy@gentoo.org> CommitDate: 2019-07-18 01:49:21 +0000 mozcoreconf-v6: drop the double filter-flags that I introduced!! Closes: https://bugs.gentoo.org/681438 Signed-off-by: Jory Pratt <anarchy@gentoo.org> eclass/mozcoreconf-v6.eclass | 2 -- 1 file changed, 2 deletions(-)
