Article View: comp.soft-sys.matlab
Article #206Re: g++: Shared library, mapfiles, execution speed
From: Bart Smaalders
Date: Tue, 18 Mar 2003 06:47
Date: Tue, 18 Mar 2003 06:47
41 lines
3457 bytes
3457 bytes
Drazen Kacar <dave@willfork.com> wrote in message news:<slrnb79ole.lql.dave@willfork.com>...
> Bart Smaalders wrote:
>
> > If you're not interposing on symbols in the library, the library may
> > also be linked w/ -Bsymbolic,
>
> Any reason why you're mentioning -Bsymbolic and not -Bdirect?
Because -Bdirect tells ld.so to remember where to find symbols (eg
what library to search in), whereas -Bsymbolic tells ld to
convert any references to global symbols that end up resolving at link
time to the current library to a local binding as if the symbol were static.
This cuts down on run-time overhead by avoiding the call through the PLT.
From the fine man page:
-B direct
Establishes direct binding information by recording
the relationship between each symbol reference and the
dependency that provides the definition. The runtime
linker uses this information to search directly for
the symbol in the associated object rather than to
carry out its default symbol search. Direct binding
information can only be established to dependencies
specified with the link-edit. Thus, you should use the
-z defs option. Objects that wish to interpose on sym-
bols in a direct binding environment should identify
themselves as interposers with the -z interpose
option. The use of -B direct enables -z lazyload for
all dependencies.
-B symbolic
In dynamic mode only. When building a shared object,
binds references to global symbols to their defini-
tions, if available, within the object. Normally,
references to global symbols within shared objects are
not bound until runtime, even if definitions are
available, so that definitions of the same symbol in
an executable or other shared object can override the
object's own definition. ld will issue warnings for
undefined symbols unless -z defs overrides.
Technical Details
Message-ID:
<5bd8e3f5.0303172247.3af625a4@posting.google.com>Path:
arc1-ca.pugleaf.net!archiver1.google.com!postnews1.google.com!not-for-mailReferences:
<3E70F170.B4EE8B07@doe.carleton.ca> <3E71FA77.7050803@mathworks.com> <3E72008C.278477DD@doe.carleton.ca> <5bd8e3f5.0303161233.20d25923@posting.google.com> <slrnb79ole.lql.dave@willfork.com>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 11318c,e2dd6c17ce56ca38 X-Google-Attributes: gid11318c,public X-Google-Thread: 106e3f,e2dd6c17ce56ca38 X-Google-Attributes: gid106e3f,public X-Google-Thread: fc89c,e2dd6c17ce56ca38 X-Google-Attributes: gidfc89c,public X-Google-Thread: 11035d,e2dd6c17ce56ca38 X-Google-Attributes: gid11035d,public X-Google-ArrivalTime: 2003-03-17 22:47:21 PST Path: arc1-ca.pugleaf.net!archiver1.google.com!postnews1.google.com!not-for-mail From: barts@smaalders.net (Bart Smaalders) Newsgroups: comp.soft-sys.matlab,gnu.gcc.help,comp.unix.programmer,comp.unix.solaris Subject: Re: g++: Shared library, mapfiles, execution speed Date: 17 Mar 2003 22:47:20 -0800 Organization: http://groups.google.com/ Lines: 41 Message-ID: <5bd8e3f5.0303172247.3af625a4@posting.google.com> References: <3E70F170.B4EE8B07@doe.carleton.ca> <3E71FA77.7050803@mathworks.com> <3E72008C.278477DD@doe.carleton.ca> <5bd8e3f5.0303161233.20d25923@posting.google.com> <slrnb79ole.lql.dave@willfork.com> NNTP-Posting-Host: 216.103.214.41 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1047970040 20337 127.0.0.1 (18 Mar 2003 06:47:20 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 18 Mar 2003 06:47:20 GMT