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?


"Thomas M. Maslen" <maslen@best.com>:
> [...] 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).
[...]
> [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]




According to its man page, ld(1) on HP-UX 9 has symbol hiding,


                      -h symbol Prior to writing the symbol table to the output
                                                    file, mark this name as ``local'' so that it is no
                                                    longer externally visible. This ensures that this
                                                    particular entry will not clash with a definition
                                                    in another file during future processing by ld.


                                                    More than one symbol can be specified, but -h must
                                                    precede each one. If used when building a shared
                                                    library or program, this option prevents the named
                                                    symbol from being visible to the dynamic loader.


and the possibility of multiple stages of linking,


                      -r Retain relocation information in the output file
                                                    for subsequent re-linking. The ld command does
                                                    not report undefined symbols. The -r option is
                                                    incompatible with -A and -b.


so in principle one could do local linking, a bit painful if individual
local symbols had to be listed by hand, but I expect automatable.


I have not myself tried such things. I mentioned this as a possibility
once when my colleagues had a name clash, but I think some other
technique was used to resolve it.


In the Ideal System (which I shall never encounter) a single-language
implementation wouldn't necessarily have a visible linking stage; but as
soon as one has the possibility of linking together object modules
generated from different source languages, it seems worth while on
general software principles of information hiding to be able to say
which definitions are exported.


        Tony Bass


--
# Tony Bass Tel: (01473) 645305
# MLB 3/19, BT Laboratories e-mail: aeb@saltfarm.bt.co.uk
# Martlesham Heath, Ipswich, Suffolk, IP5 7RE
--

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