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
AVS_linkage macros in avisynth.h break One Definition Rule and cause infinite recursion on linux #130
Comments
Here is the Minimum Reproducible Example: #include <stdio.h>
#include <avisynth.h>
bool foo(VideoInfo* vi) {
vi->IsRGB();
vi->HasAudio();
return false;
}
int main() {
puts("Started");
IScriptEnvironment *env = CreateScriptEnvironment(AVISYNTH_INTERFACE_VERSION);
env->Invoke("Import", "test.avs");
puts("After env->Invoke");
foo(NULL);
puts("Ready to exit");
return 0;
}
|
In Aegisub's source code, It worked when AVS was a Windows only thing, because dll does not export every symbol by default, and internally resolved those symbols. But this is not the case on *nix systems. I understand that I can "workaround" this issue by manually inline those function calls, and hope gcc's optimization will remove these unused problematic symbols. But I don't think this should considered the correct solution. I found this which explained this If the interface still needs to be kept this way, I sugget change internal function to a different name (e.g. prefix an underscore, or use another namespace), and all function calls within AviSynth itself use these internal names. Then the interface functions should only be used outside AVS implementation. |
You probably have to use the C interface with avisynth_c.h |
This is unfortunately something that got inherited from classic AviSynth. I don't recall anything specifically Plus-related that ever messed around with AVS_Linkage. I'm just wondering if this is needed at all on non-Windows and we could get away with putting it behind an AVS_WINDOWS ifdef. There is no straightforward equivalent of the 2.5 interface on *nix (AvxSynth excluded, unless Aegisub can actually work with it), so the compatibility tricks using AVS_Linkage would seem to probably be pretty Windows-specific in the first place. Not least of all because very very very few plugins were ever ported to AvxSynth (offhand I think it was like, five), so any that would otherwise work perfectly with AviSynth+ will almost assuredly get properly fixed up for the modern version of the code anyway (and would need to in order to take advantage of the new features Plus brings in). The AVS_Linkage stuff, as described in the FilterSDK, was at least partially intended to compensate for the breakage and relieve the need to recompile a plugin with the fixes. But that seems like a very Windows-centric concern; Linux development, or *nix more generally, usually kind of pivots around the idea of recompiling things if they've been fixed properly (because it usually is a lot easier to just recompile something there than it is on Windows). If it's possible to keep that kind of compatibility on Windows while just dropping it entirely on *nix, how far would that go toward resolving this? While I certainly would like to see more use of the C interface to talk to the library, I know that's not always possible, and the C++ interface shouldn't end up causing problems like this for the sake of just one platform. |
Finally. What it demonstrates:
Build commands (dunno if /c++11 is really needed - threads)
Important! Specify I just copied the avisynth.h and the avs/ folder right next to the source (-I. option)
We'll have a heap of warnings during the build, nevertheless, output of test:
All this on Ubuntu 19.10, in Windows 10 WSL |
I see the key point is that you are using dynamic load to workaround the conflicting definition issue. It does work, and I additionally added We still need to decide whether AVS should support dynamic / static linking, or only usable via dynamic loading. |
Static build is not supported. See AviSynth/AviSynthPlus#130
* [avisynthplus] Add new port * [avisynthplus] Disable static build Static build is not supported. See AviSynth/AviSynthPlus#130 * [avisynthplus] Ass Supports to CONTROL * [avisynthplus] set static to fail in CI baseline * [avisynthplus] add vcpkg_fail_port_install
I'm trying to compile Aegisub on Archlinux with Avs+ 2fd4156. The compilation finished without warning, but loading a simple avs file will cause SIGSEGV. This issue does not happen on Windows.
I'm not exactly sure if this is an Aegisub issue, or linker issue, or AviSynth issue. So I'm posting here to see if you have any suggestions on how to debug.
Here are some tracebacks:
Version()
: https://paste.ubuntu.com/p/NZPPjfkQVX/Blank()
: https://paste.ubuntu.com/p/fMgZp9H2DX/In Aegisub, it basically calls
But I cannot reproduce this issue with a single file example with the above commands.
Here is the linking command used by Aegisub (
CMakeFiles/Aegisub.dir/src/avisynth_wrap.cpp.o
appears before/usr/lib/libavisynth.so
):The text was updated successfully, but these errors were encountered: