duplicate symbols on HP-PA
law@redhat.com
law@redhat.com
Thu Nov 16 15:51:00 GMT 2000
In message <00111617593402.03557@maidavale>you write:
> On Tue, 14 Nov 2000, law@redhat.com wrote:
> > That message has been popping up for about 6 years, we've only had weak
> > symbol support for the last 6 months :-)
>
> [HP linker message:
> WARNING: LIBRARY <archlib>.a HAS OVERFLOW SYMBOLS; USE CLEANRL]
>
> When you got it 6 years ago, was it with C and "normal" length (~32)
> symbols, or with C++ and mangled monster symbols?
Unknown. I can't remember a time when I haven't received this message.
> Any other idea or a feeling under what circumstances that message pops up?
Not really. And to the best of my knowledge it doesn't affect the behavior
of the tools (if I had seen it have an impact on the behavior of the tools
I would have debugged it by now :-)
> But maybe the problem is unrelated to that message.
> I think that is what you are suggesting.
That is exactly what I am suggesting.
> But doesn't it need an `.EXPORT' directive to be shared with other compilat
> ion units?
All symbols with visibility outside of the current .o need to be exported.
> (I suppose $PRIVATE$ means privately mapped vmem, rather than local to comp
> unit.)
Close enough. The term HP uses is "load unit", ie a program or shared
library.
It is very likely that you're going to have to hack the assembly output to
test whether or not we can use commons to get the behavior your want. It
clearly doesn't do what you want right now.
> The CVS version emits
> .SPACE $PRIVATE$
> .SUBSPA $BSS$
> .align 4
> <local_var_name>___<disambiguating_counter>
> .block 12
>
> No `.EXPORT' or `.weak' for the (in C++) local static variable.
> So the symbol is still local, but no longer common.
Right.
jeff
More information about the Gcc-bugs
mailing list