[haiku-bugs] Re: [Haiku] #7892: [Pe] segfaults in extensions "{cut, copy} lines"
- From: "bonefish" <trac@xxxxxxxxxxxx>
- Date: Mon, 08 Aug 2011 23:25:37 -0000
#7892: [Pe] segfaults in extensions "{cut, copy} lines"
----------------------------+-----------------------------------
Reporter: ttcoder | Owner: zooey
Type: bug | Status: in-progress
Priority: normal | Milestone: R1
Component: Applications | Version: R1/alpha3
Resolution: | Keywords: Pe extension segfault
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
----------------------------+-----------------------------------
Comment (by bonefish):
When resolving a symbol all global shared objects (`RTLD_GLOBAL`) are
searched in the order they were loaded. That is also the case when
resolving symbols of add-ons. This is probably not quite the way Be
intended it to work, but there's really no alternative, if we want to
properly support weak symbols.
Regarding the solution to link Pe against libpcreposix.so, that probably
causes libpcreposix.so to be in Pe's needed library list before libroot.so
so it also ends up early in the global shared object list.
The symbol lookup for gcc 2 (Haiku) and gcc 4 built objects works just the
same. The only difference is that gcc 2 built objects are linked
symbolically, which means that symbols defined in the object are always
used instead of looking them up as well (i.e. symbol preemption is
prevented). There's no difference for undefined symbols though.
Normally (i.e. when not hacked like for Haiku) glibc defines "!__"
prefixed, non-weak versions of all public API functions while the non-
prefixed versions are weak. This way the non-prefixed versions can be
overwritten while it is still possible to use the original functions
internally.
Note that the issue will not really be solved by making libroot's symbols
weak, though. Using two libraries that export equally named but
incompatible symbols will always remain a problem. E.g. with two add-ons,
one using the libroot regex support, the other libpcreposix, one is
screwed for sure. The only solution is to load libpcreposix dynamically
with `RTLD_LOCAL` and look up the needed symbols with `dlsym()`.
--
Ticket URL: <http://dev.haiku-os.org/ticket/7892#comment:6>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
