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