Re: glibc and egcs....
On Thu, 28 Jan 1999, Loic Prylli wrote:
> But anyway, I am not sure their semantics is appropriate in our case.
> because the resolution of weak undefined symbols occur mostly at
> compile-time only. Try the following example, if the weak symbol did
> not exist at compile time, it will never be bind at run-time, and if
> it does exists at compile-time, it be equivalent to an undefined one,
> and eventually will generate a link error at run-time.
Yes, you're right about that, but the logic introduced in the 19990115
patch should add regular 'if' conditionals (not preprocessor directives)
to test whether or not the weak is supported or not and calls
__(de)register_frame_info depending on that. Prior to the 19990115 patch
(which is currently NOT in our binary egcs package on Alpha, therefore
missing the "if"s that I'm talking about), it just calls it since it
assumes it should be there regardless. What I was saying was that the
patch adds the needed checks (from what I can tell) to work around the
call should it not be there.
> So weak symbol does not fill our need for flexibility for the end-user
> (at run-time). Also they have yet another behaviour when used inside a
> shared lib, maybe this can be seen as a linker bug.
Could be. I'll look into this as well after we figure out whether or not
the existing patch is workable or not. I'm hugely busy today...is there
any way you could look at the 19990115 patch and code a quick testcase
that would behave similarly? That would solve the argument right there.
C
Reply to: