Rod Evans wrote:
> 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?
>
PTC filters out the symbols they expect which leaves the unexpected.
I implemented the mapfile suggestion that you detailed below and I feel
that will work fine for their needs and I have forwarded your suggestion
on to them.
thanks for your help.
> 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.
>
>
