Is your feature request related to a problem? Please describe.
I've tried for hours to build the DLL in 32 and 64 bit. Using Visual Studio, MinGW, and vcpkg. I ended up not being able to solve an issue where it seems to take OpenSSL 3 libraries while expecting OpenSSL 1.1 ones (based on the missing function names from the linker).
Granted I don't use C build environments daily, but I could imagine others feel the same pain. There's issue #1592 which might have a similar issue without details.
Describe the solution you'd like
The Windows binary releases include yara.exe and yarac.exe. It would be great if they would also include libyara32.dll and libyara64.dll (or libyara.dll in two folders).
Hopefully would be no big effort since the build chain that creates the executables is also set up to be able to build the libraries, while for externals, it can be tricky and time consuming.
Probably could be similar for other OS that get executables (.so, .dylib).
Describe alternatives you've considered
A separate release package with the DLLs would work as well.
Additional context
DLLs need to include a version resource pointing to the right version!
I spent probably an hour trying to find the problem with the scan callback not returning the first of four parameters, only to later find out the non-versioned DLLs I had found before where version 3, where the same callback had only three parameters.
Is your feature request related to a problem? Please describe.
I've tried for hours to build the DLL in 32 and 64 bit. Using Visual Studio, MinGW, and vcpkg. I ended up not being able to solve an issue where it seems to take OpenSSL 3 libraries while expecting OpenSSL 1.1 ones (based on the missing function names from the linker).
Granted I don't use C build environments daily, but I could imagine others feel the same pain. There's issue #1592 which might have a similar issue without details.
Describe the solution you'd like
The Windows binary releases include
yara.exeandyarac.exe. It would be great if they would also includelibyara32.dllandlibyara64.dll(orlibyara.dllin two folders).Hopefully would be no big effort since the build chain that creates the executables is also set up to be able to build the libraries, while for externals, it can be tricky and time consuming.
Probably could be similar for other OS that get executables (.so, .dylib).
Describe alternatives you've considered
A separate release package with the DLLs would work as well.
Additional context
DLLs need to include a version resource pointing to the right version!
I spent probably an hour trying to find the problem with the scan callback not returning the first of four parameters, only to later find out the non-versioned DLLs I had found before where version 3, where the same callback had only three parameters.