Bob Tanski wrote:
> I should have been a little more specific.
>
> When you use -Bsymbolic the linker spits out the unresolved symbols and
> then completes the link of the shared object. I'm looking for a way to
> get the same behavior without specifying -Bsymbolic. -zdef spits out
> the symbols but doesn't perform the link.
What do you do with the list of undefined symbols ld() spits out?
Perhaps you could explicitly define those symbols that you know are
external and use -z defs? For example, if you build a shared object
that references the external function foo() and bar(), then you should
provide the associated dependencies (-lfoo, -lbar?). But, if these
functions are expected to be found in a calling object (the a.out
perhaps as "callbacks"), you could build your shared object with a mapfile:
% cat mapfile
{
global:
foo = EXTERN;
bar = EXTERN;
};
% cc -M mapfile -z defs -o xxx.so ....
The mapfile will "silence" any unresolved errors, but the -zdefs will make sure
you don't contribute any unknown new references.
Gory mapfile details:
http://docs.sun.com/app/docs/doc/819-0690/gdzmc?a=view
I've just integrated an updated to ldd(1) in Nevada (6357282) that recognizes
these "extern" definitions from an object, and silences any ldd() unresolved
symbol messages too. Thus you can use mapfiles and -zdefs throughout your
build to ensure all symbol references are resolved, or known, and/or use ldd()
on all deliverables to ensure the same.
--
Rod.
