Can you help me with the steps to link/import Crypto++ library to OMNeT++ framework properly, please.
I use OMNeT++ 5.0/inetmanet 3.0 version (Windows 10).
OMNeT++ on windows is a C++ simulation library that is built in MinGW environment with GCC (on windows). As such, everything that applies to a general program applies here. You need to have the crypto++ headers in the /tools/win32/mingw32/include folder, the libraries in the tools/win32/mingw32/lib and the dll in the bin directory...
You may be able to install the library and the headers with:
pacman -Su mingw-w64-i686-crypto++
After that you can just use the include file of the library as usual. You have to add the crypto library to the linker command line (in the IDE: Project / Properties and add the library in the "Makemake" dialog on the Libraries tab.
Related
I'm using Visual studio 2019
I followed this link to install wxWidget using vcpkg install wxwidgets
https://www.wxwidgets.org/blog/2019/01/wxwidgets-and-vcpkg/
and read this link
https://computingonplains.wordpress.com/using-visual-studio-2017-to-build-wxwidgets/
and this
https://devblogs.microsoft.com/cppblog/vcpkg-updates-static-linking-is-now-available/
the problem after installing wxWidget using vcpkg the result build is Dynamic library and I want to compile my project as static library to run exe file on other users pc .
I want to change from Dynamic lib compilation to static due to :
users on another PCs get VCRUNTIME error so they have to install VC++ runtime library as I read in
How to fix a missing vcruntime140 clr 400 dll error
Summary of the problem :
vcpkg installation wxwidgets result is dynamic lib configuration and I need to install static one .
Instead of just doing vcpkg install wxwidgets
use vcpkg install wxwidgets:x64-windows-static
This will install wxwidgets and all it dependencies with static runtime and library linkage.
You can also define your custom triplet if you want to customize your build setup (see https://github.com/microsoft/vcpkg/blob/master/docs/users/triplets.md)
#MohmmedAlaa,
You are better off compiling the library yourself.
There is a big difference between compiling the project with wxWidgets being dynamic vs static and VC++ RT dynamic vs static.
Also, keep in mind that some VC++ RT is not licensed to be distributable.
So all in all - get the wxWidgets sources, install MSVC, build static libraries (possibly with the compiler switch to use "static RT) and compile your software.
I have received an SDK that is used to build c++/c applications for an embedded linux device. This is all new to me so some of my terminology may be wrong.
I followed their instructions and the SDK installs on my linux (ubuntu) system in /opt/. The compiler they are using appears to be arm-poky-linux-gnueabi-gcc. Part of their SDK sets some environment variables, like $CC and CPP for compiling C/C++. The environment variables run something like arm-poky-linux-gnueabi-gcc -march=armv7-a (and a bunch of other flags).
My question is: how can I utilize this using cmakelists/cmake? I currently have an entire library and application that is built around cmake.
The SDK should come with a toolchain file for cmake (for example named toolchain.cmake).
When you first call your cmake, you force it to use the SDK like this:
cmake -DCMAKE_TOOLCHAIN_FILE=/opt/???/toolchain.cmake.
I have included an external package callled SoPlex (a folder of .cpp and .h files and the library files) into my OMNet++ project. I have already tested the package in Code::Blocks IDE and it works fine besides some warnings it had: warning: explicit conversion operators only available with -std=c++11 or -std=gnu++11.
It certainly was working in Code::Blocks IDE. But when I want to use it in my OMNet++ project it gives a lot of errors for the SoPlex package like in the picture:
It gives a lot of errors for just the code of SoPlex and not my OMNet++ project code.
Any idea what may cause the problem?
I have used MinGW to compile SoPlex package in Code::Blocks IDE. When I use MinGW GCC in OMNet++ instead of GCC for OMNet++ as current toolchain there is this error fatal error: omnetpp.h: No such file or directory.
Regarding the errors with the 3rd party library. Depending where you put the library inside the src folder, at least that directory must be added as an include dir, otherwise the header files will not be found by the compiler.
As for the problem with the omnetpp.h: OMNeT++ has it's own makefile generator which automatically adds the required include folder (omnetpp_root/include). The generic MinGW GCC toolchain does not. If you want to avoid extra work, always use the omnet toolchain to build your models.
I have an application coded in c# using the Mono Framework and GTK# for UI.Im trying to create a static bundle for MacOSX (including gtk# and mono runtime)
I just bundled Mono with my exe file using
mkbundle --static hello.exe -o --deps hello2.exe
I got the exe file but when i drag it and put it on the terminal i get System.DllNotFound Exception:glibsharpglue-2
I understand that i need to include the gtk# libraries.But i dont know how to do that with a statically linked mono runtime.Is there an option to do that using mkbundle.All i need to get is a final standalone package ready to run on Mac.
Please help me out.
UPDATE:
The shell script I'm currently using with Platypus to make the .app package
export DYLD_FALLBACK_LIBRARY_PATH="/Library/Frameworks/Mono.framework/Versions/Current/lib:$DYLD_FALLBACK_LIBRARY_PATH:/usr/lib"
exec /Library/Frameworks/Mono.framework/Versions/Current/bin/mono myapp.exe
Im currently using the option provided in platypus to include myapp.exe file.How can i include the dlls required for GTK? Please help me out.
The error is from not finding the GTK shared object libraries (SO/dylib).
Using mkbundle:
If using 32-bit Mono you will need to assign the arch type for AS and CC. By default, clang will compile and link x86_64 which may not match your installed Mono's arch type.
export AS="as -arch i386"
export CC="cc -arch i386 -framework CoreFoundation -lobjc -liconv"
mkbundle gtkdesigner.exe --deps -o gtkdemo
The resulting executable will still require Mono (and any dependant shared objects/dylibs) to be installed.
Or adding --static to statically link to mono libs and thus invoking the LGPL of Mono (you will need to distribute your original CIL images so the user can upgrade the version of Mono that is running your app, unless you have a license from Xamarin)
mkbundle --static gtkdesigner.exe --deps -o gtkdemo
The resulting executable will not require Mono to be installed, but any dependant shared objects/dylibs will still be required.
GTK/GTK# based applications:
A GTK# based application will still require the GTK shared objects/dylibs to be installed and accessible by the resulting executable (i.e. gtkdemo in this case):
Thus if you try to run ./gtkdemo it will need to find shared libraries such as libc.dylib, libgtksharpglue-2.so, etc, etc... otherwise the error you are getting will be shown.
Set the dylib library path to your GTK libraries, not the C# CIL binding library (GTK#), but the native shared object libraries. Since you have Mono installed on OS-X, it also installs its own version of GTK that can be found at /Library/Frameworks/Mono.framework/Versions/Current/lib. If you are installing your own version GTK to a different location just change the path to that location. You also will be to include the location of the OS's std C library.
export DYLD_FALLBACK_LIBRARY_PATH="/Library/Frameworks/Mono.framework/Versions/Current/lib:/usr/lib"
./gtkdemo
Note: You can package this gtkdemo application into a normal OS-X app by using a packager tool such as http://sveinbjorn.org/platypus. Package all the GTK libraries and any other required so/dylibs into the app and provide a shell script that assigns the DYLIB path in order to find those app based GTK libs. Then you can distribute the self-contained app and the end-user just double-clicks it to run you GTK-based app.
Since gkt# is an open-source library why not download the code?
You would need to install git and do:
git clone https://github.com/mono/gtk-sharp
Then, you can reference those donwloaded gtk-sharp projects directly in your solution.
Note: i believe you still need the native OSXs gtk libraries since gtk-sharp is a wrapper of those libs.
I have a C# application that uses SQLite and works fine on Windows.
The same Visual Studio project compiles fine in Xamarin Studio, but when running I get:
DllNotFoundException: SQLite.Interop.dll
Despite:
libsqlite3.0.dylib is in /usr/lib and also in the same folder as the executable and other DLLs
. is part of the $DYLD_LIBRARY_PATH
The executable and all SQLite-using DLLs have a matching <the_exe_or_dll_including_filename_extension>.config file containing:
<configuration>
<dllmap dll="sqlite" target="libsqlite.0.dylib" os="osx"/>
<dllmap dll="sqlite3" target="libsqlite3.0.dylib" os="osx"/>
</configuration>
I also tried adding <dllmap dll="SQLite.Interop.dll" target="libsqlite3.0.dylib" os="osx"/>, not better.
What is the problem?
You can easily find where mono is looking for that native library by setting the MONO_LOG_LEVEL to debug and MONO_LOG_MASK filtering to only DLL related messages.
export MONO_LOG_LEVEL=debug
export MONO_LOG_MASK=dll
mono yourprogram.exe
or as a one liner so you do not have to unset env vars:
MONO_LOG_LEVEL=debug MONO_LOG_MASK=dll mono yourprogram.exe
Mono and the OS-X dynamic link editor ('man dyld' for details) does not require DYLD_LIBRARY_PATH to be set to the current directory ('.'). Note: Linux does require LD_LIBRARY_PATH to include the current directory, if that is your intention.
Move those dll map files out of the way to remove them from the equation.
Unset DYLD_LIBRARY_PATH
cd in the directory that contains your CIL based exe, dlls and native dylib(s)
MONO_LOG_LEVEL=debug MONO_LOG_MASK=dll mono yourprogram.exe
Using the native dll/shared library trace output you can track which library is not being found (or one of its dependancies) or if it is the wrong ARCH for your mono version.
If you are still having problems, we would need to know which SQLite library you are using the options that you are using to compile it (or the arch version if getting it via a Nuget). A posting your dll trace output would quickly solve things also.
Notes:
I am assuming you are using the System.Data.SQLite library and are compiling the the options "/p:UseInteropDll=true /p:UseSqliteStandard=false".
Mono includes a SQLite in it's default install, it is 32-bit on OS-X:
file /Library/Frameworks/Mono.framework/Versions/4.0.2/lib/libsqlite3.dylib
/Library/Frameworks/Mono.framework/Versions/4.0.2/lib/libsqlite3.dylib: Mach-O dynamically linked shared library i386
Assuming you are using the OS-X package installer from Mono, thus are getting the 32-bit version of Mono and thus need 32-bit versions of the native libraries.
>>file `which mono`
/usr/bin/mono: Mach-O executable i386
The /usr/lib/libsqlite3.0.dylib is a multi ARCH fat binary, so that library is not a problem, but your debug output might show another one that is a problem,
>>file /usr/lib/libsqlite3.0.dylib
libsqlite3.0.dylib: Mach-O universal binary with 3 architectures
libsqlite3.0.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
libsqlite3.0.dylib (for architecture i386): Mach-O dynamically linked shared library i386
libsqlite3.0.dylib (for architecture x86_64h): Mach-O 64-bit dynamically linked shared library x86_64
You need to build and supply SQLite.Interop.dll (or more precisely libSQLite.Interop.dylib). The Mono distribution packages don't include it, probably because it's native code and really needs to be built on the target platform.
System.Data.SQLite on Windows uses a mixed mode approach (Managed data adapter + sqlite native code in one assembly). Mono however doesn't really support mixed mode assemblies.
So on MacOS there are two alternatives when it comes to building System.Data.SQLite on Windows:
Use interop dll.
Use libsqlite.x.x.dylib.
Both of these are native code and need to be built on the Mac.
Interop is Windows com speak so it's a bit disconcerting to see it used in a MacOS context. What this native dll is is the sqlite source code compiled up with some additional native code that can be P\Invoked by System.Data.SQLite. There are some benefits to using the interop dll as opposed to the sqlite dylib.
System.Data.SQLite ships with a copy of the relevant SQLite native source code in ./SQLite.Interop/src.core. You can build the interop library by running compile-interop-assembly-release.sh on the Mac. This will build libSQLite.Interop.dylib. Drop that in beside System.Data.SQLite and you should be good to go.
If you turn on Mono dll tracing you can watch the loader (see mono 4.8.0 loader.c) searching for the dll in various locations and with various name substitutions. Eventually it finds our dylib. It is also possible to use a dllmap entry in the System.Data.SQLite.dll.config file to direct the runtime to the dll. In my case Mono is on my app bundle so I have:
<dllmap dll="SQLite.Interop.dll" target="#executable_path/../Mono/libSQLite.Interop.dylib" os="!windows"/>
The dllmap target argument is passed to dlopen() so #executable_path et al are all usable.
I prefer this approach as it goes into the repo and provides some insight into what is going on when there's a foul up.