On Wed, Jul 27, 2011 at 12:23 PM, Neal Becker <ndbecker2@xxxxxxxxx> wrote: > Sounds like the best course of action is to just disable debugedit? > 1. Would this be acceptable for a fedora package? > 2. Is it possible to disable debugedit? I don't think disabling debugedit is necessary. I think I see the problem. Caveat: I don't REALLY know what I'm talking about. You should get someone who understands the linker to help out. Upstream is adding new sections named .the.begin and .the.end, containing __shareable_begin and __shareable_end, respectively, in order to bracket the range of addresses they need to worry about. However, their altered linker script does not put these new sections in any particular segment, and since ld doesn't recognize the section names, they aren't added to any of the default segments, so they aren't marked as either loadable or allocatable. That means they can be garbage collected, which debugedit dutifully does. In short, this is an upstream bug. If that shared library was in /usr/lib64 where prelink could see it, I bet that prelink would nuke those sections, too. The solution is for upstream to change their linker scripts to put those new sections into a segment that won't be garbage collected. Take a look at the output of "readelf -S libmtcp.so". Note the absence of any flags on the ".the.begin" and ".the.end" sections. Also, the output of "readelf -l libmtcp.so" shows that there is no section-to-segment mapping for the new sections. Hoping-this-is-not-utter-nonsense-ly yours, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel