User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100723 Fedora/3.6.7-1.fc13 Firefox/3.6.7 Build Identifier: xulrunner-2.0b6pre.en-US.linux-i686.tar.bz2 libxul.so in not built with -fPIC, leading to some weird behavior on linux. Reproducible: Always

used build xulrunner-2.0b6pre.en-US.linux-i686.tar.bz2

the basic tutorial : https://developer.mozilla.org/en/Getting_started_with_XULRunner doesn't work with this build

forget about comment #2, it has nothing to do with that. "eu-findtextrel libxul.so" gives the attached file

This results in Firefox-4.0b6 having an selinux avc denial in Fedora. I remarked that libvpx is statically linked to, please allow to use the system vpx, this will solve this issue most probably.

System libvpx was WONTFIXed in bug 577653.

this was just a suggestion however, testing official mozilla binaries for ff4 is not possible with selinux enabled due to this

(In reply to comment #5) > This results in Firefox-4.0b6 having an selinux avc denial in Fedora. > > I remarked that libvpx is statically linked to, please allow to use the system > vpx, this will solve this issue most probably. I installed SELinux in my Ubuntu 10.04 using 'sudo apt-get install selinux', and I restated after it the install finished. I can still run my FF4 debug build. Do I have to do sometime else cause SELinux to prevent my debug build to run? I haven't tried Fedora 32bit. We could also build on 32bit linux with libvpx's CONFIG_PIC set to 1, that may prevent these text relocations.

(In reply to comment #8) > (In reply to comment #5) > > This results in Firefox-4.0b6 having an selinux avc denial in Fedora. > > > > I remarked that libvpx is statically linked to, please allow to use the system > > vpx, this will solve this issue most probably. > > I installed SELinux in my Ubuntu 10.04 using 'sudo apt-get install selinux', > and I restated after it the install finished. I can still run my FF4 debug > build. Do I have to do sometime else cause SELinux to prevent my debug build to > run? > > I haven't tried Fedora 32bit. Maybe you forgot to do : sudo setenforce 1 > > We could also build on 32bit linux with libvpx's CONFIG_PIC set to 1, that may > prevent these text relocations. Thanks, that would be nice

We really do need to be building VPX with PIC. And boy, we really need the build to break if we get this wrong.

I've tried building on with PIC enabled in libvpx on Fedora Core 13 32bit (which has SELinux on by default), but I still get the error "cannot restore segment prot after reloc: permission denied". Unfortunately `eu-findtextrel libxul.so` is crashing for me, which version of eu-findtextrel are you using Hicham?

(In reply to comment #11) > I've tried building on with PIC enabled in libvpx on Fedora Core 13 32bit > (which has SELinux on by default), but I still get the error "cannot restore > segment prot after reloc: permission denied". Unfortunately `eu-findtextrel > libxul.so` is crashing for me, which version of eu-findtextrel are you using > Hicham? elfutils-0.149-1.fc13.i686

That's the same version I have, except mine is x86_64. The bug for that version crashing on libxul.so is https://bugzilla.redhat.com/show_bug.cgi?id=638432 We should change the build to check our libraries for textrels and fail if they're present. A simple readelf -d $file | grep TEXTREL should be sufficient, I think. (Also, flags got clobber by comment 11, so rerequesting blocking.)

Yeah, having a test for this would be great.

I think a command that finds the problematic symbols on x86-64 Linux for me may be: objdump --dynamic-syms libxul.so | grep "g D \.text" though I'm not sure if that catches all the cases we need to care about.

... which is documented in http://sourceware.org/ml/binutils/2007-09/msg00076.html It's probably not really the right test.

bsmedberg reopened bug 388971 which has an old patch of mine to check for relocations.

I have a patch which *mostly* fixes this. Still working on one last failure.

This fixes all the relocations except for one: either the file containing the function '_ZNSt6vectorIN7mozilla6layers9EditReplyESaIS2_EE9push_backERKS2_' or the file containing the function '_ZNSt15basic_stringbufIcSt11char_traitsIcE14pool_allocatorIcEE7seekoffExSt12_Ios_SeekdirSt13_Ios_Openmode' is not compiled with -fpic/-fPIC This one might be a compiler bug, but we should get this patch landed first and can then investigate more.

+OpenGL/OpenGL.h Why does this affect libvpx libxul.so text relocations (and the C++ header files added to system-headers). libvpx doesn't use C++ does it?

That wasn't vpx, that was gfx/angle.

I hit this trying to test thunderbird 3.3 - it wont run because libxul.so requires text relocation.

OpenGL/OpenGL.h is a system header?

It's sure not a mozilla header: http://mxr.mozilla.org/mozilla-central/find?string=opengl.h

The only reason we put things in system-headers is so symbols they define get normal visibility, instead of our default hidden visibility.

right, but I don't know what "OpenGL/OpenGL.h" is, or why it should be added. AFAIK that only exists on OSX for the framework include, even though gl/gl.h is still the right thing.

_ZNSt6vectorIN7mozilla6layers9EditReplyESaIS2_EE9push_backERKS2_ comes from gfx/layers/ipc/ShadowLayersParent.cpp, but the file is compiled with -fPIC && system_wrappers which already contains a wrapper for vector class...

I landed http://hg.mozilla.org/mozilla-central/rev/a6ed567bdfb8 I'm going to mark this bug fixed, since it was about vpx and such. If the remaining issue persists, I'd love help diagnosing it: right now I suspect a compiler bug (certainly something we've seen before), but I'm not sure why eu-findtextrel is reporting a bad relocation at all.

I still get an error about text relocations when trying to run m-c with your changeset applied. eu-findtextrel is still crashing, so I don't know how to determine what is causing the remaining textrels.

Matthew Gregan pointed out a work around to get eu-findtextrel to work: run `ulimit -s unlimited` first. Attached are the remaining textrels.

How did you generate that list? hourly builds are not clobbers, so you either need to test a local clobber or tomorrow's nightly. I have only two warnings left, and none relating to vp8.

(In reply to comment #31) > How did you generate that list? hourly builds are not clobbers, so you either > need to test a local clobber or tomorrow's nightly. I have only two warnings > left, and none relating to vp8. This is in a local clobber debug build, building rev 4f6c27fc9977, on x86 fc13.

I'm pretty sure there's no dependency tracking for .asm incudes, so that, at least, will not get picked up in a clobber build.

This is what I came up with.

Filed bug 604307 for relocations in libycbcr.so.

why mark this bug as resolved if there are still text relocs ?

Because this bug is about relocations in libvpx. I filed another one for relocations in ycbcr module.

In nightly build of 20101024 the 64 bit one is fine - but the 32 bit still has a problem: for i in *.so do readelf -d $i 2>/dev/null | sed -e "s,^,$i: ," | grep TEXTREL done libxul.so: 0x00000016 (TEXTREL) 0x0