Closed Bug 292714 Opened 19 years ago Closed 19 years ago

libimgicon.so cannot be linked on x86-64

Categories

(Firefox Build System :: General, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.8beta2

People

(Reporter: wolfiR, Unassigned)

Details

Attachments

(1 file)

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
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.
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.
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.
Attachment #182504 - Flags: review?(cbiesinger)
Attachment #182504 - Flags: review?(cbiesinger) → review+
Attachment #182504 - Flags: approval1.8b3?
Comment on attachment 182504 [details] [diff] [review]
Use FORCE_USE_PIC on libimgicongtk_s.a

a=caillon for 1.8b3
Attachment #182504 - Flags: approval1.8b3? → approval1.8b3+
Attachment #182504 - Flags: approval1.8b3?
Attachment #182504 - Flags: approval1.8b3+
Attachment #182504 - Flags: approval1.8b2?
Comment on attachment 182504 [details] [diff] [review]
Use FORCE_USE_PIC on libimgicongtk_s.a

aargh, midair
Attachment #182504 - Flags: approval1.8b3? → approval1.8b3+
JFI: the patch works for me
Comment on attachment 182504 [details] [diff] [review]
Use FORCE_USE_PIC on libimgicongtk_s.a

a=asa
Attachment #182504 - Flags: approval1.8b2? → approval1.8b2+
The patch was checked in on 2005/05/10 .
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8beta2
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: