Ansys fluent UDF file not being complied - user-defined-functions

I have tried to build my udf file after adding it. I ran as follows:
tbin\win64/DOF_Sol - Copy.c to libudf\src
udf_names.c and user_nt.udf files in 2ddp_host are upto date.
(system "copy "C:\PROGRA~1\ANSYSI~1\v181\fluent"\fluent18.1.0\src\udf\makefile_nt.udf "libudf\win64\2ddp_host\makefile" ")
1 file(s) copied.
(chdir "libudf")(chdir "win64\2ddp_host")udf_names.c and user_nt.udf files in 2ddp_node are upto date.
(system "copy "C:\PROGRA~1\ANSYSI~1\v181\fluent"\fluent18.1.0\src\udf\makefile_nt.udf "libudf\win64\2ddp_node\makefile" ")
1 file(s) copied.
(chdir "libudf")(chdir "win64\2ddp_node")
Done.
Later while compling it an error is popig up.
Inc\v181\fluent\ntbin\win64\libudf"...
Error at Node 0: The UDF library you are trying to load (libudf) is not compiled for parallel use on the current platform (win64).
The system cannot find the file specified.
Error at host: The UDF library you are trying to load (libudf) is not compiled for parallel use on the current platform (win64).
The system cannot find the file specified.
C:\Program Files\ANSYS Inc\v181\fluent\ntbin\win64\libudf\win64\2ddp_host\libudf.dll
Error at Node 1: The UDF library you are trying to load (libudf) is not compiled for parallel use on the current platform (win64).
The system cannot find the file specified.
Error at Node 2: The UDF library you are trying to load (libudf) is not compiled for parallel use on the current platform (win64).
The system cannot find the file specified.
Error at Node 3: The UDF library you are trying to load (libudf) is not compiled for parallel use on the current platform (win64).
The system cannot find the file specified.
Error at Node 4: The UDF library you are trying to load (libudf) is not compiled for parallel use on the current platform (win64).
The system cannot find the file specified.
Error at Node 5: The UDF library you are trying to load (libudf) is not compiled for parallel use on the current platform (win64).
The system cannot find the file specified.
C:\Program Files\ANSYS Inc\v181\fluent\ntbin\win64\libudf\win64\2ddp_node\libudf.dll
C:\Program Files\ANSYS Inc\v181\fluent\ntbin\win64\libudf\win64\2ddp_node\libudf.dll
C:\Program Files\ANSYS Inc\v181\fluent\ntbin\win64\libudf\win64\2ddp_node\libudf.dll
C:\Program Files\ANSYS Inc\v181\fluent\ntbin\win64\libudf\win64\2ddp_node\libudf.dll
C:\Program Files\ANSYS Inc\v181\fluent\ntbin\win64\libudf\win64\2ddp_node\libudf.dll
C:\Program Files\ANSYS Inc\v181\fluent\ntbin\win64\libudf\win64\2ddp_node\libudf.dll
MPI Application rank 0 exited before MPI_Finalize() with status 2
The fl process could not be started.
error message
I have been running my fluent from vs prompt itself. I had set all the environment paths requied for the execution. The coding is working absolutly fine.

This is common if you have chosen ansys parallel run.
It should be solved by selecting the serial version at the start of Fluent.
Other way is to have PRF_GRSUMx(variable) constructs in your UDF which take care for global summation.

Related

Lua "module 'socket.core' not found"

I'm Trying to import sockets in a lua script to make a twitch chat app inside a game.
The game implementation of lua is "Designed to work with OpenResty’s fork of LuaJIT, with LuaJIT compiled with 5.2 compatibility option." (https://github.com/ac-custom-shaders-patch/acc-lua-sdk/)
I am not familiar with lua but I have been trying to get this to work for a few days but with not much progress.
I have tried different repositories with sockets/websockets but could not get them to work.
when trying local socket = require("socket") I get the following error
[
module 'socket.core' not found: no field package.preload['socket.core']
no file '\socket\core.lua'
no file 'E:\steam\SteamApps\common\assettocorsa\ua\socket\core.lua'
no file 'E:\steam\SteamApps\common\assettocorsa\Jua\socket\core\init.lua'
no file 'C:\Program Files (x86)\Lua\5.1\Jua\socket\core.luac'
no file 'E:\steam\SteamApps\common\assettocorsa\apps\lua\My FirstApp/socket\core.lua'
no file 'E:\steam\SteamApps\common\assettocorsa\extension/internal/lua-socket\core.lua'
no file '\socket\core.dil'
no file 'E:\steam\SteamApps\common\assettocorsa\socket\core.dil'
no file 'E:\steam\SteamApps\common\assettocorsa\Vloadall.dll'
no file '.\socket.dll'
no file 'E:\steam\SteamApps\common\assettocorsa\socket.dll'
no file 'E:\steam\SteamApps\common\assettocorsa\loadall.dll' [C]: in function 'require
...mApps\common\assettocorsa\apps\lua\My FirstApp/socket.lua:12: in main chunk [C]: in function 'require'
...s\common\assettocorsa\apps\lua\My FirstApp\MyFirstApp.lua:13: in main chunk
][1]
If I understood this correctly that socket.core is normally something included in the lua language that would be installed on the machine. But I need this to be included with the app so it can be shared to other people as well.
From my understanding I need something made for lua 5.1 and compiled for windows. The game runs in 64bits by default but can be forced to 32 bits so i'm assuming ideally i'd need 2 dlls.
This is mostly why I've been trying hard to get this particular solution (https://github.com/luapower/socket) to work as they include pre build dlls which I'm assuming contain everything needed for socket to run. But I can't get the error above to go away.
I have also not been able to build my own dll due to my lack of understanding of lua and programming in general and more importantly i'm not sure what to build exactly to make sure it would work for this particular usecase.
The whole lua stuff seems to be super unfriendly to use on windows in general which only adds to my confusion so any insight on how I could proceed to get this to work would be greatly appreciated. I can supply further info neeeded.
edit: it seems that my understanding of where require was looking for files was wrong. I've moved the files to a separate folder and I now get Error: error loading module socket.core' from file '.\socket\core.dll: %1 is not a valid Win32 application. [C]: at 0x7ffd961fb3c0 [C]: in function 'require' ...s\common\assettocorsa\apps\lua\MyFirstApp\MyFirstApp.lua:16: in main chunk
So I guess it's running lua in 32 bits? I tried to grab some compiled socket/core.dll from diff repos and they all give the error.. I checked with dependency walker and some were 32 bits and others were 64bits dlls. Same error regardless.
[1]: https://i.stack.imgur.com/Mdexh.png
Note that there are no commits in [GitHub]: luapower/socket since Nov 2019. Also, the directory structure doesn't seem correct. And (something that should have been mentioned there) it was built (and runs) with Lua 5.1.
I've built v3.0.0 and placed the binaries at: [GitHub]: CristiFati/Prebuilt-Binaries - (master) Prebuilt-Binaries/LuaSocket/v3 (built with Lua 5.4.4 from the same repository, which should be used to run it).
Here's an example:
[cfati#CFATI-5510-0:e:\Work\Dev\StackOverflow\q071876058]> sopr.bat
### Set shorter prompt to better fit when pasted in StackOverflow (or other) pages ###
[prompt]> "c:\Program Files\Lua\Lua\5.4.4\bin\lua.exe" -l socket
c:\Program Files\Lua\Lua\5.4.4\bin\lua.exe: module 'socket' not found:
no field package.preload['socket']
no file 'c:\Program Files\Lua\Lua\5.4.4\bin\lua\socket.lua'
no file 'c:\Program Files\Lua\Lua\5.4.4\bin\lua\socket\init.lua'
no file 'c:\Program Files\Lua\Lua\5.4.4\bin\socket.lua'
no file 'c:\Program Files\Lua\Lua\5.4.4\bin\socket\init.lua'
no file 'c:\Program Files\Lua\Lua\5.4.4\bin\..\share\lua\5.4\socket.lua'
no file 'c:\Program Files\Lua\Lua\5.4.4\bin\..\share\lua\5.4\socket\init.lua'
no file '.\socket.lua'
no file '.\socket\init.lua'
no file 'c:\Program Files\Lua\Lua\5.4.4\bin\socket.dll'
no file 'c:\Program Files\Lua\Lua\5.4.4\bin\..\lib\lua\5.4\socket.dll'
no file 'c:\Program Files\Lua\Lua\5.4.4\bin\loadall.dll'
no file '.\socket.dll'
stack traceback:
[C]: in function 'require'
[C]: in ?
[prompt]>
[prompt]> set LUA_PATH=;;c:\Program Files\LunarModules\LuaSocket\3.0.0(Lua5.4)\?.lua
[prompt]> set LUA_CPATH=;;c:\Program Files\LunarModules\LuaSocket\3.0.0(Lua5.4)\?.dll
[prompt]>
[prompt]> "c:\Program Files\Lua\Lua\5.4.4\bin\lua.exe" -l socket
Lua 5.4.4 Copyright (C) 1994-2022 Lua.org, PUC-Rio
> -- Lua started, meaning the module was successfully loaded
> ^Z
[prompt]> :: Attempt to load the module in Lua 32bit (pc032)
[prompt]> "c:\Program Files (x86)\Lua\Lua\5.4.4\bin\lua.exe" -l socket
c:\Program Files (x86)\Lua\Lua\5.4.4\bin\lua.exe: error loading module 'socket.core' from file 'c:\Program Files\LunarModules\LuaSocket\3.0.0(Lua5.4)\socket\core.dll':
%1 is not a valid Win32 application.
stack traceback:
[C]: in ?
[C]: in function 'require'
...am Files\LunarModules\LuaSocket\3.0.0(Lua5.4)\socket.lua:12: in main chunk
[C]: in function 'require'
[C]: in ?
[prompt]> :: Module structure
[prompt]> tree /a /f "c:\Program Files\LunarModules\LuaSocket\3.0.0(Lua5.4)"
Folder PATH listing for volume SSD0-WIN
Volume serial number is 0000001F F2CE:FA29
C:\PROGRAM FILES\LUNARMODULES\LUASOCKET\3.0.0(LUA5.4)
| ltn12.lua
| LuaSocket.LICENSE
| mbox.lua
| mime.lua
| socket.lua
|
+---mime
| core.dll
|
\---socket
core.dll
ftp.lua
headers.lua
http.lua
smtp.lua
tp.lua
url.lua
As seen, I also covered the pc064 / pc032 .dll mismatch. For more details, check [SO]: Python Ctypes - loading dll throws OSError: [WinError 193] %1 is not a valid Win32 application (#CristiFati's answer).

Log file write error while using Cmake, Ninja, PREFast with MSVC

Turning on the /analyze flag to run PREFast for Windows builds using MSVC non deterministically throws the below error. I think this is because ninja is trying to optimize builds by compiling files from the same target simultaneously but since each target logs to a single file, MSVC is not able to edit the file while another process is writing to the same log file because the file the other process is compiling belongs to the same target.
fatal error C1258: Failed to save XML Log file '<path to log file>.xml'. The process cannot access the file because it is being used by another process.
Can I write to different files per target ?
Can I make MSVC smarter and force it to attempt to write despte another process writing to it ?
I don't want to set paralell jobs to 1 , so do I have any other options ?

Windows Driver build - incorrect path passed to Inf2Cat.exe

I'm new to the subject of windows drivers. I'm trying to build one of the Windows-driver-samples in Visual Studio 2015. The compilation and linking steps pass without errors and then I get the following error:
TRACKER : error TRK0002: Failed to execute command:
""C:\Program Files (x86)\Windows Kits\10\bin\x86\inf2cat.exe"
/os:10_x64 /driver:x64\Debug\WFPSamplerCalloutDriver\".
The operation identifier is not valid.
(Note the relative path in /driver argument). If I call Inf2Cat manually from command prompt with full path to the driver, it passes without a hitch:
C:\Program Files (x86)\Windows Kits\10\bin\x86>Inf2Cat.exe /os:10_x64
/driver:C:\Users\****\Windows-driver-samples\network\trans\WFPSampler\sys\x64\Debug\W
FPSamplerCalloutDriver
...........................
Signability test complete.
Errors:
None
Warnings:
None
Catalog generation complete.
C:\Users\****\Windows-driver-samples\network\trans\WFPSampler\sys\x64\Debug
\WFPSamplerCalloutDriver\wfpsamplercalloutdriver.cat
So, it seems to me that VS somehow failed to provide the full path to the driver in the argument to Inf2Cat.
How can I fix this? Which configuration property of my project is incorrect?
Description
Seems Inf2Cat from SDK10 does not accept directory path format provided by VS Project Configurator. Works when: either output folder name has with no trailing "\" or folder name ends up with "\.".
Workaroud
Disable Inf2Cat under Project Preferences: Run Inf2Cat -> No
Configure build events under Build-Events->Post Build-Event: Command Line -> "$(WindowsSdkDir)bin\$(DDKPlatform)\inf2cat.exe" /os:10_$(DDKPlatform) /driver:"$(ProjectDir)$(IntDir)$(MSBuildProjectName)"

Execution error when out-of stack enviroment, using text-icu on windows

I wrote some code. and fixed some errors with the help of good persons.
Now, this utility(samChecker-exe.exe) works properly in Stack environment.
This utility use text-icu and I coded this utility on windows. Of course, I want to work this utility on other windows OS.
I copied %stackPath%.stack-work\install\~\bin\samCheceker-exe.exe to some other folder, and execution through CMD.
But I got error message that says "libicuuc57.dll dose not exist. so program can't start. please re-install the program."
I copied libicuuc57.dll, and so... as like programming newbies, but failed. "stack install" command was the same result.
(I installed text-icu and installed ICU lib. on windows. The input file encoded in "MS949")
With help of Francesco Ariis from (beginners#haskell.org), I stepped forward.
But still got error message.
C:\Users\shaeg\Documents\Haskell\samChecker3> stack build --ghc-options="-static -optl-static"
Warning: File listed in samChecker3.cabal file does not exist: README.md
samChecker3-0.1.0.0: unregistering (local file changes: app\Main.hs samChecker3.cabal src\Lib.hs test\Spec.hs)
samChecker3-0.1.0.0: configure (lib + exe)
Configuring samChecker3-0.1.0.0...
samChecker3-0.1.0.0: build (lib + exe)
Preprocessing library samChecker3-0.1.0.0...
[1 of 1] Compiling Lib ( src\Lib.hs, .stack-work\dist\ca59d0ab\build\Lib.o )
Preprocessing executable 'samChecker3-exe' for samChecker3-0.1.0.0...
[1 of 1] Compiling Main ( app\Main.hs, .stack-work\dist\ca59d0ab\build\samChecker3-exe\samChecker3-exe-tmp\Main.o )
Linking .stack-work\dist\ca59d0ab\build\samChecker3-exe\samChecker3-exe.exe ...
C:/Users/shaeg/AppData/Local/Programs/stack/x86_64-windows/ghc-8.0.2/mingw/bin/ld.exe: cannot find -licuuc
C:/Users/shaeg/AppData/Local/Programs/stack/x86_64-windows/ghc-8.0.2/mingw/bin/ld.exe: cannot find -licuin
C:/Users/shaeg/AppData/Local/Programs/stack/x86_64-windows/ghc-8.0.2/mingw/bin/ld.exe: cannot find -licudt
collect2.exe: error: ld returned 1 exit status
`gcc.exe' failed in phase `Linker'. (Exit code: 1)
Warning: File listed in samChecker3.cabal file does not exist: README.md
-- While building package samChecker3-0.1.0.0 using:
C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_1.24.2.0_ghc-8.0.2.exe --builddir=.stack-work\dist\ca59d0ab build lib:samChecker3 exe:samChecker3-exe --ghc-options " -ddump-hi -ddump-to-file"
Process exited with code: ExitFailure 1
[stack path] results
extra-include-dirs: C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include
extra-library-dirs: C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib
According to first error message(libicuuc57.dll dose not exist. so program can't start. please re-install the program.), I find the path for libicuuc57.dll, and re-set the extra-library-dirs.
C:\Users\shaeg\Documents\Haskell\samChecker3>stack build --extra-lib-dirs=C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\bin --ghc-options="-static -optl-static"
But got the same result.
libicuuc75.dll, libicuin57.dll etc files is located in C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\bin
Someones says, this is Linker Acting.
How can I fix this error?
Thank you so much.
Sincerely, S. Chang.
Here is my stack path.
C:\Users\shaeg\Documents\Haskell\samChecker3>stack path
stack-root: C:\sr
project-root: C:\Users\shaeg\Documents\Haskell\samChecker3
config-location: C:\Users\shaeg\Documents\Haskell\samChecker3\stack.yaml
bin-path: .;C:\sr\snapshots\7dd4ddea\bin;C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\bin;C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\mingw\bin;C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\bin;C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\usr\bin;C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\usr\local\bin;C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files\Intel\IntelSGXPSW\bin\x64\Release\;C:\Program Files\Intel\IntelSGXPSW\bin\win32\Release\;c:\Program Files\Intel\WiFi\bin\;c:\Program Files\Common Files\Intel\WirelessCommon\;C:\Program Files\Hewlett-Packard\SimplePass\;C:\Users\shaeg\AppData\Roaming\local\bin;C:\Users\shaeg\AppData\Local\Microsoft\WindowsApps
programs: C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows
compiler-exe: C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\bin\ghc.EXE
compiler-bin: C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\bin
local-bin: C:\Users\shaeg\AppData\Roaming\local\bin
extra-include-dirs: C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include
extra-library-dirs: C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib
snapshot-pkg-db: C:\sr\snapshots\7dd4ddea\pkgdb
local-pkg-db: C:\Users\shaeg\Documents\Haskell\samChecker3\.stack-work\install\02136e14\pkgdb
global-pkg-db: C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib\package.conf.d
ghc-package-path: C:\Users\shaeg\Documents\Haskell\samChecker3\.stack-work\install\02136e14\pkgdb;C:\sr\snapshots\7dd4ddea\pkgdb;C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib\package.conf.d
snapshot-install-root: C:\sr\snapshots\7dd4ddea
local-install-root: C:\Users\shaeg\Documents\Haskell\samChecker3\.stack-work\install\02136e14
snapshot-doc-root: C:\sr\snapshots\7dd4ddea\doc
local-doc-root: C:\Users\shaeg\Documents\Haskell\samChecker3\.stack-work\install\02136e14\doc
dist-dir: .stack-work\dist\ca59d0ab
local-hpc-root: C:\Users\shaeg\Documents\Haskell\samChecker3\.stack-work\install\02136e14\hpc
local-bin-path: C:\Users\shaeg\AppData\Roaming\local\bin
ghc-paths: C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows
I was able to test it recently, and share my solution.
First of all, I assume environment of latest msys2 which is installed mingw64/mingw-w64-x86_64-icu 57.1-2 package.
Dynamic linking
Executable which dynamically linked has dependencies to libgcc_s_seh-1.dll libicudt57.dll libicuin57.dll libicuuc57.dll libstdc++-6.dll libwinpthread-1.dll under stack's msys2 mingw64/bin path. If you have already built dynamic linked executable, copying all of them to same directory will solve the problem.
Dependency walker in my comment can help to reveal all of these dependencies.
Static linking
Currently text-icu package doesn't seem to support static linking. So we should modify it ourselves. If you don't know how to make it into local package, note the third option of this.
Modify text-icu-0.7.0.1's .cabal file extra-libraries section to the following.
extra-libraries: sicuin sicuuc sicudt
-- if os(mingw32)
-- extra-libraries: icuin icudt
-- else
-- extra-libraries: icui18n icudata
Append -pgmlC:\Users\[USERNAME]\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\mingw\bin\g++.exe to your executable's ghc-options cabal entry. This is required to link to ICU's C++ symbols.
Then just do stack build.

unable to build OpenH264.lib for windows

I followed all the instruction mentioned in https://github.com/cisco/openh264 but I am unable to get through. The information is cited in link but its quite confusing.
Alternative Way:
You can build Openh264 using visual studio in windows. Here are the steps..
i) Download OpenH264 source code provided by cisco (that already you
mentioned https://github.com/cisco/openh264).
ii) Now you will find two visual studio compatible projects in
directory /OpenH264/codec/build/win32/dec and
/OpenH264/codec/build/win32/enc.
iii) You will need to download NASM software from http://www.nasm.us/pub/nasm/releasebuilds/2.12.02/
iv) Install NASM software on the directory C:\NASM or wherever you like.
v) Then Add NASM executable path to all these visual studio projects.
vi) Then You can either select static or dynamic library in general
options.
vi) If you are able to perform all these operations successfully, you will have 5 different .lib or .dll files named welsdcore, welsdecplus, welsecore, welsencplus, welsvp and those
are usable in any visual studio projects.
Now if you want to get openh264 features, just add all these libraries to your project and enjoy.
Hope it will help you.. :)
I also had some difficulty building openh264 on Windows using the recommended mingw approach.
In my case make crashed for all configurations I tried:
bash -c "make OS=msvc ARCH=x86_64 USE_ASM=No BUILDTYPE=Debug clean"
bash -c "make OS=msvc ARCH=x86_64 USE_ASM=No BUILDTYPE=Debug"
0 [main] make 3888 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
564 [main] make 3888 open_stackdumpfile: Dumping stack trace to make.exe.stackdump
0 [main] make 5448 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
561 [main] make 5448 open_stackdumpfile: Dumping stack trace to make.exe.stackdump
copying dll files to destination folder...
FullDestDir is E:\projects\openh264\bin\x64\Debug
current dir is:
E:\projects\openh264
DestDir is bin/x64/Debug
cp: cannot stat `openh264.dll': No such file or directory
cp: cannot stat `openh264.lib': No such file or directory
cp: cannot stat `openh264.pdb': No such file or directory
cp: cannot stat `codec_unittest.exe': No such file or directory
cp: cannot stat `h264enc.exe': No such file or directory
cp: cannot stat `h264dec.exe': No such file or directory
BuildDebugFlag =1
BuildReleaseFlag =0
BuildDebugInfo ="build debug--failed"
BuildReleaseInfo =NULL
aBuildFlagList is 1 0
ReturnCode is 1
I resorted to converting the existing solution/projects (VS2008) to VS2013 and linking/building with the created .lib files.
You can find the solutions in {openh264_dir}\codec\build\win32\enc and {openh264_dir}\codec\build\win32\dec.
Building the solution will create .libs and .dlls in {openh264_dir}\bin\Win32\Release
To link to the lib, you need to link to welsenc.lib.
When running, you need to have both the welsenc.dll and welsvp.dll in your application directory. So far it seems to have worked fine for my usage.
I'm assuming that building the decoder will be similar.

Resources