Re: glibc and egcs....
Christopher C Chimelis writes:
>
> Ok...the prior messages must have confused me. I'm going to see how this
> build of egcs goes (it's running now). So, let's see if my dense mind
> gets it this time: apply HJL's "12" patch AND the one you sent, right?
>
The problem is that there is several possible choices, that would make
sense. The last one you mention is only one of several, and I am too
little knowledge about gcc/egcs to say which ay we can choose. (maybe
only part of the HJL's "12" patch shoudl be applied or none at all),
The choice that seems to be recommended by HJL was to just take the
last diff he maintains against egcs1.1.1, and do not apply anything
else. Well I guess the egcs Debian maintainers put others
patches for some reasons, so it may be better to take them into
account.
It sould be easier if someone who is familiar with egcs and the HJL
patches could shed some light on the following issues:
1) In the patches that makes crtbegin.o depends on
register_frame_info, there is a tentative try to declare this undefined
symbol as weak, which seems to me a dumb thing to do when a symbol is
undefined (because as far as I can tell the weak declaration has no
effect afterwards). I would be more happy to understand why I am the
stupid one in this regard, and what I missed that makes a undefined
weak symbol different from a regular undefined one in some situations.
2) HLU suggests to remove the register_frame_info reference from
crtbegin.o. Just to satisfy my technical curiosity, why is it not
possible to do this in a uniform manner between platforms, in
particular why couldn't we remove the calls from crtstuff.c which is
used for the x86 crtbegin.o? Moreover, if it is possible to remove this
call on Alpha, by what are they replaced, (or if nothing replace them,
for what purpose were there introduced in the first place)? From what
I understand they are related to C++ exception handling, but that is
mean removing them will have any effect on C++ exception handling?
In conclusion, I am sorry, but I am at a loss to recommend what
exactly shoudl be done, except this is an important issue because one
user has already render its system unusable (or at least gzip/gunzip
which are quite critical components, in particular they would be
unfortunately needed to solve the problem by upgrading).
Regards,
Loic
Reply to: