nightly 20170302 compile fails OSPreferences_gtk.o: requires dynamic R_X86_64_PC32 reloc against 'g_settings_new' which may overflow at runtime; recompile with -fPIC

RESOLVED FIXED in Firefox 55

Status

defect
RESOLVED FIXED
3 years ago
8 months ago

People

(Reporter: stanl-mozilla, Assigned: glandium)

Tracking

54 Branch
mozilla55
Dependency tree / graph

Firefox Tracking Flags

(firefox55 fixed)

Details

Attachments

(6 attachments)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170301153019

Steps to reproduce:

Updated local hg repository.  Compiled nightly.


Actual results:

35:35.77     INPUT("StaticXULComponentsEnd/StaticXULComponentsEnd.o")
35:35.77 
35:35.77 ../../build/unix/gold/ld: error: /mnt/to_archive/accum/src/mozilla-central/obj-x86_64-pc-linux-gnu/toolkit/library/../../intl/locale/gtk/OSPreferences_gtk.o: requires dynamic R_X86_64_PC32 reloc against 'g_settings_new' which may overflow at runtime; recompile with -fPIC
35:35.77 ../../build/unix/gold/ld: error: read-only segment has dynamic relocations
35:35.77 ../../build/unix/gold/ld: error: hidden symbol 'g_settings_new' is not defined locally
35:35.77 ../../build/unix/gold/ld: error: hidden symbol 'g_settings_get_value' is not defined locally
35:35.77 collect2: error: ld returned 1 exit status


Expected results:

PASS
PASS
nightly 20170301 compiled and is running fine.  So it is something in today's update.
Component: Untriaged → Build Config
The changeset that caused the problem is 

$ hg log -v -r 345499
changeset:   345499:0fb088fb7d66
user:        Zibi Braniecki <gandalf@mozilla.com>
date:        Wed Feb 08 17:17:51 2017 -0800
files:       intl/build/nsI18nModule.cpp intl/locale/OSPreferences.cpp intl/locale/OSPreferences.h intl/locale/gtk/OSPreferences_gtk.cpp intl/locale/gtk/moz.build intl/locale/mac/OSPreferences_mac.cpp intl/locale/moz.build intl/locale/moz
description:
Bug 1308329 - Extend OSPreferences API to cover date/time styles. r=jfkthame

MozReview-Commit-ID: HnuWfS8UEDH
Posted file mozconfig
Please note that recompiling with -fPIC (as recommended in the helpful error message) has no effect on this issue: the same errors happen - unless I'm doing it wrong, of course.

Thanks @stan for pointing out the changeset. Is there any workaround? I'll try to figure out one.

I am including my mozconfig, too.


...
86:54.02     INPUT("../../memory/fallible/fallible.o")
86:54.02     INPUT("../../media/psshparser/Unified_cpp_media_psshparser0.o")
86:54.02     INPUT("StaticXULComponentsEnd/StaticXULComponentsEnd.o")
86:54.02 
86:54.02 ../../build/unix/gold/ld: error: /tmp/obj-x86_64-pc-linux-gnu/toolkit/library/../../intl/locale/gtk/OSPreferences_gtk.o: requires dynamic R_X86_64_PC32 reloc against 'g_settings_new' which may overflow at runtime; recompile with -fPIC
86:54.02 ../../build/unix/gold/ld: error: read-only segment has dynamic relocations
86:54.02 ../../build/unix/gold/ld: error: hidden symbol 'g_settings_new' is not defined locally
86:54.02 ../../build/unix/gold/ld: error: hidden symbol 'g_settings_get_value' is not defined locally
86:54.02 collect2: error: ld returned 1 exit status
86:54.02 make[5]: *** [/home/xftroxgpx/build/1packages/firefox-hg/makepkg_pacman/firefox-hg/src/firefox-hg/config/rules.mk:806: libxul.so] Error 1
86:54.03 make[5]: Leaving directory '/tmp/obj-x86_64-pc-linux-gnu/toolkit/library'
86:54.03 make[4]: *** [/home/xftroxgpx/build/1packages/firefox-hg/makepkg_pacman/firefox-hg/src/firefox-hg/config/recurse.mk:71: toolkit/library/target] Error 2
86:54.03 make[4]: Leaving directory '/tmp/obj-x86_64-pc-linux-gnu'
86:54.03 make[3]: *** [/home/xftroxgpx/build/1packages/firefox-hg/makepkg_pacman/firefox-hg/src/firefox-hg/config/recurse.mk:33: compile] Error 2
86:54.03 make[3]: Leaving directory '/tmp/obj-x86_64-pc-linux-gnu'
86:54.03 make[2]: *** [/home/xftroxgpx/build/1packages/firefox-hg/makepkg_pacman/firefox-hg/src/firefox-hg/config/rules.mk:525: default] Error 2
86:54.03 make[2]: Leaving directory '/tmp/obj-x86_64-pc-linux-gnu'
86:54.03 make[1]: *** [/home/xftroxgpx/build/1packages/firefox-hg/makepkg_pacman/firefox-hg/src/firefox-hg/client.mk:419: realbuild] Error 2
86:54.03 make[1]: Leaving directory '/home/xftroxgpx/build/1packages/firefox-hg/makepkg_pacman/firefox-hg/src/firefox-hg'
86:54.03 make: *** [client.mk:170: build] Error 2
86:54.06 0 compiler warnings present.
I'm not sure about a workaround.  I imagine that backing out this changeset would allow the compile to complete, if there has been nothing added that depends on the changeset.

And in this ticket, https://bugzilla.mozilla.org/show_bug.cgi?id=1332788, the reporter says he got his nightly to compile with a similar error by turning off something called PGO.  Like you, he found that -fpic didn't help.
You're building with --disable-gio, and bug 1308329 added an unconditional dependency on gio...
Blocks: 1308329
Flags: needinfo?(gandalf)
I wasn't aware the gio is conditional.

:jfkthame, should we just ifdef in OSPreferences_gtk?
Flags: needinfo?(gandalf) → needinfo?(jfkthame)
Another option is to remove the option to disable gio. I'm not convinced it's useful anymore, especially now that the gnomevfs code is gone. Karl, thoughts?
Flags: needinfo?(karlt)
Yes, removing the --disable-gio option would make sense now that the build depends on GTK versions that depend on GIO and GLib versions that have GIO, anyway.
Flags: needinfo?(karlt)
Confirmed: firefox compiles & works ok with --enable-gio and fails to compile(just like in OP) with --disable-gio
I tested by bringing repo up to date once, then cleaning the out dir /tmp/obj-x86_64-pc-linux-gnu/ before each compile.

Thanks all! Your knowledge is much appreciated!
Also confirmed.  If I comment the --disable-gio, nightly compiles just fine.  Thanks for the solution.
Assignee: nobody → mh+mozilla
Flags: needinfo?(jfkthame)
Comment on attachment 8844806 [details]
Bug 1344038 - Move the gio protocol handler under netwerk/protocol.

https://reviewboard.mozilla.org/r/118128/#review121250

Thanks!  r+ if you are happy with s/MOZ_GTK/MOZ_WIDGET_GTK/

::: extensions/gio/moz.build:13
(Diff revision 1)
>      'nsGIOProtocolHandler.cpp',
>  ]
>  
>  FINAL_LIBRARY = 'xul'
>  
> -CXXFLAGS += CONFIG['MOZ_GIO_CFLAGS']
> +CXXFLAGS += CONFIG['GLIB_CFLAGS']

GIO has its own gio-2.0 pkgconfig, so strictly it could add its own cflags, but it doesn't in the version I checked.  TK_CFLAGS may be better because that will include gio flags, but it probably doesn't matter.

::: netwerk/base/nsIOService.cpp:545
(Diff revision 1)
>          if (NS_SUCCEEDED(rv)) {
>              CacheProtocolHandler(scheme, *result);
>              return rv;
>          }
>  
> -#ifdef MOZ_ENABLE_GIO
> +#ifdef MOZ_GTK

I don't think MOZ_GTK is defined for this file.
(There are some specific defines for some files.)
MOZ_WIDGET_GTK is my best suggestion.

::: toolkit/components/downloads/nsDownloadManager.cpp:2651
(Diff revision 1)
>    // This will be used later to query the application reputation service.
>    mRedirects = aRedirects;
>    return NS_OK;
>  }
>  
> -#ifdef MOZ_ENABLE_GIO
> +#ifdef MOZ_GTK

MOZ_WIDGET_GTK

::: toolkit/components/downloads/nsDownloadManager.cpp:2820
(Diff revision 1)
>                g_free(uri);
>              }
>  #endif
>            }
>  #endif
> -#ifdef MOZ_ENABLE_GIO
> +#ifdef MOZ_GTK

"

::: toolkit/components/jsdownloads/src/DownloadPlatform.cpp:62
(Diff revision 1)
>  #endif
>  
>    return gDownloadPlatformService;
>  }
>  
> -#ifdef MOZ_ENABLE_GIO
> +#ifdef MOZ_GTK

"

::: toolkit/components/jsdownloads/src/DownloadPlatform.cpp:134
(Diff revision 1)
>            g_free(uri);
>          }
>  #endif
>        }
>  #endif
> -#ifdef MOZ_ENABLE_GIO
> +#ifdef MOZ_GTK

"
Attachment #8844806 - Flags: review?(karlt) → review+
Comment on attachment 8844806 [details]
Bug 1344038 - Move the gio protocol handler under netwerk/protocol.

https://reviewboard.mozilla.org/r/118128/#review121254

::: old-configure.in:3545
(Diff revision 1)
>  if test `echo "$MOZ_EXTENSIONS" | grep -c gio` -ne 0; then
> -    MOZ_GIO_COMPONENT=1
>      MOZ_EXTENSIONS=`echo $MOZ_EXTENSIONS | sed -e 's|gio||'`
>  fi

Hmmm.  This is dropping support for disabling the gio protocol handling extension.

Perhaps it is better to leave MOZ_GIO_COMPONENT as is, here and in toolkit.mozbuild, for tor browser, if they use that, or may want to do that.

If you are keen to remove this option, then please remove gio from the list of extensions (in browser IIRC).
Comment on attachment 8844807 [details]
Bug 1344038 - Remove --disable-gio.

https://reviewboard.mozilla.org/r/118130/#review121252

::: commit-message-a6ca3:1
(Diff revision 1)
> +Bug 1344038 - Remove --disable-gnomeui. r?karlt

"Remove --enable-gnomeui" would be slightly more descriptive.
Attachment #8844807 - Flags: review?(karlt) → review+
(In reply to Karl Tomlinson (:karlt) from comment #14)
> Comment on attachment 8844806 [details]
> Bug 1344038 - Remove --disable-gio.
> 
> https://reviewboard.mozilla.org/r/118128/#review121254
> 
> ::: old-configure.in:3545
> (Diff revision 1)
> >  if test `echo "$MOZ_EXTENSIONS" | grep -c gio` -ne 0; then
> > -    MOZ_GIO_COMPONENT=1
> >      MOZ_EXTENSIONS=`echo $MOZ_EXTENSIONS | sed -e 's|gio||'`
> >  fi
> 
> Hmmm.  This is dropping support for disabling the gio protocol handling
> extension.
> 
> Perhaps it is better to leave MOZ_GIO_COMPONENT as is, here and in
> toolkit.mozbuild, for tor browser, if they use that, or may want to do that.
> 
> If you are keen to remove this option, then please remove gio from the list
> of extensions (in browser IIRC).

Well, if we remove --disable-gio, there's no reason to keep --with-extensions=-gio working is there?
So, I was thinking, since gio is not really handled like a MOZ_EXTENSION already, and since this bug won't allow to disable it, I was thinking, how about moving it out of the extensions/ directory? The logical place for it would be under netwerk/protocol, but ironically, that would make it disableable again through --enable-network-protocols=-gio.

Karl, do you have any thought?
Flags: needinfo?(karlt)
(In reply to Mike Hommey [:glandium] from comment #16)
> (In reply to Karl Tomlinson (:karlt) from comment #14)
> > extension.
> > 
> > Perhaps it is better to leave MOZ_GIO_COMPONENT as is, here and in
> > toolkit.mozbuild, for tor browser, if they use that, or may want to do that.
> > 
> > If you are keen to remove this option, then please remove gio from the list
> > of extensions (in browser IIRC).
> 
> Well, if we remove --disable-gio, there's no reason to keep
> --with-extensions=-gio working is there?

I have always thought of the gio protocol handling as an extra feature.
--enable/disable-gio was mainly intended for choosing the implementation of
features.  The gio handler was a gio implementation of the gnomevfs protocol handler iirc.

There was previously separate configuration available for the protocol handlers, while still having a dependency on the --enable-gio option.

I don't know whether or not there is a need to be able to disable the gio
protocol handler, but it does seem to be something that is not core browser
functionality.

(In reply to Mike Hommey [:glandium] from comment #17)
> So, I was thinking, since gio is not really handled like a MOZ_EXTENSION
> already, and since this bug won't allow to disable it, I was thinking, how
> about moving it out of the extensions/ directory? The logical place for it
> would be under netwerk/protocol, but ironically, that would make it
> disableable again through --enable-network-protocols=-gio.
> 
> Karl, do you have any thought?

Putting it under netwerk/protocol sound great to me.  That location would make
much more sense.

This may have been implemented as an extension only so that it didn't add
runtime library dependencies, and that is no longer an issue.
Flags: needinfo?(karlt)
Comment on attachment 8844806 [details]
Bug 1344038 - Move the gio protocol handler under netwerk/protocol.

Patrick, f?'ing you as module owner on netwerk/, where the code is being moved to. Please note that the corresponding moz.build contains:

with Files('**'):
    BUG_COMPONENT = ('Core', 'Widget: Gtk')
Attachment #8844806 - Flags: review?(karlt)
Attachment #8844806 - Flags: review+
Attachment #8844806 - Flags: feedback?(mcmanus)
Attachment #8844807 - Flags: review+ → review?(karlt)
Comment on attachment 8844806 [details]
Bug 1344038 - Move the gio protocol handler under netwerk/protocol.

ok by me
Attachment #8844806 - Flags: feedback?(mcmanus) → feedback+
Comment on attachment 8844806 [details]
Bug 1344038 - Move the gio protocol handler under netwerk/protocol.

https://reviewboard.mozilla.org/r/118128/#review129720

Thanks!
Attachment #8844806 - Flags: review?(karlt) → review+
Comment on attachment 8844807 [details]
Bug 1344038 - Remove --disable-gio.

https://reviewboard.mozilla.org/r/118130/#review129736
Attachment #8844807 - Flags: review?(karlt) → review+
Comment on attachment 8854697 [details]
Bug 1344038 - Remove --enable-gnomeui.

https://reviewboard.mozilla.org/r/126648/#review129738
Attachment #8854697 - Flags: review?(karlt) → review+
Pushed by mh@glandium.org:
https://hg.mozilla.org/integration/autoland/rev/5d28a6382285
Move the gio protocol handler under netwerk/protocol. r=karlt
https://hg.mozilla.org/integration/autoland/rev/c859506b2e4e
Remove --disable-gio. r=karlt
https://hg.mozilla.org/integration/autoland/rev/4befea89d81b
Remove --enable-gnomeui. r=karlt
Comment on attachment 8844806 [details]
Bug 1344038 - Move the gio protocol handler under netwerk/protocol.

Was missing the part that disables the protocol handler on non-Gtk builds... Chris, can you review the toolkit/moz.configure part?
Flags: needinfo?(mh+mozilla)
Attachment #8844806 - Flags: review?(cmanchester)
Comment on attachment 8844806 [details]
Bug 1344038 - Move the gio protocol handler under netwerk/protocol.

Note that I filed bug 1353993 for the --help dependency.
Attachment #8844806 - Flags: review?(cmanchester)
Comment on attachment 8844806 [details]
Bug 1344038 - Move the gio protocol handler under netwerk/protocol.

https://reviewboard.mozilla.org/r/118128/#review130074
Attachment #8844806 - Flags: review?(cmanchester) → review+
Pushed by mh@glandium.org:
https://hg.mozilla.org/integration/autoland/rev/7ad4be04d16e
Move the gio protocol handler under netwerk/protocol. r=chmanchester,karlt
https://hg.mozilla.org/integration/autoland/rev/91f503f83851
Remove --disable-gio. r=karlt
https://hg.mozilla.org/integration/autoland/rev/5fbd12b4d8e7
Remove --enable-gnomeui. r=karlt
https://hg.mozilla.org/mozilla-central/rev/7ad4be04d16e
https://hg.mozilla.org/mozilla-central/rev/91f503f83851
https://hg.mozilla.org/mozilla-central/rev/5fbd12b4d8e7
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 55
Got another (new) one and I forgot how to fix it. Need a lil help, please.

18:17.44 ../../build/unix/gold/ld: error: /tmp/obj-x86_64-pc-linux-gnu/toolkit/library/../../gfx/sfntly/cpp/src/Unified_cpp_gfx_sfntly_cpp_src0.o: requires dynamic R_X86_64_PC32 reloc against '_ZN6icu_5911StringPieceC1EPKc' which may overflow at runtime; recompile with -fPIC
18:17.44 ../../build/unix/gold/ld: error: /tmp/obj-x86_64-pc-linux-gnu/toolkit/library/../../gfx/sfntly/cpp/src/Unified_cpp_gfx_sfntly_cpp_src0.o: requires dynamic R_X86_64_PC32 reloc against '_ZNK6icu_5913UnicodeString13doCaseCompareEiiPKDsiij' which may overflow at runtime; recompile with -fPIC
18:17.44 ../../build/unix/gold/ld: error: /tmp/obj-x86_64-pc-linux-gnu/toolkit/library/../../gfx/sfntly/cpp/src/Unified_cpp_gfx_sfntly_cpp_src0.o: requires dynamic R_X86_64_PC32 reloc against '_ZN6icu_5913UnicodeString8doAppendERKS0_ii' which may overflow at runtime; recompile with -fPIC
18:17.45 ../../build/unix/gold/ld: error: /tmp/obj-x86_64-pc-linux-gnu/toolkit/library/../../gfx/sfntly/cpp/src/Unified_cpp_gfx_sfntly_cpp_src0.o: requires dynamic R_X86_64_PC32 reloc against '_ZN6icu_5913UnicodeStringD1Ev' which may overflow at runtime; recompile with -fPIC
18:17.45 ../../build/unix/gold/ld: error: read-only segment has dynamic relocations
18:17.45 ../../build/unix/gold/ld: error: hidden symbol '_ZN6icu_5911StringPieceC1EPKc' is not defined locally
18:17.45 ../../build/unix/gold/ld: error: hidden symbol '_ZN6icu_5913UnicodeString8fromUTF8ENS_11StringPieceE' is not defined locally
18:17.45 ../../build/unix/gold/ld: error: hidden symbol '_ZN6icu_5911StringPieceC1EPKc' is not defined locally
18:17.45 ../../build/unix/gold/ld: error: hidden symbol '_ZN6icu_5913UnicodeString8fromUTF8ENS_11StringPieceE' is not defined locally
18:17.45 ../../build/unix/gold/ld: error: hidden symbol '_ZN6icu_5913UnicodeStringC1ERKS0_' is not defined locally
18:17.45 ../../build/unix/gold/ld: error: hidden symbol '_ZTVN6icu_5913UnicodeStringE' is not defined locally
18:17.45 ../../build/unix/gold/ld: error: hidden symbol '_ZN6icu_5913UnicodeStringC1EPKDs' is not defined locally
18:17.45 ../../build/unix/gold/ld: error: hidden symbol '_ZN6icu_5913UnicodeString8moveFromERS0_' is not defined locally
18:17.45 ../../build/unix/gold/ld: error: hidden symbol '_ZN6icu_5913UnicodeStringC1ERKS0_' is not defined locally
18:17.45 ../../build/unix/gold/ld: error: hidden symbol '_ZN6icu_5913UnicodeStringC1EPKDs' is not defined locally
18:17.45 ../../build/unix/gold/ld: error: hidden symbol '_ZN6icu_5913UnicodeString8moveFromERS0_' is not defined locally
18:17.45 ../../build/unix/gold/ld: error: hidden symbol '_ZN6icu_5913UnicodeStringD1Ev' is not defined locally
18:17.45 ../../build/unix/gold/ld: error: hidden symbol '_ZN6icu_5913UnicodeStringC1EPKDs' is not defined locally
18:17.45 ../../build/unix/gold/ld: error: hidden symbol '_ZN6icu_5913UnicodeStringD1Ev' is not defined locally
18:17.45 ../../build/unix/gold/ld: error: hidden symbol '_ZN6icu_5913UnicodeStringD1Ev' is not defined locally
18:17.45 ../../build/unix/gold/ld: error: hidden symbol '_ZN6icu_5913UnicodeStringD1Ev' is not defined locally
18:17.45 ../../build/unix/gold/ld: error: hidden symbol '_ZN6icu_5913UnicodeStringD1Ev' is not defined locally
18:17.45 ../../build/unix/gold/ld: error: hidden symbol '_ZN6icu_5913UnicodeStringD1Ev' is not defined locally
18:17.45 ../../build/unix/gold/ld: error: hidden symbol '_ZNK6icu_5913UnicodeString13doCaseCompareEiiPKDsiij' is not defined locally
18:17.45 ../../build/unix/gold/ld: error: hidden symbol '_ZN6icu_5913UnicodeString8doAppendERKS0_ii' is not defined locally
18:17.45 ../../build/unix/gold/ld: error: hidden symbol '_ZN6icu_5913UnicodeStringD1Ev' is not defined locally
18:17.45 collect2: error: ld returned 1 exit status
18:17.45 make[5]: *** [/home/xftroxgpx/build/1packages/firefox-hg/makepkg_pacman/firefox-hg/src/firefox-hg/config/rules.mk:785: libxul.so] Error 1
18:17.45 make[5]: Leaving directory '/tmp/obj-x86_64-pc-linux-gnu/toolkit/library'
18:17.45 make[4]: *** [/home/xftroxgpx/build/1packages/firefox-hg/makepkg_pacman/firefox-hg/src/firefox-hg/config/recurse.mk:73: toolkit/library/target] Error 2
18:17.45 make[4]: Leaving directory '/tmp/obj-x86_64-pc-linux-gnu'
18:17.45 make[3]: *** [/home/xftroxgpx/build/1packages/firefox-hg/makepkg_pacman/firefox-hg/src/firefox-hg/config/recurse.mk:33: compile] Error 2
18:17.45 make[3]: Leaving directory '/tmp/obj-x86_64-pc-linux-gnu'
18:17.45 make[2]: *** [/home/xftroxgpx/build/1packages/firefox-hg/makepkg_pacman/firefox-hg/src/firefox-hg/config/rules.mk:519: default] Error 2
18:17.45 make[2]: Leaving directory '/tmp/obj-x86_64-pc-linux-gnu'
18:17.45 make[1]: *** [/home/xftroxgpx/build/1packages/firefox-hg/makepkg_pacman/firefox-hg/src/firefox-hg/client.mk:419: realbuild] Error 2
18:17.45 make[1]: Leaving directory '/home/xftroxgpx/build/1packages/firefox-hg/makepkg_pacman/firefox-hg/src/firefox-hg'
18:17.45 make: *** [client.mk:170: build] Error 2
18:17.50 0 compiler warnings present.
nevermind, fixed by replacing this mozbuild line:
ac_add_options --with-system-icu
with this:
ac_add_options --without-system-icu

$ pacman -Qs icu
local/icu 59.1-1
    International Components for Unicode library

on Arch Linux.

Sorry for the noise.
typo: by mozbuild I meant mozconfig
(also the patch wasn't needed without system icu)
Duplicate of this bug: 794698
Component: Build Config → General
Product: Firefox → Firefox Build System
Target Milestone: Firefox 55 → mozilla55
You need to log in before you can comment on or make changes to this bug.