Re: qhull external symbols clash
Matti Picus <[email protected]>
| Newsgroups | gmane.comp.python.scientific.devel |
|---|---|
| Message-ID | <[email protected]> |
On 5/1/23 10:10, Andrew Nelson wrote: > On Thu, 5 Jan 2023 at 17:33, Sam Gillingham <[email protected]> > wrote: > > Yes that's the file. It has all the qhull functions exported as > their original names (look for functions starting with "qh_"). > > Problem is if _qhull.cpython-310-darwin.so > <http://qhull.cpython-310-darwin.so> is already loaded and another > library comes looking for qhull symbols it *may* get the scipy > functions instead leading to incompatibility esp. if it is looking > for a different version (as we saw on conda-forge). > > > That's quite interesting. I need to find out more about how symbol > names get resolved. I would've naively thought that if you had the > same function/symbol name in two files called libqhull.so and > _qhull.cpython-310-linux.so <http://qhull.cpython-310-linux.so> then > they would resolve separately, doesn't the loader use the library file > name to find the symbols? > This is not specific to qhull, see similar issues in NumPy [1], [2]. The canonical resource for this is the "How to write shared libraries" (Ulrich Drepper) paper available from [3], particularily the "symbol relocation" section on page 5. In short: linux has a global namespace, and name clashes are a thing. Windows uses a different model: it resolves function locations when linking. I think macOS (which inherits some of this from FreeBSD) manages to better use namespaces, but I am not sure. Matti [1] https://github.com/numpy/numpy/issues/21643 [2] https://github.com/numpy/numpy/issues/10700 [3] https://www.akkadia.org/drepper/dsohowto.pdf [4] https://akkadia.org/drepper/goodpractice.pdf _______________________________________________ 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]