OS_GetEnv result

John Tytgat John.Tytgat at aaug.net
Mon Aug 5 11:22:17 PDT 2002

In message <3D4E3D54.7090401 at dsvr.net>
          Nick Burrett <nick at dsvr.net> wrote:

> AFAICT, the linker doesn't handle WEAK symbols very well.  Usually, even 
> though something is marked WEAK, the linker drags in all associated 
> functions anyway.  This is why I removed the original ___vfork and 
> ___stdiolib WEAK links.
> If we can avoid WEAK symbols, then that would be preferable in my book.

I think I see a conflict of use here (or understanding how WEAK symbols
are supposed to work).  In this thread we want to define __riscosify_control
as a WEAK symbol (like __dynamic_da_name and __dynamic_no_da) so that
as soon as there is a variable defined called __riscosify_control in
an object/library specified on our link line (not necessary really used
or refered elsewhere apart from the WEAK link), we want the WEAK symbol
to have the address of __riscosify_control.  I believe there are no issues
with this kind of WEAK symbol use.

But, Nick's use (the __vfork & __stdiolib WEAK symbols) is slightly
different.  I think Nick wants to have a non zero contents of those
WEAK symbols as soon as there is a piece of code which (in)directly
referred by __main and which is itself using (in)directly __vfork/
__stdiolib.  This is different from the case where you just have in your
link line an object file/library file (like UnixLib) which has a
reference to __vfork/__stdiolib but that piece of code is not necessary
referred (in)directly by __main.  I don't think those two uses
are compatible and that the second use of WEAK symbols can easily be
(mis ?)described as a problem with the linker.

John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at aaug.net                             ARM powered, RISC OS driven

More information about the gcc mailing list