System.DllNotFoundException in pocketsphinx swig Unity windows build - unity3d

Goal:
Obtain a wrapper dll to use pocketsphinx in a Unity project in Windows.
Problem:
When running the test program, I get an annoying System.DllNotFoundException even though the .so file is in the same directory as the mono program.
Setup and attempted actions:
For starters, I am using Cygwin. I was able to build absolutely everything, sphinxbase and pocketsphinx no problem. Then I went into the swig/csharp directory and attempted make. It does make, a .so file is created. I am using the default Makefile and make in cygwin. Rules 1-3 run perfectly fine, building, linking and everything. So does the pocketsphinx_continuous test.
pocketsphinx.c: ../pocketsphinx.i
mkdir -p gen
swig -I.. -I../../../sphinxbase/swig -I../include -I../../sphinxbase/include \
-csharp \
-dllimport "libpocketsphinxwrap.so" \
-namespace "Pocketsphinx" -o sphinxbase.c \
-outdir gen ../../../sphinxbase/swig/sphinxbase.i
swig -I.. -I../../../sphinxbase/swig -I../include -I../../sphinxbase/include \
-csharp \
-dllimport "libpocketsphinxwrap.so" \
-namespace "Pocketsphinx" -o pocketsphinx.c \
-outdir gen ../pocketsphinx.i
libpocketsphinxwrap.so: pocketsphinx.c
gcc -fPIC pocketsphinx.c sphinxbase.c `pkg-config --libs --cflags pocketsphinx` -shared -o $#
test.exe: libpocketsphinxwrap.so
mcs test.cs gen/*.cs
run: test.exe
MONO_LOG_LEVEL=debug mono test.exe
clean:
rm -rf gen
rm -f libpocketsphinxwrap.so
rm -f pocketsphinx.c
rm -f sphinxbase.c
rm -f test.exe
.PHONY: run clean
When attempting mono test.exe - the following happens:
Unhandled Exception:
System.TypeInitializationException: The type initializer for 'Pocketsphinx.PocketSphinxPINVOKE' threw an exception. ---> System.TypeInitializationException: The type initializer for 'SWIGExceptionHelper' threw an exception. ---> System.DllNotFoundException: libpocketsphinxwrap.so
The .so is in the same directory as the test.exe file and is certainly being looked at because when running mono with MONO_LOG_LEVEL=debug, the output is:
Mono: DllImport error loading library 'C:\Users\fgera\Development\Tools\CMUSphinx\pocketsphinx\swig\csharp\libpocketsphinxwrap.so.dll': 'The system cannot find the file specified.
Many times over and over.
Any help will be greatly appreciated. Again, I need a libpocketsphinx.so x86_64 for windows in Unity to interop with the C# files.
Thanks.
--- edit - added relevant snippet. test.cs just calls this method from the wrapper data structure. These files were all generated by SWIG.
[global::System.Runtime.InteropServices.DllImport("libpocketsphinxwrap.so", EntryPoint="CSharp_Pocketsphinx_Decoder_GetConfig")]
public static extern global::System.IntPtr Decoder_GetConfig(global::System.Runtime.InteropServices.HandleRef jarg1);

I doubt Cygwin DLL is compatible with Mono/Unity. You need to create DLL in Visual Studio, then it will work.

Why do you test the so file with mono, while it is actually used in Unity?
Mono: DllImport error loading library 'C:\Users\fgera\Development\Tools\CMUSphinx\pocketsphinx\swig\csharp\libpocketsphinxwrap.so.dll': 'The system cannot find the file specified.
If file libpocketsphinxwrap.so does exist in C:\Users\fgera\Development\Tools\CMUSphinx\pocketsphinx\swig\csharp\, try rename libpocketsphinxwrap.so to libpocketsphinxwrap.so.dll so mono can find it.
See also mono pinvoke: library names and DllNotfoundException.
You can try build pocketsphinx with Visual Studio since it is offically supported.
BTW, I'd rather write the C# wrapper myself instead of using SWIG since there are many traps in P/Invoke and I don't think SWIG can handle all of them.

Related

gcc49 on Fedora 27: /usr/bin/ld: cannot find -lgcc_s

I am using the davidva/gcc49 copr, on Fedora 27.
When I try to compile after running source /usr/bin/gcc49 as the copr webpage describes, I get this error:
/usr/bin/ld: cannot find -lgcc_s
After learning about how the flag -l works for gcc, I learned it is looking for library gcc_s. I found it in /opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/lib64, which sounds like the right spot for it to be. Why is it not linking? Do I need to add a directory to a library path? If it's LDFLAGS, it's already there because of the file I sourced:
export LDFLAGS="-L/opt/gcc-$gver/$lib/gcc/$gcc_target_platform/$lib/"
What do I need to do to get gcc 4.9 on Fedora 27 to find its library file which is clearly in the LDFLAGS directory?
The problem is that the libgcc_s.so file is in the wrong directory! Just symlink to it in the 4.9.3 directory:
pushd /opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/4.9.3
sudo cp -p ../lib64/libgcc_s.so.1 .
sudo ln -s libgcc_s.so.1 libgcc_s.so
popd
I guess the /opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/lib64 directory was supposed to be included in any LDFLAGS parameter, and that might be a weakness of the build process I was using and not the gcc 4.9 package.
Putting this file and appropriately-named symlink in the 4.9.3 directory allows my build process to complete successfully.
Reference: https://bgstack15.wordpress.com/2018/02/01/gcc-4-9-for-fedora-27/

CMake fails to generate Makefiles with Sun Studio 12.5

I'm working on Solaris 11.3 with Sun Studio 12.5. When I attempt to configure with Cmake out-of-tree, Cmake finishes with configuration errors and does not produce the makefiles. In-tree may be broken, too. But our procedures say to build out-of-tree, so that;' what I do.
I have nearly no Cmake experience. Others contributed the the CMake files, and I struggle with tasks related to them. I'm not sure if I am doing something wrong, if our Cmake files are broken, or if Cmake is not well tested under Solaris.
What is going on with CMake, and how do I fix it?
Here are the links to the Cmake files. I can copy/paste them, but it just takes up a bunch of space. The files are hosted on GitHub so they should always be available.
CMakefileList.txt
cryptopp-config.cmake
Here is Solaris' Cmake version, prior to me installing 3.6.2:
$ cmake --version
cmake version 2.8.6
Below is from Solaris Cmake version 2.8.6.
cryptopp-build$ export CXX=/opt/developerstudio12.5/bin/CC
cryptopp-build$ export CXXFLAGS="-DNDEBUG -g2 -O2 -D__SSE2__ -D__SSE3__ -D__SSSE3__ -D__SSE4_1__ -D__SSE4_2__ -D__AES__ -D__PCLMUL__ -D__RDRND__ -D__RDSEED__ -D__AVX__ -D__AVX2__ -D__BMI__ -D__BMI2__ -D__ADX__ -xarch=avx2_i"
cryptopp-build$ cmake ../cryptopp
-- The CXX compiler identification is unknown
-- Check for working CXX compiler: /bin/c++
-- Check for working CXX compiler: /bin/c++ -- broken
CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake:45 (MESSAGE):
The C++ compiler "/bin/c++" is not able to compile a simple test program.
It fails with the following output:
Change Dir: /export/home/test/cryptopp-build/CMakeFiles/CMakeTmp
Run Build Command:/bin/gmake "cmTryCompileExec/fast"
/bin/gmake -f CMakeFiles/cmTryCompileExec.dir/build.make
CMakeFiles/cmTryCompileExec.dir/build
gmake[1]: Entering directory
`/export/home/test/cryptopp-build/CMakeFiles/CMakeTmp'
/usr/bin/cmake -E cmake_progress_report
/export/home/test/cryptopp-build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building CXX object CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o
/bin/c++ -DNDEBUG -g2 -O2 -D__SSE2__ -D__SSE3__ -D__SSSE3__ -D__SSE4_1__
-D__SSE4_2__ -D__AES__ -D__PCLMUL__ -D__RDRND__ -D__RDSEED__ -D__AVX__
-D__AVX2__ -D__BMI__ -D__BMI2__ -D__ADX__ -xarch=avx2_i -o
CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o -c
/export/home/test/cryptopp-build/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
c++: error: language arch=avx2_i not recognized
c++: error: language arch=avx2_i not recognized
gmake[1]: Leaving directory
`/export/home/test/cryptopp-build/CMakeFiles/CMakeTmp'
gmake[1]: *** [CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o] Error
1
gmake: *** [cmTryCompileExec/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:9 (project)
-- Configuring incomplete, errors occurred!
And:
$ /opt/developerstudio12.5/bin/CC -V
CC: Studio 12.5 Sun C++ 5.14 SunOS_i386 2016/05/31
I built Cmake 3.6.2 from sources and installed in /usr/local to attack the CXX compiler identification is unknown issue, but it appears to be having some troubles. As I said earlier, I'm not a Cmake expert (and I'm not sure how one can mess up a make && sudo make install).
cryptopp-build$ cmake ../cryptopp
CMake Error: Could not find CMAKE_ROOT !!!
CMake has most likely not been installed correctly.
Modules directory not found in
/usr/local/bin
CMake Error: Error executing cmake::LoadCache(). Aborting.
Clearing the cache as suggested by #AndrewHenle results in:
# The project GNUmakefile clears all Cmake artifacts because Cmake cannot seem to do it on its own
$ cd cryptopp
$ git status -s
$
$ cd ..
$ rm -rf cryptopp-build
$ mkdir cryptopp-build
$ cd cryptopp-build
# Using 3.6.2 now
$ cmake ../cryptopp
CMake Error: Could not find CMAKE_ROOT !!!
CMake has most likely not been installed correctly.
Modules directory not found in
/usr/local/bin
CMake Error: Error executing cmake::LoadCache(). Aborting.
So there appeared to be two problems. First was the down level Sun supplied Cmake. There's nothing genius about diagnosing it as "too old".
The second issue was more interesting. It appears the CMake Error: Could not find CMAKE_ROOT !!! was cause by sudo make install Once I switched to sudo gmake install the issue went away.
Here are the bug reports on the issue:
Cmake Issue 16302: Cmake fails to identify Sun Studio 12.5 compiler
Cmake Issue 16303: Cmake fails to produce a working installation on Solaris 11.3

Compiling Freetype 2.6.5 Xcode for IOS

Alright guys, I posted a similar question and took it down because it wasn't specific enough so here I go. From the zip file of Freetype 2.6.5 I have not been able to create an Xcode project that will compile the library for iOS use, only for i386_64.
I tried the commands here but I don't get past the first commands the and I am getting this
FreeType build system -- automatic system detection
The following settings are used:
platform unix compiler cc
configuration directory ./builds/unix configuration rules
./builds/unix/unix.mk
If this does not correspond to your system or settings please remove
the file `config.mk' from this directory then read the INSTALL file
for help.
Otherwise, simply type
/Applications/Xcode.app/Contents/Developer/usr/bin/make' again to
build the library, or
/Applications/Xcode.app/Contents/Developer/usr/bin/make refdoc' to
build the API reference (this needs python >= 2.6).
cd builds/unix; \
./configure 'CFLAGS=-arch i386' /bin/sh: ./configure: No such file or directory make: *** [setup] Error 127
I also followed the instructions inside the cmakelists.txt that it comes inside the project but still nothing, I still get an xcode project for osx and not for IOS which is giving me a plethora of linking errors. Here is the instructions for your reference.
For an iOS static library, use
#
cmake -D IOS_PLATFORM=OS -G Xcode
#
or
#
cmake -D IOS_PLATFORM=SIMULATOR -G Xcode
I am not sure what else to do. Any help?
Here's an outline of the basic build process to compile the FreeType libaries for iOS:
Download the latest FreeType source code
Extract the archive and cd into the unarchived directory
Setup toolchain and export variables for the architectures desired (arm64, arm7, i386, x86_64)
Compile the source code and build the libraries
For example, the build commands for arm64 might look something like this:
$ export CC="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
$ iphoneos="7.0" # target version of iOS
$ ARCH="arm64" # architecture (arm64, arm7, i386, x86_64)
$ export CFLAGS="-arch ${ARCH} -pipe -mdynamic-no-pic -Wno-trigraphs -fpascal-strings \
-O2 -Wreturn-type -Wunused-variable -fmessage-length=0 -fvisibility=hidden \
-miphoneos-version-min=$iphoneos -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/include/libxml2 \
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk"
$ export AR="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar"
$ export LDFLAGS="-arch ${ARCH} -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk \
-miphoneos-version-min=7.0"
$ ./configure --host="aarch64-apple-darwin" --enable-static=yes --enable-shared=no
$ make
$ clean
It's a bit of work to construct the commands for each arch, but
fortunately there's a build
script
— which automatically downloads, extracts, and builds the latest FreeType (2.6.5 currently).
To run the script just use the following command in Terminal:
./build_freetype.sh
The resulting iOS libraries can be found in ~/Desktop/FreeType_iOS_Release when it completes.

command-line library build fails with linker error

I am getting a library not found error building GraphViz current release (June 7 2012) with Xcode 4.3 using a script. I may have made mistakes updating build scripts from other people's successful recipes for the new location of Xcode4.3 and the developer tools in the Applications folder.
ld: library not found for -lcrt1.10.6.o
(doing this from memory so exact number on the CRT lib may be wrong)
Am also a little lost also how I would incorporate this into an Xcode build in the IDE. I am a very experienced programmer but having trouble finding my way around Xcode 4 at times. (Decades of Visual Studio et al).
I have copied the instructions from this earlier question and adapted
#!/bin/sh
# For iPhoneOS, see http://clang.llvm.org/ for options
export DEV_iOS=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer
# was /Developer/Platforms/iPhoneOS.platform/Developer
export SDK_iOS=${DEV_iOS}/SDKs/iPhoneOS5.1.sdk
export COMPILER_iOS=${DEV_iOS}/usr/bin
export CC=${COMPILER_iOS}/clang
export CXX=${COMPILER_iOS}/clang++
export LDFLAGS="-arch armv7 -pipe -Os -gdwarf-2 -mthumb -isysroot ${SDK_iOS}"
export CFLAGS="${LDFLAGS}"
export OBJCFLAGS="${LDFLAGS}"
export CXXFLAGS="${LDFLAGS} -fvisibility-inlines-hidden"
export LD=${COMPILER_iOS}/ld
export CPP=${COMPILER_iOS}/clang
export AR=${COMPILER_iOS}/ar
export AS=${COMPILER_iOS}/as
export NM=${COMPILER_iOS}/nm
export CXXCPP="${COMPILER_iOS}/clang++"
export OBJC=${COMPILER_iOS}/clang
export RANLIB=${COMPILER_iOS}/ranlib
./configure \
--build=arm-apple-darwin11 \
--host=arm-apple-darwin11 \
--disable-dependency-tracking \
--enable-shared=no \
--enable-static=yes \
--enable-ltdl=no \
--enable-swig=no \
--enable-tcl=no \
--srcdir=${GVROOT} \
--with-codegens=no \
--with-cgraph=no \
--with-graph=yes \
--with-expat=no \
--with-fontconfig=no \
--with-freetype2=no \
--with-ipsepcola=yes \
--with-libgd=no \
--with-quartz=yes \
--with-visio=yes \
--with-x=no
The compiler normally uses crt1.o combined with crt[i/n].o and crt[begin/end].o to support the constructors and destructors (functions called before and after main and exit).
This error could be caused by this missing library file for the specific deployment target.
First, do some investigation, like:
list all your deployment targets:
ls -la /Developer/SDKs
and find which crt1 libraries do you have for which environment
find /Developer/SDKs -name crt1\*
You could see something like:
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/crt1.10.5.o
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/crt1.o
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/crt1.10.5.o
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/crt1.10.6.o
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/crt1.o
So as you can see, crt1.10.6.o is missing for MacOSX10.5.
Solution 1:
You can solve that by creating the link to the missing file pointed to the other environment, or you could change your deployment target.
E.g.
ln -s /Developer/SDKs/MacOSX10.6.sdk/usr/lib/crt1.10.6.o /Developer/SDKs/MacOSX10.5.sdk/usr/lib/
Also this could be caused, that you have different gcc installed in your system. See:
which gcc;
xcrun -find gcc;
brew list | grep gcc; brew list gcc47
Solution 2
So when you're compiling using make, you can actually specify the right compiler by CC variable. E.g.
CC=/path/to/gcc-3.4 make
Solution 3
What you can also try is specifying the right target deployment environment variable for gcc, by executing the following lines:
export MACOSX_DEPLOYMENT_TARGET=10.5
export C_INCLUDE_PATH=/Developer/SDKs/MacOSX10.5.sdk/usr/include
export LIBRARY_PATH=/Developer/SDKs/MacOSX10.5.sdk/usr/lib
If this works, then you can add above lines to your shell profile (~/.profile) to make the change permanent.
How to test
Create the example conftest.c file with the following code:
#ifdef __GNUC__
yes;
#endif
And try to compile it via:
gcc conftest.c
cc conftest.c
cc conftest.cc conftest.c
Troubleshooting
To see which exactly what file is missing, try to debug it using dtruss, e.g.:
sudo dtruss -f gcc conftest.c 2>/dev/stdout | grep crt
You should see something like:
12426/0xb4e3b: stat64("/Developer/usr/lib/gcc/i686-apple-darwin10/4.2.1/crt1.10.6.o\0", 0x7FFF5FBFE780, 0xB) = -1 Err#2
So once you found the missing file, then you can follow by the first solution by linking the missing file from existing location (e.g. locate crt1.10.6.o). If you will have other missing symbols, then try another file (check the architecture before by: file `locate crt1.10.6.o`).
E.g.
sudo ln -s /Applications/Xcode.app/Contents/Developer//Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.6.o /Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/crt1.10.6.o
sudo ln -s /Applications/Xcode.app/Contents/Developer//Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.6.o /Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/x86_64/crt1.10.6.o
Related
Error in xcode project: ld: library not found for -lcrt1.10.6.o
If I remember correctly this is what fixed the library not found problem.
CFLAGS="$(OTHER_CFLAGS) -miphoneos-version-min=5.0"
LDFLAGS="$(OTHER_LDFLAGS) --miphoneos-version-min=5.0"
To link this to Xcode, under Build Settings then Header and Library search paths you need to add the paths to the built versions of the library and the header.
You can add the build script as part of your Xcode project, but I haven't had success with this, plus you should only need to build it once per version, so putting the time into anything other than a build script doesn't have much return.
If you decide to put the script in your project anyway (good luck!), then go to the build phases tab, add a build phase of type "Run Script" and paste your script there.

GCC C++ Linker section on FC13

I am trying to get OpenGL and Glut running on Eclipse Linux FC13.
After spending two days on it, I admit that help is needed. On FC13 Eclipse, I see
/usr/include/GL and /usr/include/SDL -- so the libs are there. I started Eclipse, and then tried to run a simple program on it, just like suggested here. However, two things were missing in those steps:
Callisto could not be installed --
nothing was found from the
repository
GCC C++ Linker is not found anywhere
for Eclipse 3.5.2.
When trying to run the program, I see this error:
Program does not exist
and sometimes
Binary not found
If I just run the "hello world" it works, but otherwise, those errors happen every time I try to include glut gl or sdl commands.
Here is an excerpt from the compiler error:
make all
g++ -O2 -g -Wall -fmessage-length=0 -c -o tw.o tw.cpp
tw.cpp: In function ‘void main_loop_function()’:
g++ -o tw tw.o
Yes, apparently the compiler is not able to see the glu, gl, sdl and glut libraries.
Some suggestion on how to fix?
You have to tell the compiler that your program uses additional libraries.
Use the -l argument
g++ -O2 -g -Wall -fmessage-length=0 -lglut -lGL -lGLU -lX11 -c -o tw.o tw.cpp
This should help against unsatisfied link errors.
You can set these in the properties of your Project.
Properties->c/c++ Build->Settings->Tool Settings->Linker
Check if the compiler is able to find the appropriate header files or not. If not, you are sure to get compiler errors. Try using the -I option to set the appropriate paths.
Once you've fixed that, check if there are any linker errors (undefined symbols/references or the sort). If you do: Try to set the library paths using the -L option and ask the compiler to link in the specific libraries by using the -l option. Note that the latter expects something like -lmath where in reality the library being linked in is actually called libmath.so or libmath.a (as the case may be).