duplicate symbols on HP-PA

[law@redhat.com]

  In message <200011141536.PAA28045@maidavale.thyron-local>you write:
  > It may well be connected with my problem and the one that Dave had before. 
  >  If
  > I understand him right, Dave too had weak symbols duplicated when that mess
  > age
  > occurred.
That message has been popping up for about 6 years, we've only had weak
symbol support for the last 6 months :-)  

  > The som archive library support being hokey,
  >  would you recommend using shared libraries instead?  
The hokeyness is mostly an implementation detail -- from the user standpoint
they should work just fine.

  > BTW, are there any plans for an HP port of the GNU linker? 
Not for SOM.  It's probably a year or more of effort for a platform which
becomes less and less important every day.  We have GNU ld support for
PA64 (which is ELF based, and in typical HP fashion, hacked in strange and
mysterious ways).

  > It must be nearly impossible then to correctly implement weak symbols on
  > topp of sdef.  Amazing that it works so well...
Agreed.  A fair amount of the implementation was guesswork and experimentation.
Not a particularly good way to code, but such is life (ie, coding to an
implementation is bad.  Coding to a specification is good).

  > Do I understand correctly that weak symbols are needed only as a vehicle fo
  > something else, not in their own right (apart from the __attribute__
  > specification)?  
  > 
Correct.

  > If so (and even if not), could the effect of folding in-line-defined functi
  > on
  > instantiations not be achieved by some other mechanism that relies on more
  > widely well-supported features: 
Unsure.

  > One approach that would not hurt on other platforms could be using global
  > (fortran and traditional C style) common rather than local symbols for the
  > local static data.  Then, if the folding of the function text fails due to
  > problems with the native linker, at least the data are folded to get correc
  > t
  > semantics.  (It is not only size that matters.)  As far as I understand it,
  > staying ISO C++ conform while making local data (or anything without extern
  > al
  > linkage) global for the linker is a mere mangling issue.
Yes, this is another approach.  I don't know if anyone has tried it to see
if HP's linker supports it.


  > That is probably also the only way to actually inline functions correctly t
  > hat
  > have static data, at least when you have no working weak support.  How is t
  > hat
  > being done now?  Not at all, common, weak or wrong?
Unknown.  I'm a low level guy, I just move the bits :-)

  > In the case of my problem, the functions were emitted (no inlining, -O0)
  > multiply in different translation units and as weak, each with their local
  > static data as local rather than weak or common.  Common should have worked
That sounds like a bug to me.  Probably in the compiler itself since it seems
to me it should have arranged for the local data to be weak or common.

jeff