When I tried to build the LLVM source with a user defined module(which invoke add_llvm_loadable_module from CmakeLists.txt) I am getting following error -
LlvmDisassembler ignored -- Loadable modules not supported on this
platform.
I am building from the latest trunk and using MingW to build LLVM. Is there any way to build dll for LLVM modules in Windows ?
As the error indicates, build dynamical loadable module is not supported. It can be built as a static library and link to the main executable.
Related
I'm trying to debug a segfault in some code built with mingw-w64's version of gcc. Since no Windows build of gcc includes the Address Sanitizer, I've been looking for a version prior to 4.9 that would allow me to use Mudflap instead.
(It has to be 4.8 or earlier, since Mudflap was removed from gcc in 4.9 - see https://gcc.gnu.org/wiki/Mudflap_Pointer_Debugging)
I've tried using downloads of 4.8.1 and 4.6.4 from https://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/ - but my builds all fail with cc1plus.exe: fatal error: mf-runtime.h: No such file or directory.
I have tried using the original MinGW as well, but 4.5 as downloaded from
https://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version4/gcc-4.5.0-1/
just fails silently with error code 1.
Is there any site that still hosts a mingw-w64 build of gcc old enough to include mudflap? Preferably with SEH threads instead of SJLJ. If not, is there anywhere I can download a mingw-w64-compatible set of libraries and headers to install mudflap to work with an existing build?
I am using xcode 12.4 and In a macOS/OSX project I am getting a linking error Library not found.
The mac os app is using a C++ library that is being successfully built in the xcode workspace, but the linker fails to find it
I have added that dependency Cpp library in the "Link binary with Libraries" (Build phases)
I think my Library search paths setting in Build Settings is not correct, linker search hardcoded path which was set on different machine where project was first built.
The output of workspace which includes the C++ library is in the Derived data, how can I specify derived data or Build path as variable and use it to point to C++ library folder , so that even on different machine project is built without searching any hard coded library paths ?
Thanks,
Ahmed
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'm trying out a new setup. I'm on a 64-bit Windows 10. I've meson example project and clang compiler stack over Visual Studio 2017. Both of those are in my PATH.
[0/1] Regenerating build files.
The Meson build system Version: 0.49.0
Source dir: C:\WORK\cpp-example\wx-example
Build dir: C:\WORK\cpp-example\wx-example\builddir
Build type: native build
Project name: wx-example
Project version: undefined
Native C++ compiler: clang++ (clang 7.0.0 "clang version 7.0.0 (tags/RELEASE_700/final)")
Build machine cpu family: x86_64
Build machine cpu: x86_64
Found wx-config '>=3.0.0' NO
Dependency WxWidgets found: NO (tried config-tool)
meson.build:8:2: ERROR: Dependency "wxwidgets" not found, tried config-tool
A full log can be found at C:\WORK\cpp-example\wx-example\builddir\meson-logs\meson-log.txt
FAILED: build.ninja
My meson.build is
project('wx-example', 'cpp')
#if build_machine.system() == 'windows'
# cpp = meson.get_compiler('cpp')
# add_project_link_arguments(['C:\WORK\wxWidgets-3.1.2\include'], language : 'cpp')
# wx_dep = cpp.find_library('wxwidgets', dirs : ['C:\WORK\wxWidgets-3.1.2\lib\vc_x64_dll'])
#else
wx_dep = dependency('wxwidgets', version : '>=3.0.0', required : true)
#endif
executable('wx-example.exe', ['main.cpp'], dependencies : [wx_dep])
Do u have any idea how to compile my example?
Maybe I should use MinGW wxWitgets package?
Meson's dependency for wxWidgets only supports wx-config tool, which was originally intended for *nix only. So you need to get wx-config Windows native port first to make it work with VC++.
BTW. Maybe even the easiest thing to do is to write it on your own, as it's just a regular console application, which parses the command line and spits to stdout the corresponding compiler/linker flags.
Maybe I should use MinGW wxWitgets package?
Well, that's, of course, possible but then you will also have to switch to gcc/g++. Moreover, Meson's wxWidgets dependency is still broken under MSYS2/MinGW. The problem is that Meson erroneously tries to execute wx-config directly, while under Windows it must be prefixed with env/sh/bash or whatever. Not a big problem to fix it, but you'll still have some work to do.
UPD.: The issue appears to be fixed in Meson 0.51.0
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.