-
Notifications
You must be signed in to change notification settings - Fork 6
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
Comments
To be honest, I’m having a hard time figuring out why /usr/bin/cmake -S . -B build -DBUILD_SHARED_LIBS:BOOL=ON --trace it looks like Line 1866 in 318155d
is executed, but |
@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. |
Thanks! Let me know if I can do anything to help. |
@biojppm, did you have any luck figuring out why this was happening? Thanks! |
Sorry, forgot about this. I investigated and turns out the proper name is I don't know how it worked before, but there it is. |
Thanks! This now seems to work as intended. |
I’ve packaged
c4core
,c4log
, andc4fs
on Fedora Linux in preparation for packagingrapidyaml
(almost done!)The change in 436b163 means that these libraries no longer have an
SONAME
, so I would have to either: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!
The text was updated successfully, but these errors were encountered: