This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: for 3.4-bi 20021213 (experimental) testsuite on

> I think elf specifies weak symbols default to zero.
> says so on page 1-18 2nd bullet. That is
> an i86 base document though - I couldn't google a plain elf spec.

There is one at <<>.  It says
in the 2nd bullet of the latest document:

When the link editor searches archive libraries [see ``Archive File'' in
Chapter 7], it extracts archive members that contain definitions of undefined
global symbols. The member's definition may be either a global or a weak
symbol. The link editor does not extract archive members to resolve undefined
weak symbols. Unresolved weak symbols have a zero value. 


The behavior of weak symbols in areas not specified by this document is
implementation defined. Weak symbols are intended primarily for use in system
software. Applications using weak symbols are unreliable since changes in the
runtime environment might cause the execution to fail. 

I have to think that the HP linker is non-compliant in that it produces
an unsatisfied error for unresolved weak symbols.  I did a futher test
to see if an archive library search for an undefined weak symbol would
incorrectly pull in a member to resolve an undefined weak symbol.  Sure
enough, it did.  So, the HP linker also non-compliant in this way as well.

It's not as clear how the dynamic linker should behave because it is not
generating an elf object file.  However, I think it could be argued that
it should treat undefined weak symbols in the same manner as the regular

J. David Anglin                        
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]