-
Notifications
You must be signed in to change notification settings - Fork 93
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
Please make a release #306
Comments
Issue #294 should be fixed before that too, otherwise lv2 guis are just broken |
To be clear: Calf is currently completely broken (unbuildable) on systems with clang as a major compiler because of the above issue. clang and gcc generally don't mix, so if Jack and other dependencies are built with clang, Calf can't just be built with gcc to work around clang incompatibilities like this. |
where did you hear or seen such things? I have been using clang for testing and mix gcc-built with clang-built libraries without any issues.. |
Here. |
For your info, I plan a bugfix release (0.90.4) in the next weeks. The mentioned #156 and #294 have been solved, aswell as some other bugs, and CI is working (except of MinGW, where I could need some help, but it is not critical). If there are any bugs that you think must make it into the next release, let me know. |
In the FreeBSD port audio/calf-lv2 we have this post-install script that makes the absolute symlink relative:
If this is still happening in the latest revision - this is better to be fixed. |
Then we have this code:
which means that the build fails (or used to fail at some point) when gcc is used without these flags. These were added in 2015, so maybe they aren't relevant any more. |
The latest master revision 04c6ad9 still has this failure not fixed:
We have this patch as a workaround for it in the FreeBSD port:
|
This looks very much like #290 , which has been merged to master. Can you please confirm?
These are all optimization flags. Are you sure that the build really fails without them? Can you make some tests? |
@yurivict About your large diff, the second change ( |
About GCC flags: w/out these flags supplied by the port they are still present in the build - either calf itself adds them, or some dependency adds them. It is irrelevant from the port standpoint. I'll just remove these lines. |
The above patch fixes the "Warning: Linking the executable calfbenchmark against the loadable module". It's better that this is fixed in the master. |
Which do you mean? The one that you provided, or the PR that I linked you? Have you tested whether the linked PR fixes the issue? |
The patch that I've pasted above that comes from the FreeBSD port patch. |
@yurivict I made a few tests to remove the The libtool docs just says that theses modules are "libtool modules": "These are libtool libraries meant to be dlopened. They are indicated to libtool by passing -module at link-time.". That does not sound wrong at first? |
Please keep in mind that libtool and GNU tools in general is an ailing, legacy technology. I'll re-test the latest code in the FreeBSD ports framework today. |
I tried the latest revision 1df3a2a and there are still these warnings:
The build also fails:
|
@yurivict I removed the About the relative symlinks, can you please explain what is the reason for this? My guess is that this is only relevant if you move the installation from the |
@yurivict Friendly Reminder: I could still need your feedback here. It will be valuable to create the next calf release. |
@yurivict Are you still planning to answer here? I think it would be very important. |
Sorry for the delay. This patch has 2 parts.
I believe that the "-module" argument caused the original problem, either through the buggy implementation somewhere in GNU Tools, or through some other reason.
Most packaging systems install files into a stage dir, not into This is well supported by GNU Tools, cmake, etc. We have a very rigorous port/build infrastructure in FreeBSD, and it regularly rebuilds the package calf-lv2-0.90.3.20210427_3. I have high confidence that the linked patch should be good for everybody, because the same ports infrastructure builds thousands GNU Tools based packages without problems. |
I think the comment from the patch is wrong. The symlinks have never been absolute - at least until 2011 (I did not check further). What the patch does is 2 things:
From how I read it, both must have been fixed in 0f567ee . Additionally, I removed In summary, branch
So, can you please confirm if branch |
@yurivict Sorry, I just thought about it again. The links are still absolute. I will change them to relative and let you know then. |
I made some tests. If I run
If I run
However, this behavior has never been changed - it is like that since the first commit of CALF in git. Summary:
|
@yurivict Friendly reminder that I could still need your input here. This is one of the both last issues blocking us from making the next release. |
The last release was in July 2019, which is 2.5 years ago.
Please also make sure that the release builds with clang, because currently it does not.
The text was updated successfully, but these errors were encountered: