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 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