Re: Help- selective symbol exposure after link

Jason Spielman asked:


>Q: How does one link several object files into a single object file
> or library, where symbols are resolved locally as much as possible,
> and where only selected symbols are exported/exposed/made public?
[...]
>PS. it's on a linux-2.0.18 platform; however I've tried it on various
> other platforms, including sunos-4.1.3, dec-alpha-osf1-v3.2, and
> can't get it to work anywhere


This is one of the many goodies that Unix linkers have traditionally
not provided, but there are now some that support it. My guess is
that a major reason for adding it was to make the runtime cost of
shared libraries as low as possible, but that's just a guess. In any
case, I believe (it's been a couple of years) that I saw something
like this in the man page for 'ld' on HPUX 9.x, and the Solaris 2.5
'ld' man page seems to be describing a similar facility ("-B local").
I don't know whether it applies to relocatables (e.g. your "ab.o") or
only to shared libraries ("ab.sl" on HPUX, "ab.so" on Solaris 2.x).




Our friendly moderator quoth:


> [I have long maintained that nested link-time scopes are a good
> idea, but I've never seen a linker that actually provides them. -John]


... and perhaps he could expand (or expound) on that? Offhand, I'd
file it under "nice, but overkill".


Thomas
maslen@pobox.com
[It means what it sounds like, groups of modules which share symbols
but export limited numbers of symbols to the outside. For small
programs, it's overkill, but for large programs with lots of libraries
and subsystems, it'd be nice not to have to prefix every symbol shared
among routines in the foo subsystem with "foo_". Re Solaris, I looked
at the ld man page on a nearby 4.1.4 system and it looked like the
same old dumb linker, just barely smart enough to create and
defererence shared libraries. Is there something else I should look
at? -John]


--

Return to the comp.compilers page.
Search the comp.compilers archives again.