Confusing meaning of --no-undefined

[H. J. Lu]

On Tue, Feb 11, 2003 at 05:30:45PM +0000, Nick Clifton wrote:
> Hi Alan, Hi H.J.,
> 
>   I need your help/advice.  I took a look at the error reported by Jan
>   Vroonhof:
> 
>     http://sources.redhat.com/ml/binutils/2003-02/msg00024.html
> 
>   concerning the fact that:
> 
>      ld --share --no-undefined foo.o bar.so
> 
>   does not report an undefined symbol in bar.so.
> 
>   It seemed to me that the problem was in elf_link_output_extsym()
>   in bfd/elflink.h, where there is a test for unresolved symbols:
> 
>     /* If we are not creating a shared library and this symbol is
>        referenced by a shared library but is not defined anywhere, then
>        warn that it is undefined.  If we do not do this, the runtime
>        linker will complain that the symbol is undefined when the
>        program is run.  We don't have to worry about symbols that are
>        referenced by regular files, because we will already have issued
>        warnings for them.  */
>     if (! finfo->info->relocateable
>         && ! finfo->info->allow_shlib_undefined
>         && ! finfo->info->shared
>         && h->root.type == bfd_link_hash_undefined
>         && (h->elf_link_hash_flags & ELF_LINK_HASH_REF_DYNAMIC) != 0
>         && (h->elf_link_hash_flags & ELF_LINK_HASH_REF_REGULAR) == 0
>         && ! elf_link_check_versioned_symbol (finfo->info, h))
>       {
> 
>   This seemed wrong to me, since if we *are* creating a shared library
>   we should also issue an error message unless allow_shlib_undefined
>   is true.  So I changed the test like this:
> 

I believe we have gone through it before. Since bar.so is not the
part of the resulting DSO, I don't see why ld should complain. Even
if ld checks bar.so at the link-time, we don't know if the run-time
bar.so is the same one. If you want to ensure there is no undefined
symbol in bar.so, you should do

# ld --share --no-undefined -o bar.so ...



H.J.