Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature request] Allow linking a single non-versioned shared object #4468

Closed
mattip opened this issue Jan 31, 2024 · 7 comments · Fixed by #4485
Closed

[Feature request] Allow linking a single non-versioned shared object #4468

mattip opened this issue Jan 31, 2024 · 7 comments · Fixed by #4485

Comments

@mattip
Copy link
Contributor

mattip commented Jan 31, 2024

Over a few PRs to MacPython/openblas-libs, I changed the end result to be a Python wheel. This required packaging a single shared object with no symbolic links. I needed to

  • use a prefix so the shared object is unique and can be globally loaded along side a different OpenBLAS build
  • changed the Makefiles to allow building a single shared object, with no versioning and no symlinks
  • changed the pkg-config file to reflect this

Here is the patch to OpenBLAS 0.3.26 to remove all the symlinking and versioning. Note the prefixing requires this line and this change in order to support prefixes in the pkg-config file. The rest of the patch is "just" removing things.

Would you be open to merging these changes, toggled with a build option, to reduce openblas-lib's maintenance burden?

@martin-frbg
Copy link
Collaborator

this looks a bit like PR #4252 ? (that I haven't had time to address properly yet)

@mattip
Copy link
Contributor Author

mattip commented Jan 31, 2024

Yup, it seems so. Anything I can do to help move that one along?

@martin-frbg
Copy link
Collaborator

I hope to get to this now, with the other issues out of the way

@martin-frbg
Copy link
Collaborator

hmm, I'm slightly confused by your patch to openblas.pc.in

-Libs: -L${libdir} -lopenblas${libsuffix}
+Libs: -L${libdir} -l${libprefix}openblas${libsuffix}

which I would have expected to be something like ${libprefix}.${libsuffix} ?

@mattip
Copy link
Contributor Author

mattip commented Feb 5, 2024

The prefix I am thinking of goes before openblas. So in my case, where libprefix is scipy_ and libsuffix is 64_, the shared object generated is libscipy_openblas64_.so.

@martin-frbg
Copy link
Collaborator

I'm getting a feeling the makefiles have grown some unhealthy mix of automatic and manual prefix and suffix options lately.

@martin-frbg
Copy link
Collaborator

martin-frbg commented Feb 8, 2024

#4485 implements the basic idea but I still need to sort out the dual use of LIBPREFIX which is an internally generated variable already. (This also needs porting to cmake and integrating with the most recent realization from #3998 that symbol rewriting does not work when applied directly to a shared library ,as it is currently done in the cmake build)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants