292714 - libimgicon.so cannot be linked on x86-64

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Wolfgang Rosenauer [:wolfiR]]

libimgicon.so cannot be linked on x86-64:

c++ -I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion
-Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy
-Wno-non-virtual-dtor -Wno-long-long -pedantic -O2 -fmessage-length=0 -Wall -Os
-fno-strict-aliasing -fshort-wchar -pthread -pipe  -DNDEBUG -DTRIMMED -O2
-fmessage-length=0 -Wall -Os -fno-strict-aliasing -fPIC -shared -Wl,-h
-Wl,libimgicon.so -o libimgicon.so  nsIconURI.o nsIconModule.o
nsIconProtocolHandler.o       -Wl,--whole-archive
../../../../dist/lib/libimgicongtk_s.a -Wl,--no-whole-archive -L/usr/lib64
-L/opt/gnome/lib64 -L/usr/X11R6/lib64   -lgnomeui-2 -lSM -lICE -lbonoboui-2
-lxml2 -lpthread -lz -lgnomecanvas-2 -lgnome-2 -lpopt -lart_lgpl_2
-lpangoft2-1.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0
-lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgnomevfs-2 -lbonobo-2
-lgconf-2 -lbonobo-activation -lORBit-2 -lm -lgmodule-2.0 -ldl -lgthread-2.0
-lglib-2.0    -L../../../../dist/bin -lxpcom -lxpcom_core 
-L../../../../dist/bin -L../../../../dist/lib -lplds4 -lplc4 -lnspr4 -lpthread
-ldl  -Wl,--version-script
-Wl,../../../../build/unix/gnu-ld-scripts/components-version-script
-Wl,-Bsymbolic -ldl -lm
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../x86_64-suse-linux/bin/ld:
../../../../dist/lib/libimgicongtk_s.a(nsIconChannel.o): relocation R_X86_64_32
against `a local symbol' can not be used when making a shared object; recompile
with -fPIC
../../../../dist/lib/libimgicongtk_s.a(nsIconChannel.o): could not read symbols:
Bad value
collect2: ld returned 1 exit status

Comment 1

[Mike Shaver (:shaver emeritus)]

gcc version?  Is this one with the known hidden-visibility bugs fixed?  (biesi:
do you know the number for that x86-64 bug?  I can't find it right now, but this
is looking like a dup.)

I presume that nsIconChannel.o is, in fact, being built with -fPIC, because
that's how our CFLAGS work, but I can't tell from the snippet pasted.

Comment 2

[Wolfgang Rosenauer [:wolfiR]]

it happens with gcc 3.3.5 and gcc 4.0.1 for me.
The gcc 3.3.5 as delivered with SUSE 9.3.

nsIconChannel.o isn't built with -fPIC according to my build-log.
But I've rebuilt it with -fPIC and tried again to link it which still failed.

Comment 3

[cls]

Attachment: Use FORCE_USE_PIC on libimgicongtk_s.a

It sounds like you're doing a static build and that we're forcing libimgicon to
be dynamic in the static build.  This means that the static libraries used to
create the shared library must be built with -fPIC by setting FORCE_USE_PIC as
well.

Comment 4

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 182504 [details] [diff] [review]
Use FORCE_USE_PIC on libimgicongtk_s.a

a=caillon for 1.8b3

Comment 5

[Benjamin Smedberg]

Comment on attachment 182504 [details] [diff] [review]
Use FORCE_USE_PIC on libimgicongtk_s.a

aargh, midair

Comment 6

[Wolfgang Rosenauer [:wolfiR]]

JFI: the patch works for me

Comment 7

[Asa Dotzler [:asa]]

Comment on attachment 182504 [details] [diff] [review]
Use FORCE_USE_PIC on libimgicongtk_s.a

a=asa

Comment 8

[cls]

The patch was checked in on 2005/05/10 .