We need our own libgcc-compat for a leaked __clz_tab
PA,
Problem:
- GCC used to export a symbol for __clz_tab (GLOBAL DEFAULT)
- Everything in debian is being built with newer tools (GCC 3.2).
- Symbol is no longer leaked (LOCAL HIDDEN)
- Libraries that had the leadked symbol are rebuilt (e.g. libcrypto)
- Binaries that had relocations against the symbol are failing (e.g. wget)
Solution:
- Create a libgcc-compat in glibc for the symbol __clz_tab
= Various arches have them for certain symbols that were leaked = from GCC when we the GNU tools didn't have ".hidden" = So examples exist...
- Test the solution to see that atleast "wget" works.
- Put it into Debians glibc as a dpatch.
- Submit upstream for fame and glory.
I'm writing a paper and doing research until Saturday.
If someone feels gutsy enough to attempt a fix, please have at it... If not, it's currently the highest priority item on my TODO.
Cheers,
Carlos.
Quoted 11 lines
Problem:
- GCC used to export a symbol for
__clz_tab(GLOBAL DEFAULT)
- Everything in debian is being built with newer tools (GCC 3.2).
- Symbol is no longer leaked (LOCAL HIDDEN)
- Libraries that had the leadked symbol are rebuilt (e.g. libcrypto)
- Binaries that had relocations against the symbol are failing (e.g. wget)Solution:
Quoted 7 lines
- Create a libgcc-compat in glibc for the symbol
__clz_tab
= Various arches have them for certain symbols that were leaked = from GCC when we the GNU tools didn't have ".hidden" = So examples exist...
- Test the solution to see that atleast "wget" works.
- Put it into Debians glibc as a dpatch.
- Submit upstream for fame and glory.
As I said, this is a generic problem affecting all GCC ports. The correct solution probably isn't adding the symbol to a PA specific libgcc-compat in glibc. I think the matter needs discussion on [email protected]. I'm not sure if there is a reason for hiding this symbol. I would file a GCC PR.
Dave
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6605)