| Summary: | www-client/firefox-{46|47|48|49}: ld segfaults while building libmozgtk.so (LDFLAGS overriden by widget/gtk/mozgtk/gtk{2|3}/moz.build) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Émeric Maschino <emeric.maschino> |
| Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | emeric.maschino |
| Priority: | Normal | Keywords: | REGRESSION |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build.log
environment bzip2-compressed build.log for Firefox 49 patch to remove --as-needed wrappers to gtk libs in mozgtk |
||
|
Description
Émeric Maschino
2016-05-08 09:09:41 UTC
Created attachment 433622 [details]
environment
emerge --info output:
Portage 2.2.26 (python 3.4.3-final-0, default/linux/ia64/13.0/desktop/gnome/systemd, gcc-4.9.3, glibc-2.22-r4, 4.1.15-gentoo-r1 ia64)
=================================================================
System uname: Linux-4.1.15-gentoo-r1-ia64-Madison-with-gentoo-2.2
KiB Mem: 24988608 total, 15932800 free
KiB Swap: 524272 total, 524272 free
Timestamp of repository gentoo: Mon, 02 May 2016 19:00:01 +0000
sh bash 4.3_p42-r1
ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1
app-shells/bash: 4.3_p42-r1::gentoo
dev-lang/perl: 5.20.2::gentoo
dev-lang/python: 2.7.10-r1::gentoo, 3.4.3-r1::gentoo
dev-util/cmake: 3.3.1-r1::gentoo
dev-util/pkgconfig: 0.28-r2::gentoo
sys-apps/baselayout: 2.2::gentoo
sys-apps/openrc: 0.19.1::gentoo
sys-apps/sandbox: 2.10-r1::gentoo
sys-devel/autoconf: 2.13::gentoo, 2.69::gentoo
sys-devel/automake: 1.11.6-r1::gentoo, 1.14.1::gentoo, 1.15::gentoo
sys-devel/binutils: 2.25.1-r1::gentoo
sys-devel/gcc: 4.5.4::gentoo, 4.9.3::gentoo
sys-devel/gcc-config: 1.7.3::gentoo
sys-devel/libtool: 2.4.6::gentoo
sys-devel/make: 4.1-r1::gentoo
sys-kernel/linux-headers: 4.3::gentoo (virtual/os-headers)
sys-libs/glibc: 2.22-r4::gentoo
Repositories:
gentoo
location: /usr/portage
sync-type: rsync
sync-uri: rsync://rsync.gentoo.org/gentoo-portage
priority: -1000
my_ebuilds
location: /var/lib/layman/my_ebuilds
masters: gentoo
priority: 0
ACCEPT_KEYWORDS="ia64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="ia64-unknown-linux-gnu"
CFLAGS="-O2 -pipe -mtune=itanium2"
CHOST="ia64-unknown-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -pipe -mtune=itanium2"
DISTDIR="/usr/portage/distfiles"
FCFLAGS="-O2 -pipe -mtune=itanium2"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -pipe -mtune=itanium2"
GENTOO_MIRRORS="ftp://mirrors.linuxant.fr/distfiles.gentoo.org/"
LANG="fr_FR.utf8"
LDFLAGS="-Wl,-O1 -Wl,--no-as-needed"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
USE="X a52 aac acl acpi alsa berkdb branding bzip2 cairo cdda cdr cli colord cracklib crypt cups cxx dbus dri dts dvdr eds encode evo exif fam firefox flac fortran gdbm gif glamor gnome gnome-keyring gnome-online-accounts gpm gstreamer gtk ia64 iconv introspection ipv6 jpeg lcms ldap libnotify libsecret mad mng modules mp3 mp4 mpeg nautilus ncurses nls nptl ogg opengl openmp pam pango pcre pdf png policykit ppds pulseaudio qt3support qt4 readline sdl session spell ssl startup-notification svg systemd tcpd tiff tracker truetype udev udisks unicode upower usb vorbis wxwidgets xattr xcb xml xv xvid zlib" ALSA_CARDS="fm801" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="fr" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_4" RUBY_TARGETS="ruby20 ruby21" USERLAND="GNU" VIDEO_CARDS="radeon" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset: CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
emerge -pqv output:
[ebuild U ] www-client/firefox-46.0 [38.8.0] USE="dbus ffmpeg%* gmp-autoupdate hwaccel%* jemalloc3 jit pulseaudio startup-notification -bindist -custom-cflags (-custom-optimization) -debug -force-gtk2% -hardened (-neon) (-pgo) (-selinux) (-system-cairo) -system-harfbuzz% -system-icu -system-jpeg -system-libevent% -system-libvpx -system-sqlite {-test} (-wifi) (-egl%) (-gstreamer%*) (-gstreamer-0%) (-minimal%*)" LINGUAS="fr -af -ar -as -ast -be -bg -bn_BD -bn_IN -br -bs -ca -cs -cy -da -de -el -en_GB -en_ZA -eo -es_AR -es_CL -es_ES -es_MX -et -eu -fa -fi -fy_NL -ga_IE -gd -gl -gu_IN -he -hi_IN -hr -hu -hy_AM -id -is -it -ja -kk -km -kn -ko -lt -lv -mai -mk -ml -mr -nb_NO -nl -nn_NO -or -pa_IN -pl -pt_BR -pt_PT -rm -ro -ru -si -sk -sl -son -sq -sr -sv_SE -ta -te -th -tr -uk -vi -xh -zh_CN -zh_TW"
Another noticeable difference between 45 and 46 is a major change to the build system. Its very possible the new build system needs an adjustment for system ldflags, somewhere. Thanks for reporting! FYI - bug 576922 almost certainly still applies to firefox-46 as well. Until the platform-specific stubs can be put im place for the Atomic ops, the generic defaults (which are just wrappers to MOZ_CRASH()) are going to be used. (In reply to Ian Stakenvicius from comment #4) > Another noticeable difference between 45 and 46 is a major change to the > build system. Its very possible the new build system needs an adjustment > for system ldflags, somewhere. Thanks for reporting! Just FYI, still failing with firefox-47.0, just in case changes were made to the new build system. > FYI - bug 576922 almost certainly still applies to firefox-46 as well. Until > the platform-specific stubs can be put im place for the Atomic ops, the > generic defaults (which are just wrappers to MOZ_CRASH()) are going to be > used. I'm not getting this point. Does it mean that upstream kill all arches but x86 and amd64 (and maybe arm)? Émeric (In reply to Émeric Maschino from comment #5) > > FYI - bug 576922 almost certainly still applies to firefox-46 as well. Until > > the platform-specific stubs can be put im place for the Atomic ops, the > > generic defaults (which are just wrappers to MOZ_CRASH()) are going to be > > used. > > I'm not getting this point. Does it mean that upstream kill all arches but > x86 and amd64 (and maybe arm)? > Yes, though ppc and ppc64 still work too. But technically they did that around firefox-10, it's just that it's been fairly easy to keep them on life support until now. All platforms need either a full jit implementation (and jit enabled), or -at least- the jit atomics implemented, if they are not going to crash by design at runtime. (In reply to Ian Stakenvicius from comment #6) > (In reply to Émeric Maschino from comment #5) > > I'm not getting this point. Does it mean that upstream kill all arches but > > x86 and amd64 (and maybe arm)? > > > > Yes, though ppc and ppc64 still work too. But technically they did that > around firefox-10, it's just that it's been fairly easy to keep them on life > support until now. > > All platforms need either a full jit implementation (and jit enabled), or > -at least- the jit atomics implemented, if they are not going to crash by > design at runtime. So, now that Firefox 38 ESR has been removed from portage, this means that several "exotic" arches are without a working web browser :-( Émeric (In reply to Émeric Maschino from comment #7) > (In reply to Ian Stakenvicius from comment #6) > > > > All platforms need either a full jit implementation (and jit enabled), or > > -at least- the jit atomics implemented, if they are not going to crash by > > design at runtime. > > So, now that Firefox 38 ESR has been removed from portage, this means that > several "exotic" arches are without a working web browser :-( > > Émeric OK I got the point and proposed patch for ia64 (see https://bugs.gentoo.org/show_bug.cgi?id=576922#c24). Back to original problem: Firefox 49 build is still crashing for the same reason. And LDFLAGS are still not honored, as I still can see both --as-needed and --no-as-needed passed to linker :-( Émeric (In reply to Émeric Maschino from comment #8) > > <snip> > > Back to original problem: Firefox 49 build is still crashing for the same > reason. And LDFLAGS are still not honored, as I still can see both > --as-needed and --no-as-needed passed to linker :-( > > Émeric Aha, that's interesting. From build.log, I can find: * Running elibtoolize in: firefox-49.0/ipc/chromium/src/third_party/libevent/ * Applying portage/1.2.0 patch ... * Applying sed/1.5.6 patch ... * Applying as-needed/2.4.2 patch ... <============ THIS * Applying target-nm/2.4.2 patch ... * Running elibtoolize in: firefox-49.0/js/src/ * Running elibtoolize in: firefox-49.0/js/src/ctypes/libffi/ * Applying portage/1.2.0 patch ... * Applying sed/1.5.6 patch ... * Applying as-needed/2.4.2 patch ... <============ THIS * Applying target-nm/2.4.2 patch ... * Running elibtoolize in: firefox-49.0/memory/jemalloc/src/ * Running elibtoolize in: firefox-49.0/modules/freetype2/ * Running elibtoolize in: firefox-49.0/modules/freetype2/builds/unix/ * Applying portage/1.2.0 patch ... * Applying sed/1.5.6 patch ... * Applying as-needed/2.4.3 patch ... <============ THIS * Running elibtoolize in: firefox-49.0/nsprpub/ * Running elibtoolize in: firefox-49.0/python/mozbuild/mozbuild/ * Running elibtoolize in: firefox-49.0/python/mozbuild/mozbuild/test/ * Running elibtoolize in: firefox-49.0/toolkit/crashreporter/google-breakpad/ * Running elibtoolize in: firefox-49.0/toolkit/crashreporter/google-breakpad/akpat/autotools/ * Applying portage/2.2 patch ... * Applying sed/1.5.6 patch ... * Applying as-needed/2.2.6 patch ... <============ THIS What are all these as-needed patches? Where do they come from? Could they be the reason why --as-needed flag is always passed to ld? Émeric (In reply to Émeric Maschino from comment #9) > (In reply to Émeric Maschino from comment #8) > > > > <snip> > > > > Back to original problem: Firefox 49 build is still crashing for the same > > reason. And LDFLAGS are still not honored, as I still can see both > > --as-needed and --no-as-needed passed to linker :-( > > > > Émeric > > Aha, that's interesting. From build.log, I can find: > > * Running elibtoolize in: > firefox-49.0/ipc/chromium/src/third_party/libevent/ > * Applying portage/1.2.0 patch ... > * Applying sed/1.5.6 patch ... > * Applying as-needed/2.4.2 patch ... <============ THIS > * Applying target-nm/2.4.2 patch ... > * Running elibtoolize in: firefox-49.0/js/src/ > * Running elibtoolize in: firefox-49.0/js/src/ctypes/libffi/ > * Applying portage/1.2.0 patch ... > * Applying sed/1.5.6 patch ... > * Applying as-needed/2.4.2 patch ... <============ THIS > * Applying target-nm/2.4.2 patch ... > * Running elibtoolize in: firefox-49.0/memory/jemalloc/src/ > * Running elibtoolize in: firefox-49.0/modules/freetype2/ > * Running elibtoolize in: firefox-49.0/modules/freetype2/builds/unix/ > * Applying portage/1.2.0 patch ... > * Applying sed/1.5.6 patch ... > * Applying as-needed/2.4.3 patch ... <============ THIS > * Running elibtoolize in: firefox-49.0/nsprpub/ > * Running elibtoolize in: firefox-49.0/python/mozbuild/mozbuild/ > * Running elibtoolize in: firefox-49.0/python/mozbuild/mozbuild/test/ > * Running elibtoolize in: > firefox-49.0/toolkit/crashreporter/google-breakpad/ > * Running elibtoolize in: > firefox-49.0/toolkit/crashreporter/google-breakpad/akpat/autotools/ > * Applying portage/2.2 patch ... > * Applying sed/1.5.6 patch ... > * Applying as-needed/2.2.6 patch ... <============ THIS > > What are all these as-needed patches? Where do they come from? Could they be > the reason why --as-needed flag is always passed to ld? > > Émeric So what you're referring to now is a toolchain / autotools issue. I would expect that if this were a real issue you would be having these problems everywhere though, not just with firefox and other mozilla products. I don't know what that patch is off-hand but I expect it's some adjustment to autotools files that makes it honour --as-needed instead of stripping it or overriding it. Do you have a build.log from firefox-49 that you can attach for me? Created attachment 453196 [details]
bzip2-compressed build.log for Firefox 49
(In reply to Ian Stakenvicius from comment #11) > Do you have a build.log from firefox-49 that you can attach for me? Sure. Please have a look at attachment 453196 [details]. Émeric (In reply to Émeric Maschino from comment #13) > (In reply to Ian Stakenvicius from comment #11) > > Do you have a build.log from firefox-49 that you can attach for me? > > Sure. Please have a look at attachment 453196 [details]. > > Émeric OK, so let's compare your build.log to mine for a bit. The python-wrapper command on the mozgtk_stub link (which is the one that is failing) is on yours: /var/tmp/portage/www-client/firefox-49.0/work/firefox-49.0/ff/_virtualenv/bin/python /var/tmp/portage/www-client/firefox-49.0/wo rk/firefox-49.0/config/expandlibs_exec.py --uselist -- /usr/bin/ia64-unknown-linux-gnu-g++ -std=gnu++11 -Wall -Wc++11-compat - Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-st rings -Wno-invalid-offsetof -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -pipe -mtu ne=itanium2 -fPIC -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -pthread -pipe -O2 -fomit-fram e-pointer -fPIC -shared -Wl,-z,defs -Wl,-h,libmozgtk.so -o libmozgtk.so mozgtk.o -lpthread -Wl,-O1 -Wl,-rpath=/usr/lib/firef ox,--enable-new-dtags -Wl,-z,noexecstack -Wl,-z,text -Wl,-rpath-link,/var/tmp/portage/www-client/firefox-49.0/work/firefox-49. 0/ff/dist/bin -Wl,-rpath-link,/usr/lib -ldl -Wl,--no-as-needed -lgtk-3 -lgdk-3 -Wl,--as-needed ...and on mine (amd64): /var/tmp/portage/www-client/firefox-49.0/work/firefox-49.0/ff/_virtualenv/bin/python /var/tmp/portage/www-client/firefox-49.0/work/firefox-49.0/config/expandlibs_exec.py --uselist -- /usr/lib64/distcc/bin/x86_64-pc-linux-gnu-g++ -std=gnu++11 -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -march=sandybridge -mtune=generic -pipe -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -pthread -pipe -freorder-blocks -Os -fomit-frame-pointer -fPIC -shared -Wl,-z,defs -Wl,-h,libmozgtk.so -o libmozgtk_stub.so mozgtk.o -lpthread -Wl,-O1 -Wl,--no-as-needed -Wl,-rpath=/usr/lib64/firefox,--enable-new-dtags -Wl,-z,noexecstack -Wl,-z,text -Wl,-rpath-link,/var/tmp/portage/www-client/firefox-49.0/work/firefox-49.0/ff/dist/bin -Wl,-rpath-link,/usr/lib -ldl Note that on yours, you have a whole extra "-Wl,--no-as-needed -lgtk-3 -lgdk-3 -Wl,--as-needed" portion. I think it's the addition of this that is causing the issue. Not sure where it's coming from yet. (In reply to Ian Stakenvicius from comment #14) > > OK, so let's compare your build.log to mine for a bit. The python-wrapper > command on the mozgtk_stub link (which is the one that is failing) is on > yours: > > <snip> > > Note that on yours, you have a whole extra "-Wl,--no-as-needed -lgtk-3 > -lgdk-3 -Wl,--as-needed" portion. I think it's the addition of this that is > causing the issue. Not sure where it's coming from yet. Wait a minute, where do these --no-as-needed and --as-needed come from? Indeed, my LDFLAGS simply inherit the ia64 default ones, i.e. "-Wl,-O1", so no --no-as-needed nor --as-needed there. So, you're right, I simply don't know where they come from! I've also noticed --no-as-needed being passed on your python-wrapper command. Do you pass it on purpose to LDFLAGS or is it also magically added somewhere? While we're talking about mozgtk_stub, did you noticed that the output name is different on ia64? The python-wrapper command says -o libmozgtk.so whereas your amd64 output is -o libmozgtk_stub.so. In fact, there's no such mozgtk_stub on ia64. Could this be an issue too? About the additional -lgtk-3 -lgdk-3 flags, well, they seem to come from MOZ_GTK3_LIBS variable. Émeric (In reply to Émeric Maschino from comment #15) > (In reply to Ian Stakenvicius from comment #14) > > > > OK, so let's compare your build.log to mine for a bit. The python-wrapper > > command on the mozgtk_stub link (which is the one that is failing) is on > > yours: > > > > <snip> > > > > Note that on yours, you have a whole extra "-Wl,--no-as-needed -lgtk-3 > > -lgdk-3 -Wl,--as-needed" portion. I think it's the addition of this that is > > causing the issue. Not sure where it's coming from yet. > > Wait a minute, where do these --no-as-needed and --as-needed come from? > Indeed, my LDFLAGS simply inherit the ia64 default ones, i.e. "-Wl,-O1", so > no --no-as-needed nor --as-needed there. So, you're right, I simply don't > know where they come from! > I've also noticed --no-as-needed being passed on > your python-wrapper command. Do you pass it on purpose to LDFLAGS or is it > also magically added somewhere? I adjusted my LDFLAGS to match yours, in make.conf, before running my build. > While we're talking about mozgtk_stub, did you noticed that the output name > is different on ia64? The python-wrapper command says -o libmozgtk.so > whereas your amd64 output is -o libmozgtk_stub.so. In fact, there's no such > mozgtk_stub on ia64. Could this be an issue too? > > About the additional -lgtk-3 -lgdk-3 flags, well, they seem to come from > MOZ_GTK3_LIBS variable. So both of these might interrelate -- if on ia64 the code is for some reason building a quasi-bundled libmozgtk, rather than building a stub that links to the whole system-installed gtk+-3.x et. al. package, then I'm going to guess that the mozilla build system itself is adding the -Wl,--no-as-needed + -W,--as-needed wrappers around MOZ_GTK3_LIBS. Time to check ./configure's log (In reply to Ian Stakenvicius from comment #16) > > I adjusted my LDFLAGS to match yours, in make.conf, before running my build. OK. > So both of these might interrelate -- if on ia64 the code is for some reason > building a quasi-bundled libmozgtk, rather than building a stub that links > to the whole system-installed gtk+-3.x et. al. package, then I'm going to > guess that the mozilla build system itself is adding the -Wl,--no-as-needed > + -W,--as-needed wrappers around MOZ_GTK3_LIBS. Time to check ./configure's > log Bingo! Have a look at ${S}/widget/gtk/mozgtk/gtk3/moz.build I bet that you don't see this on amd64 as you're using gold as linker, whereas ia64 uses ld, right? Émeric (In reply to Émeric Maschino from comment #17) > (In reply to Ian Stakenvicius from comment #16) > > > > I adjusted my LDFLAGS to match yours, in make.conf, before running my build. > > OK. > > > So both of these might interrelate -- if on ia64 the code is for some reason > > building a quasi-bundled libmozgtk, rather than building a stub that links > > to the whole system-installed gtk+-3.x et. al. package, then I'm going to > > guess that the mozilla build system itself is adding the -Wl,--no-as-needed > > + -W,--as-needed wrappers around MOZ_GTK3_LIBS. Time to check ./configure's > > log > > Bingo! Have a look at ${S}/widget/gtk/mozgtk/gtk3/moz.build > > I bet that you don't see this on amd64 as you're using gold as linker, > whereas ia64 uses ld, right? > > Émeric I used ld.bfd on this build too, so there shouldn't be any ld.bfd vs ld.gold issues... So that file is absolutely where it's getting introduced. I was, however, wrong about the relevant line of code in my build.log, we should be comparing with this one: /var/tmp/portage/www-client/firefox-49.0/work/firefox-49.0/ff/_virtualenv/bin/python /var/tmp/portage/www-client/firefox-49.0/work/firefox-49.0/config/expandlibs_exec.py --uselist -- /usr/lib64/distcc/bin/x86_64-pc-linux-gnu-g++ -std=gnu++11 -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -march=sandybridge -mtune=generic -pipe -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -pthread -pipe -freorder-blocks -Os -fomit-frame-pointer -fPIC -shared -Wl,-z,defs -Wl,-h,libmozgtk.so -o libmozgtk.so mozgtk.o -lpthread -Wl,-O1 -Wl,--no-as-needed -Wl,-rpath=/usr/lib64/firefox,--enable-new-dtags -Wl,-z,noexecstack -Wl,-z,text -Wl,-rpath-link,/var/tmp/portage/www-client/firefox-49.0/work/firefox-49.0/ff/dist/bin -Wl,-rpath-link,/usr/lib -ldl -Wl,--no-as-needed -lgtk-3 -lgdk-3 -Wl,--as-needed ..where I do in fact have the exact same last few arguments as you do. It's worth noting, also, that the build doesn't fail when the gtk2 version of libmozgtk.so is built, which uses the exact same -Wl,--no-as-needed + -Wl,--as-needed pattern. This is from your build.log, a few hundred lines earlier: /var/tmp/portage/www-client/firefox-49.0/work/firefox-49.0/ff/_virtualenv/bin/python /var/tmp/portage/www-client/firefox-49.0/work/firefox-49.0/config/expandlibs_exec.py --uselist -- /usr/bin/ia64-unknown-linux-gnu-g++ -std=gnu++11 -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -pipe -mtune=itanium2 -fPIC -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -pthread -pipe -O2 -fomit-frame-pointer -fPIC -shared -Wl,-z,defs -Wl,-h,libmozgtk.so -o libmozgtk.so mozgtk.o -lpthread -Wl,-O1 -Wl,-rpath=/usr/lib/firefox,--enable-new-dtags -Wl,-z,noexecstack -Wl,-z,text -Wl,-rpath-link,/var/tmp/portage/www-client/firefox-49.0/work/firefox-49.0/ff/dist/bin -Wl,-rpath-link,/usr/lib -ldl -Wl,--no-as-needed -lgtk-x11-2.0 -lgdk-x11-2.0 -Wl,--as-needed [...] chmod +x libmozgtk.so ../../../../config/nsinstall -R -m 644 'libmozgtk.so' '../../../../dist/bin/gtk2' make[4]: Leaving directory '/var/tmp/portage/www-client/firefox-49.0/work/firefox-49.0/ff/widget/gtk/mozgtk/gtk2' So just out of curiosity, what happens if you set your LDFLAGS="-Wl,-O1 -Wl,--as-needed" globally when you build firefox on ia64? Is it absolutely needed on this platform for linking for some reason? (In reply to Ian Stakenvicius from comment #18) > I used ld.bfd on this build too, so there shouldn't be any ld.bfd vs ld.gold > issues... OK. > So that file is absolutely where it's getting introduced. Yes. There's a symmetric one for GTK2. > <snip> > > So just out of curiosity, what happens if you set your LDFLAGS="-Wl,-O1 > -Wl,--as-needed" globally when you build firefox on ia64? Is it absolutely > needed on this platform for linking for some reason? Well, it'll probably make ld segfaulting, as the problem comes from --as-needed flag, not --no-as-needed. In fact, some times ago, ia64's LDFLAGS were matching Linux's default one in /usr/portage/profiles/default/linux/make.defaults, i.e. LDFLAGS="-Wl,-O1 -Wl,--as-needed". But we were having a few (but important) packages failing to link. It was later found (@vapier?) that ld was segfaulting because of --as-needed LDFLAGS. Hence the reason ia64's LDFLAGS were redefined (@pacho?) in /usr/portage/profiles/default/linux/ia64/make.defaults, dropping --as-needed flag from the default ones, i.e. LDFLAGS="-Wl,-O1". It's noteworthy that before this change, most packages didn't have problem linking with --as-needed. That's probably why mozgtk's gtk2 variant is linking flawlessly. All this to say that, when ld is segfaulting on ia64, a known workaround is not to pass --as-needed, or passing --no-as-needed to overcome --as-needed if it was passed previously. This solves the problem most of the time, unless ld is segfaulting for yet another reason but I don't remember having seen such a scenario. Here, problem is that moz.build forcibly adds --as-needed at the end of python-wrapper command, thus cancelling any previous --no-as-needed (introduced by Firefox build scripts or inherited from global LDFLAGS) and then resulting in a ld crash. Émeric (In reply to Émeric Maschino from comment #19) > But we were having a few (but important) packages failing to link. It was > later found (@vapier?) that ld was segfaulting because of --as-needed > LDFLAGS. Where it all started: https://bugs.gentoo.org/show_bug.cgi?id=541828#c8 > Hence the reason ia64's LDFLAGS were redefined (@pacho?) in > /usr/portage/profiles/default/linux/ia64/make.defaults, dropping --as-needed > flag from the default ones, i.e. LDFLAGS="-Wl,-O1". https://bugs.gentoo.org/show_bug.cgi?id=541828#c11 Émeric (In reply to Émeric Maschino from comment #20) > (In reply to Émeric Maschino from comment #19) > > But we were having a few (but important) packages failing to link. It was > > later found (@vapier?) that ld was segfaulting because of --as-needed > > LDFLAGS. > > Where it all started: https://bugs.gentoo.org/show_bug.cgi?id=541828#c8 > > > Hence the reason ia64's LDFLAGS were redefined (@pacho?) in > > /usr/portage/profiles/default/linux/ia64/make.defaults, dropping --as-needed > > flag from the default ones, i.e. LDFLAGS="-Wl,-O1". > > https://bugs.gentoo.org/show_bug.cgi?id=541828#c11 > > Émeric Thanks for the background! OK, so it seems the most viable solution here will be to patch the moz.build for ia64 to remove both the --no-as-needed and --as-needed wrappings. I don' like conditional patching but it seems necessary in this case. Please try the following and let me know if you have better luck? Created attachment 453338 [details, diff]
patch to remove --as-needed wrappers to gtk libs in mozgtk
(In reply to Ian Stakenvicius from comment #22) > Created attachment 453338 [details, diff] [details, diff] > patch to remove --as-needed wrappers to gtk libs in mozgtk Build flawlessly with the above patch. As expected ;-) Émeric (In reply to Émeric Maschino from comment #23) > (In reply to Ian Stakenvicius from comment #22) > > Created attachment 453338 [details, diff] [details, diff] [details, diff] > > patch to remove --as-needed wrappers to gtk libs in mozgtk > > Build flawlessly with the above patch. As expected ;-) > > Émeric Perfect. I'll work on a version of this patch that doesn't need to be applied quite so conditionally on ia64 and integrate it (and the ion patches) into firefox-50 for testing. If you feel I have closed your bug and it is still a current issue, please reopen and update it completely. We will not work bugs that have no ebuild in tree any longer or can not be reproduced with a current system. Thank You for your support and understanding The Mozilla Team |
