Re: A multiple definition error in Creating library file: liboctave.dll.a (gcc-4.3.2-dw2-TDM for mingw )

[Jaroslav Hajek]

On Sat, Feb 14, 2009 at 8:46 PM, Jaroslav Hajek <address@hidden> wrote:
> On Sat, Feb 14, 2009 at 4:55 PM, Benjamin Lindner <address@hidden> wrote:
>>>>>
>>>>> Creating library file: liboctave.dll.a
>>>>>
>>>>> Sparse-C.o:Sparse-C.cc:(.text$_ZN11octave_sortISt7complexIdEE17ascending_compareES1_S1_[octave_sort<std::complex<double>
>>>>>>
>>>>>> ::ascending_compare(std::complex<double>, std::complex<double>)]+0x0):
>>>>>
>>>>> multiple definition of `octave_sort<std::complex<double>
>>>>> >::ascending_compare(std::complex<double>,
>>>>> std::complex<double>)'
>>>>>
>>>>> Array-C.o:c:\usr\Tatsu\mingwhome\octaves\octave-3.1.52\liboctave/Array-C.cc:44:
>>>>> first defined here
>>>>>
>>
>> This double-definition error occurs, because of different implementations in
>> the coding in Array-C.cc and Sparse-C.cc.
>> Array-C.cc defines a total template specialization of
>>  octave_sort<Complex>::sort_ascending(const Complex&, const Complex&)
>> and
>>  octave_sort<Complex>::sort_descending(const Complex&, const Complex&)
>> whereas Sparse-C.cc provides versions for
>>  operator<(const Complex&, const Complex&)
>> and
>>  operator>(const Complex&, const Complex&)
>> which are then used with the instantiated template function
>>  octave_sort<T>::sort_ascending(const T&, const T&)
>> and
>>  octave_sort<T>::sort_descending(const T&, const T&)
>> provided in octave-sort.cc.
>>
>> I'm not sure this why this asymmtery,
>
> because I adapted the Array code to the improved octave_sort
> interface, but didn't yet do so for Sparse.
>
>> but changing the code in Array-C.cc to
>> define operator< and operator> as in Sparse-C.cc removes the
>> double-definition linker error.
>>
>> Please consider the attached changeset.
>>
>
> Sorry, but this is the wrong way to go. One of the aims of the new
> octave_sort design is to not require the type to have < and >
> operators. Here a proper solution needs to prevent re-instantiation of
> octave_sort<Complex> in Sparse-C.cc, because one instantiation (in
> Array-C.cc) suffices. Similarly for Array-d/Sparse-d and
> Array-b/Sparse-b. Apparently gcc on Linux is somehow able to do it
> automatically.
> You cannot, however, simply vipe out the definitions from the Sparse
> codes because Sparse.cc still uses the vec_index sorts, which need to
> be instantiated. So, we can either do a quick fix by moving the
> vec_index sort definitions to sparse-sort.cc, or simply update the
> code in Sparse.cc to use the indexed sort methods and simply do not
> instantiate any more sorts in the sparse code.
> Unless someone takes up the latter approach, I'll probably do the quick fix.
>
>> BTW I also see that the code for comparing two Complex values differs in
>> Sparse-C.cc and Array-C.cc. Is this intentional?
>
> Yes. But it does not need to be so, if the NaNs are pre-partitioned
> out like they are in Array::sort.
>
>> benjamin
>>
>
> --
> RNDr. Jaroslav Hajek
> computing expert
> Aeronautical Research and Test Institute (VZLU)
> Prague, Czech Republic
> url: www.highegg.matfyz.cz
>

Update: The problem should be solved in the development archives:
http://hg.savannah.gnu.org/hgweb/octave/rev/06b9903a029b

regards

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz