Closed Bug 615196 Opened 14 years ago Closed 13 years ago

[SeaMonkey 2.0, linux64 (dep) 'build'] new OTS code causes "/usr/bin/ld: gfxUserFontSet.o: relocation R_X86_64_PC32 against `ots::Process(...)' can not be used when making a shared object; recompile with -fPIC"

Categories

(Core :: Graphics, defect)

1.9.1 Branch
x86_64
Linux
defect
Not set
blocker

Tracking

()

RESOLVED WONTFIX
Tracking Status
status2.0 --- unaffected
status1.9.1 --- wanted

People

(Reporter: sgautherie, Assigned: Callek)

References

Details

Spun off from bug 613374 which fixed nightlies (only).

{
/usr/bin/ld: gfxUserFontSet.o: relocation R_X86_64_PC32 against
`ots::Process(ots::OTSStream*, unsigned char const*, unsigned long, bool)' can
not be used when making a shared object; recompile with -fPIC

that is typically just needing a
FORCE_USE_PIC=1 put in an appropriate makefile.in - probably the
thebes/src/Makefile.in.
}
blocking1.9.1: --- → ?
Summary: [SeaMonkey 2.0, linux64 (dep) 'build'] new OTS code causes "" → [SeaMonkey 2.0, linux64 (dep) 'build'] new OTS code causes "/usr/bin/ld: gfxUserFontSet.o: relocation R_X86_64_PC32 against `ots::Process(...)' can not be used when making a shared object; recompile with -fPIC"
I don't know why you didn't just fix this in the other bug, but we'll look at a patch when you have one.  I don't see any way to mark this bug blocking-seamonkey, maybe it should be filed in the SeaMonkey component, but it's not blocking the 1.9.1 branch itself.
blocking1.9.1: ? → ---
(In reply to comment #1)
> I don't know why you didn't just fix this in the other bug, but we'll look at a
> patch when you have one.  I don't see any way to mark this bug
> blocking-seamonkey, maybe it should be filed in the SeaMonkey component, but
> it's not blocking the 1.9.1 branch itself.

1.9.1 linux64 nightlies compile fine, its the shared linux64 builds that are failing. And as its a pretty darn old branch I don't think we need to BLOCK sec releases on it, it is _certainly_ good to fix though.
Assignee: nobody → bugspam.Callek
I just stumbled on this issue in seamonkey 2.0.11 on RHEL5.
All previous versions (2.0.x up to and including 2.0.10) did build and work
fine as linux64. Something changed in 2.0.11 which is causing my rpmbuild to
fail:

c++  -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual
-Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align
-Wno-invalid-offsetof -Wno-long-long -pedantic -fno-strict-aliasing
-fshort-wchar -pthread -pipe  -DNDEBUG -DTRIMMED -Os -freorder-blocks
-fno-reorder-functions -finline-limit=50
-I/usr/src/redhat/BUILD/seamonkey/objdir/mozilla/dist/include/cairo
-I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12
-I/usr/include/gtk-unix-print-2.0   -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 
 -fPIC -shared -Wl,-z,defs -Wl,-h,libthebes.so -o libthebes.so 
cairo-xlib-utils.o gfxASurface.o gfxAlphaRecovery.o gfxBlur.o gfxContext.o
gfxImageSurface.o gfxFont.o gfxFontMissingGlyphs.o gfxFontTest.o gfxFontUtils.o
gfxMatrix.o gfxPath.o gfxPattern.o gfxPlatform.o gfxRect.o gfxSkipChars.o
gfxTextRunCache.o gfxTextRunWordCache.o gfxUserFontSet.o gfxPangoFonts.o
gfxXlibSurface.o gfxPlatformGtk.o gfxGdkNativeRenderer.o gfxPDFSurface.o
gfxPSSurface.o gfxFontconfigUtils.o nsUnicodeRange.o     -lpthread  
-Wl,-rpath-link,/usr/src/redhat/BUILD/seamonkey/objdir/mozilla/dist/bin
-Wl,-rpath-link,/usr/lib  ../../../gfx/cairo/cairo/src/libmozcairo.a
../../../gfx/cairo/libpixman/src/libmozlibpixman.a   -L/usr/lib64 -lXrender
-lfreetype -lfontconfig
/usr/src/redhat/BUILD/seamonkey/objdir/mozilla/dist/lib/libunicharutil_s.a
-L/usr/src/redhat/BUILD/seamonkey/objdir/mozilla/dist/bin -lxpcom -lxpcom_core 
-L/usr/src/redhat/BUILD/seamonkey/objdir/mozilla/dist/lib -lplds4 -lplc4
-lnspr4 -lpthread -ldl -lz  ../../../gfx/qcms/libmozqcms.a
../../../gfx/ots/src/libmozots.a  -L/lib64 -lpangoft2-1.0 -lpango-1.0
-lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0   -lz  -L/usr/lib64 -lX11  -L/lib64
-lgtk-x11-2.0 -latk-1.0 -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0
-lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0    -lasound
-ldl -lm
/usr/bin/ld: gfxUserFontSet.o: relocation R_X86_64_PC32 against
`ots::Process(ots::OTSStream*, unsigned char const*, unsigned long, bool)' can
not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
gmake[7]: *** [libthebes.so] Error 1
gmake[7]: Leaving directory
`/usr/src/redhat/BUILD/seamonkey/objdir/mozilla/gfx/thebes/src'
gmake[6]: *** [libs] Error 2
gmake[6]: Leaving directory
`/usr/src/redhat/BUILD/seamonkey/objdir/mozilla/gfx/thebes'
gmake[5]: *** [libs] Error 2
gmake[5]: Leaving directory
`/usr/src/redhat/BUILD/seamonkey/objdir/mozilla/gfx'
gmake[4]: *** [libs_tier_gecko] Error 2
gmake[4]: Leaving directory `/usr/src/redhat/BUILD/seamonkey/objdir/mozilla'
gmake[3]: *** [tier_gecko] Error 2
gmake[3]: Leaving directory `/usr/src/redhat/BUILD/seamonkey/objdir/mozilla'
gmake[2]: *** [default] Error 2
gmake[2]: Leaving directory `/usr/src/redhat/BUILD/seamonkey/objdir/mozilla'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/usr/src/redhat/BUILD/seamonkey/objdir'
make: *** [build] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.2979 (%build)
Err I'm sorry. I forgot that distro's *do* ship linux64 builds.

I'll get this fixed asap for you. [sorry]
Hi Justin,
No problem at all. This kind of stuff can happen. On RHEL5, you can use both ia32 and x86_64 binaries -BUT- for the x86_64 desktop, RedHat only ships java-1.6.0 as x86_64. This means that your browser must be x86_64 too if you need java applets (the ia32 plugins run fine in the x86_64 browser but the reverse isn't true).
Please let me know when/if you have a patch and I'll re-test my builds
Thanks
Vincent
Just to let you know... I think I found a workaround.
I changed my spec file as follows:
- Added 'ac_cv_visibility_pragma=no' to .mozconfig
- Added the following before the actual 'build':
export CFLAGS="-pipe -fPIC"
export CXXFLAGS="$CFLAGS"
make -f client.mk build

I am not sure if the '-fPIC' is still required with ac_cv_visibility_pragma=no but at least seamonkey now compiles and works fine on linux64:

$ rpm -qa seamonkey\*
seamonkey-2.0.11-7.el5.x86_64
seamonkey-debuginfo-2.0.11-7.el5.x86_64
Only adding ac_cv_visibility_pragma=no seems to be enough for me to build thunderbird-3.1.7 on CentOS 5.5 x86_64.
Yup, ac_cv_visibility_pragma=no is most likly enough. My CFLAGS stuff is most likly not needed for seamonkey either.. :)
(In reply to comment #4)
> Err I'm sorry. I forgot that distro's *do* ship linux64 builds.
> 
> I'll get this fixed asap for you. [sorry]

Actually very sorry this got delayed MUCH longer than I had hoped, Mozilla-1.9.1 is now EOL, and SeaMonkey 2.0 probably won't get any updates.

If a patch gets created I can promise to try and drive it through, but we likely won't be shipping another SeaMonkey version, marking it wontfix due to this situation
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.