[Mingw-users] Re: Fwd: [Mingw-msys] libgen.h (dirname, basename) and

[<rr...@cs...>]

Ross Ridge wrote:
> That"s the only type of weak symbol supported by PECOFF.
> Weak externals always alias one symbol with another. 

Danny Smith wrote:
>Technically, yes, is the brader sense of "alias" -- but the "alias" may
>be just a null-pointer rather than symbol of the same type.

They always alias another symbol.  The "TagIndex" field auxiliary
references another symbol that must exist at link time.  When you try
to create an unaliased weak symbol on a PECOFF target, binutils will
silently create a symbol in order to satisify this requirement.

>What I was referring to was the IMAGE_WEAK_EXTERN_SEARCH_ALIAS
>characteristic

I wouldn't call these weak aliases, as they're true aliases.  It's an
error if the symbol is defined somewhere else.  You problaby saw what
I've seen in Microsoft libraries, weak externals with the SEARCH_LIBRARY
characteristic.

>What I should have said: The SVR4 ABI uses (and bfd currently supports)
>the equivalent of IMAGE_WEAK_EXTERN_SEARCH_NOLIBRARY semantics (a library
>member does not resolve a weak symbol unless a strong symbol cause the
>member to be linked in)

Well, this gets back to my original concern, I'm not sure how well
binutils is able to implement System V ABI (and thus ELF) weak semantics
using PECOFF.  One problem I've noticed is that those symbols binutils
silently creates aren't guaranteed to be unique and can cause multiple
definition problems.

					Ross Ridge