Bug#488531: devhelper FTBFS with gp-relative relocation against dynamic symbol
Mike Hommey
mh at glandium.org
Wed Jul 2 05:56:15 UTC 2008
On Tue, Jul 01, 2008 at 09:47:42PM -0700, Steve Langasek wrote:
> On Tue, Jul 01, 2008 at 09:11:26PM +0200, Andreas Barth wrote:
> > * Mike Hommey (mh at glandium.org) [080701 20:35]:
> > > On Tue, Jul 01, 2008 at 08:24:02PM +0200, Mike Hommey wrote:
> > > > On Tue, Jul 01, 2008 at 10:49:10AM +0200, Andreas Barth wrote:
> > > > > * Mike Hommey (mh at glandium.org) [080701 07:40]:
> > > > > > On Sun, Jun 29, 2008 at 04:44:34PM +0200, Andreas Barth wrote:
> > > > > > > /usr/bin/ld: final link failed: Nonrepresentable section on output
> > > > > > > collect2: ld returned 1 exit status
> > > > > >
> > > > > > Is it possible to see get this .libs/libdevhelp_1_la-Yelper.o file ?
> > > > >
> > > > > Not from me at least.
> > > > >
> > > > > What I can do is of course build that package on another alpha, and then
> > > > > copy the relevant files out - albeniz.debian.org is open for all
> > > > > developers of course.
>
> > > > I'll just get the build-deps installed on albeniz.
>
> > > Hum... it builds flawlessly on albeniz...
>
> > I've given the package now back on goetz to see if that issue persists.
> > If so, could one of the alpha porters please take a look at it?
>
> Failed again on the autobuilder.
>
> Trivially reproducible here on unstable when using dpkg-buildpackage.
>
> The Yelper.o file is attached, but I'm not sure this is a bug in that file;
> the error "gp-relative relocation against dynamic symbol
> gtk_moz_embed_get_nsIWebBrowser" looks to me like a binutils problems of
> some sort. It's apparently not the bug we've seen before with ld --relax
> being enabled by default, because adding -Wl,--no-relax to LDFLAGS doesn't
> fix it.
>
> I'm not sure why this wouldn't have been reproducible on albeniz, unless the
> build env wasn't up-to-date?
found out why: both libxul-dev and xulrunner-dev are installed ; and I
was building the wrong version. Doh.
There is something fishy with the gtk_moz_embed_get_nsIWebBrowser symbol...
it should be .hidden.
This is what it looks like on amd64:
0000000000000000 *UND* 0000000000000000 .hidden gtk_moz_embed_get_nsIWebBrowser
and alpha:
00000000000003e0 GPRELHIGH gtk_moz_embed_get_nsIWebBrowser
00000000000003f4 GPRELLOW gtk_moz_embed_get_nsIWebBrowser
It is defined as:
typedef void ( * gtk_moz_embed_get_nsIWebBrowserType) (GtkMozEmbed *embed, nsIWebBrowser **retval);
extern gtk_moz_embed_get_nsIWebBrowserType gtk_moz_embed_get_nsIWebBrowser __attribute__((visibility("hidden")));
And the real place where it is defined is dh-gecko-utils.cpp, where,
once compiled, it looks like, on alpha:
00000000000000d0 g O .sbss 0000000000000008 gtk_moz_embed_get_nsIWebBrowser
000000000000066c ELF_LITERAL gtk_moz_embed_get_nsIWebBrowser
0000000000005dc0 REFQUAD gtk_moz_embed_get_nsIWebBrowser
00000000000001b8 REFQUAD gtk_moz_embed_get_nsIWebBrowser
and on amd64:
00000000000000d0 g O .bss 0000000000000008 gtk_moz_embed_get_nsIWebBrowser
00000000000003ee R_X86_64_GOTPCREL gtk_moz_embed_get_nsIWebBrowser+0xfffffffffffffffc
0000000000005cc2 R_X86_64_64 gtk_moz_embed_get_nsIWebBrowser
00000000000001c8 R_X86_64_64 gtk_moz_embed_get_nsIWebBrowser
FWIW, there are these warnings while building dh-gecko-utils.cpp:
/usr/include/xulrunner-1.9/unstable/./gtkmozembed_glue.cpp:101: warning:
dereferencing type-punned pointer will break strict-aliasing rules.
This warning occurs when preprocessing to get to this code:
static const nsDynamicFunctionLoad GtkSymbolsInternal[] = {
{ "gtk_moz_embed_get_nsIWebBrowser", (NSFuncPtr*)
>k_moz_embed_get_nsIWebBrowser }, { "gtk_moz_embed_get_title_unichar",
(NSFuncPtr*) >k_moz_embed_get_title_unichar }, {
"gtk_moz_embed_get_js_status_unichar", (NSFuncPtr*)
>k_moz_embed_get_js_status_unichar }, {
"gtk_moz_embed_get_link_message_unichar", (NSFuncPtr*)
>k_moz_embed_get_link_message_unichar }, {
"gtk_moz_embed_set_directory_service_provider", (NSFuncPtr*)
>k_moz_embed_set_directory_service_provider }, {
"gtk_moz_embed_set_app_components", (NSFuncPtr*)
>k_moz_embed_set_app_components },
{ 0, 0 }
};
There is a global
gtk_moz_embed_get_nsIWebBrowserType gtk_moz_embed_get_nsIWebBrowser;
defined right before (likewise for other members of this array), and
even before, there is the same definition as for Yelper.cpp (see above).
If this is a toolchain issue, this can surely be worked around by
creating a wrapper function in dh-gecko-utils.cpp to get replace the
gtk_moz_embed_get_nsIWebBrowser in Yelper.cpp.
Mike
More information about the pkg-gnome-maintainers
mailing list