Re: qhull external symbols clash

On Tue, Jan 3, 2023 at 11:50 AM Sam Gillingham <[email protected]>
wrote:

> Hi SciPy maintainers,
>
> I'm keen to hear your thoughts on the following problem:
> Currently, SciPy has its own internal copy of qhull. If a script also
> imports something else that uses libqhull (of a different version) there
> can be a crash due to both versions of qhull exporting the same symbols.
>

Thanks for bringing this up Sam. It looks like there is a problem indeed. I
just reopened https://github.com/scipy/scipy/issues/7203, which has the
only previous bug report on this that I could find.



> This has recently been a problem in conda-forge when the GDAL library
> started linking against external libqhull:
> https://github.com/conda-forge/qgis-feedstock/issues/284
>
> As I see it, there are 2 possible solutions:
>
> 1. Use a similar approach to GDAL (when using its own internal copy of
> qhull) and rename all qhull symbols so they are unique (see
> https://github.com/OSGeo/gdal/blob/master/alg/internal_qhull_headers.h)
>
> 2. Allow external libqhull to be linked against in the SciPy build process
> (instead of the internal version). This would mean all software imported in
> a script can use the same libqhull.
>

The problem with (2) is that we turn a build problem into a dependency
problem - which is not good. It implies either supporting a range of Qhull
versions rather than one specific version. Or we ask for one exact version,
but then it doesn't help conda-forge because it ties upgrades of GDAL and
SciPy together.

Another thought that comes up here is that this issue is probably not
limited to Qhull. It gets triggered for Qhull here because it does an
internal check - but we have other vendored libraries like HiGHS and
SuperLU where we don't rename symbols and that can cause problems.

And yet another: we've had requests for unvendoring Boost, which is a
similar thing. A thing I had on my TODO list was to allow this: search for
the one specific version on the system that we support, and only fall back
to the vendored copy if it cannot be found externally.


I'm happy to open a pull request if either of the above options is
> acceptable.
>

The GDAL symbol renaming seems pretty clean. I think that's the main way to
go, a PR for that would be great. And then optionally, we can allow using
an external library as a second step- if and only if the version matches
our internally vendored version.

Cheers,
Ralf

_______________________________________________
SciPy-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/scipy-dev.python.org/
Member address: [email protected]