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. }

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.

(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.

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