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

Intent of removing .so versions from c4core/c4log/c4fs? #8

Closed
musicinmybrain opened this issue May 27, 2022 · 6 comments
Closed

Intent of removing .so versions from c4core/c4log/c4fs? #8

musicinmybrain opened this issue May 27, 2022 · 6 comments

Comments

@musicinmybrain
Copy link
Contributor

I’ve packaged c4core, c4log, and c4fs on Fedora Linux in preparation for packaging rapidyaml (almost done!)

The change in 436b163 means that these libraries no longer have an SONAME, so I would have to either:

  1. start versioning the libraries downstream (basically, carry a patch reverting this commit forever)—which is feasible—or
  2. give up on packaging these libraries separately from rapidyaml—which I am permitted to do, subject to conditions, if I absolutely have to, but which has disadvantages from a distribution packager’s point of view.

Is this the intended effect of this commit? Does it solve a problem in a different environment? Can it be conditionalized such that I can turn versioning back on when packaging system copies of these libraries?

Thanks!

@musicinmybrain
Copy link
Contributor Author

To be honest, I’m having a hard time figuring out why c4core and friends now don’t have shared library versioning when built as standalone shared libraries. When I build c4project using

/usr/bin/cmake -S . -B build -DBUILD_SHARED_LIBS:BOOL=ON --trace

it looks like

set_target_properties(${target} PROPERTIES SO_VERSION ${${_c4_prefix}_VERSION})

is executed, but libc4core.so remains unversioned.

@biojppm
Copy link
Owner

biojppm commented Jun 2, 2022

@musicinmybrain sorry for the late reply, I missed this.

c4core and friends are definitely meant to have versioning - that's why that is done in this project, so that any lib that uses this is dealt with in the same way. I will try to figure this out.

@musicinmybrain
Copy link
Contributor Author

c4core and friends are definitely meant to have versioning - that's why that is done in this project, so that any lib that uses this is dealt with in the same way. I will try to figure this out.

Thanks! Let me know if I can do anything to help.

@musicinmybrain
Copy link
Contributor Author

@biojppm, did you have any luck figuring out why this was happening? Thanks!

biojppm added a commit that referenced this issue Aug 2, 2022
@biojppm
Copy link
Owner

biojppm commented Aug 2, 2022

Sorry, forgot about this.

I investigated and turns out the proper name is SOVERSION rather than SO_VERSION.

I don't know how it worked before, but there it is.

@biojppm biojppm closed this as completed Aug 2, 2022
@musicinmybrain
Copy link
Contributor Author

[…] I investigated and turns out the proper name is SOVERSION rather than SO_VERSION. […]

Thanks! This now seems to work as intended.

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

No branches or pull requests

2 participants