CVS build error with new sort

[Thomas Treichl]

John W. Eaton schrieb:
> On 12-Feb-2008, John Swensen wrote:
> 
> | 
> | On Feb 12, 2008, at 3:45 PM, John W. Eaton wrote:
> | 
> | > Hmm.  I don't think the explicit instantiations in this file should
> | > actually be needed.  I committed the following change.  If you update,
> | > does it work now, or do you still see multiple definitions for some
> | > symbols?
> | >
> | > Thanks,
> | >
> | > jwe
> | >
> | >
> | 
> | That fixed some of them.  I don't get the same error now, but I still  
> | get a linker error when linking liboctave.dylib
> | 
> | ld: duplicate symbol Array<long long>::ArrayRep::length() constin pic/ 
> | Array-so.o and pic/Array-i.o
> | 
> | I didn't include the nm output, grepping for ArrayRep, because it is  
> | very, very long.
> | 
> | Let me know if seeing it will help you figure out where this one is  
> | doubly-defined.
> 
> My guess is that this happens because on your system, std::streamoff
> is a typedef for "long long int".  You can probably avoid the problem
> by commenting out the line
> 
>   INSTANTIATE_ARRAY_AND_ASSIGN (std::streamoff, OCTAVE_API);
> 
> in liboctave/Array-so.cc.
> 
> If it is a typedef problem, then how can we detect automatically at
> configure time so we can avoid the bug?
> 
> BTW, I think this doesn't happen on my system because template
> instantiations produce "weak" symbols.  If there are multiple weak
> symbols with the same name, the linker then uses only one and doesn't
> issue the error message you see.

You're right, if I comment out INSTANTIATE_ARRAY_AND_ASSIGN (std::streamoff, 
OCTAVE_API); in Array-so.cc then linking can be done. I hope this also solves 
all problems on John's Mac?

However, I currently cannot imagine how such a detection could be done. Every 
tip would be greatly helpful here.

   Thomas