[Octave-bug-tracker] [bug #61711] Test errors for sorting NaN values on Windows with visibility flags

[Markus Mützel]

Follow-up Comment #6, bug #61711 (project octave):

I pushed a changeset here that should help to avoid the build error:
https://hg.savannah.gnu.org/hgweb/octave/rev/fa025af77216

This still leaves us with how we should generally fix the issue that implicit
instantiations on Windows (and maybe other platforms?) in one library might
lead to missing specializations from another library.
But at the same time: If we prevent implicit instantiations, we need to make
sure that all (necessary) constructors and member functions are exported from
the library that contains the specialized instantiation. That includes also
those functions that aren't specialized.

One way to do the first part could be to:
- Rename "Array.cc" in liboctave to, e.g., "Array-base.cc".
- Add a new file in liboctave that includes "Array-base.cc" followed by
`extern template Array<T>` declarations for all types that are exported from
the liboctave library. That would prevent (accidentally) instantiating the
template class implicitly with those types again where that file is included.
That file could be called "Array-oct.cc".
- Everywhere where we currently include "Array.cc" in libinterp, we could
include "Array-oct.cc" instead.
- Add a new file to libinterp that includes "Array-oct.cc" followed by `extern
template Array<T>` declarations for all types that are exported from the
liboctinterp library. (Same motivation as for "Array-oct.cc".) That file could
be called "Array.cc".
- Install these three files with Octave.

That way third-party code that currently includes "Array.cc" could continue
doing that if they link against the liboctinterp library. Third-party code
that *only* links against liboctave (but not liboctinterp) would need to
include "Array-oct.cc". In either case, including those files would prevent
(accidentally) instantiating the template class implicitly with types that
should be used in the definition from the libraries.

For the second part of the task, the only way that I can currently think of is
splitting the declaration of the Array<T> template class from its definition
completely. But I'm open to other ideas.



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61711>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/