exporting symbols, help with export list

[Robert Schweikert]

Attached is a small example that demonstrates my problem.

The goal:

My goal is to give the linker a list of symbol names that I'd like to
have accessible (global) from outside a shared library. All names not
specified in the list should be treated as local. If a local symbol is
called from outside the shared object the linker should issue an error
and stop linking.

My approach:

(a) My first attempt is to use a file (export.lst in the tarball) that
simply lists the symbols I want accessible from outside the shared
object and pass it to the linker with the -retain-symbols-file. This
does not work, i.e. calling a symbol not listed in the file from outside
the .so does not trigger a link error.

(b) My second approach is to use a version script (xportScript_1.txt in
the tarball) specifying the global and local symbols and passing the
script with -version-script to the linker. This works, i.e. calling a
symbol not listed as global generates a link error.

(c) My third approach is to use a version script (xportScript_2.txt in
the tarball) specifying only the global symbols and passing the script
with -version-script to the linker. This does not work, i.e. calling a
symbol not listed in the file from outside the .so does not trigger a
link error.

The example:

The tarball contains the following files 

a.h                       class definition of a
a.C                       class implementation of a
b.C                       class definition and implementation of b
export.lst                list of symbols in libA.so intended to be 
                          global
xportScript_1.txt         version script following the documented format
                          contains global and local section
xportScript_2.txt         version script following the documented format
                          contains only global section
cmds.txt                  commands used to generate .o and .so files

All methods but the a::print() method are ment to be global in libA.so.
The print method of class b calls a::print() and thus when linking
libB.so from b.o a link error should be triggered.


The way our system works:

We maintain a list of symbols which represent methods a given developer
wants to make available outside a component (shared library) as the
interface for certain functionality. This list of functions/methods is
maintained by developers and only contains the functions/methods which
are intended to be global. Prior to linking we parse the maintained list
and generate regular expressions for each function/method. The list is
maintained in code form, i.e. would contain a::print() rather than
_ZN1a5printEv. This is done to be platform independent. After generating
the regular expressions the parser scans all the object files (.o) to
extract the symbols that match the regular expressions from the
maintained list. All matches are written to a file (export list) and
this is then presented to the linker.


The problem:

Currently we use the -retain-symbols-file option and this does not
generate the desired link errors as demonstrated in case (a) of the
example. In an ideal world (for us) this would work.
At the present, as described above we only know the global symbols, thus
we can relatively easily produce a script that follows example (c).
However, that unfortunately doesn't work either. Therefore we would have
to generate a script that matches example (b) and spells out global and
local symbols. This new script will be rather large and would
potentially be more expensive to generate. Another issue with options
(b) and (c) is that we do not really care about versioning and thus
carrying the extra data in the shared library appears superfluous.


Is there any chance to get option (a) to work like (b), i.e. using
-retain-symbols-file and get the same effect as a version script with
global and local sections?
One concern is with exceptions in C++. How does the use of exceptions
across shared libraries work when using export lists? Are there
predefined symbols that need to go into the global section?

Answers, comments and advise are welcome.

Thanks,
Robert

-- 
Robert Schweikert <Robert.Schweikert@abaqus.com>
ABAQUS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xportExa.tgz
Type: application/x-gzip
Size: 965 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20040802/92cafb3b/attachment.bin>