When building LLVM using cmake, a few components involving "Loadable modules" are not built, and warning messages such as the following are issued:
-- LLVMHello ignored -- Loadable modules not supported on this platform.
...
-- BugpointPasses ignored -- Loadable modules not supported on this platform.
...
-- SampleAnalyzerPlugin ignored -- Loadable modules not supported on this platform.
-- PrintFunctionNames ignored -- Loadable modules not supported on this platform.
But loadable modules are supported under Cygwin; and the handy opt tool can readily be used. Building with ./configure produces no such messages; and the components are built. Why do these messages occur? Is there a way to build using cmake, and still have these components built?
The loadable modules are not supported on Windows due to lack of dynamic linking on this platform. The plugins definitely should be disabled on autoconf build as well.
The only way to use loadable modules on windows is to build the whole LLVM into a big .DLL
Related
Suppose that:
I'm writing a C or C++ library.
I intend my library to be usable on multiple Unix-like platforms (and perhaps also on Windows).
I use CMake for build configuration.
I have some dependencies on other libraries.
Given this - should I be cognizant of the pkg-config mechanism? Versed in its use? Or - should I just ignore it? I'm asking both about its use when configuring my library's build, but also about whether to make sure the installation commands generate and install a .pc file for my library?
I am totally new to CMake and compiled languages for that matter. I have seen this question and answer. But I still don't fully understand what CMake is.
I am coming from a nodeJs/Javascipt environment, therefore if I could know a CMake equivalent in the nodeJs/Javascipt environment it would really help me understand what it is.So... Is CMake an equivalent of npm?
No, citing from Wikipedia:
CMake is a cross-platform free and open-source software tool for managing the build process of software using a compiler-independent method. It supports directory hierarchies and applications that depend on multiple libraries. It is used in conjunction with native build environments such as Make, Qt Creator, Ninja, Apple's Xcode, and Microsoft Visual Studio. It has minimal dependencies, requiring only a C++ compiler on its own build system.
JavaScript is an interpreted language, that means NodeJS/Browsers read and understand the code and execute it directly. For example C is built via a compiler (that reads and understands the code before execution) to Machine code (that does not need to be understand because it's the native language from your processor) and can be executed faster. CMake simplifies calling the Compiler, linking libraries (something like setting up require) and more for all files. Altough sometimes using babel, webpack and others via npm run is called 'building'.
I need to build Sundials (as a dependency for another C/C++ library) on a Linux cluster which provides only MKL as BLAS and LAPACK support.
As far as I know, unlike other versions, the MKL BLAS and LAPACK wrappers are not self-contained at link time but require linking against MKL core and/or other libraries as well.
So how (if at all) can I tell CMake what to include in order to successfully build Sundials? Is it possible and safe to use flags like
$ cmake (...) -DBLAS_LIBRARIES=/path/to/mkl/<several files grouped together>
and what would be the correct syntax?
I just installed msys2 and mingw64, with their development packages. I really need perl-Gtk3. Perl is msys2 and compiled with gcc-4.9.x, Gtk and friends are mingw and compiled with gcc-5.
Perl complains "Glib.c: loadable library and perl binaries are mismatched (got handshake key 0xde00080, needed 0xdd80080)" when building Glib. Should this work?
Thanks.
PS ... mingw-w64-x86_64-perl is simply unable to compile. And yes, I'm careful to use a mingw shell vs an msys shell.
Are you still having this problem? I have been able to build a Perl dev environment in MinGW64, current as of this time.
I have been able to build Perl Gtk2 / Gtk3 applications in that environment and the GUIs work. (Both Gtk2 and Gtk3 based). These applications are used in a production environment with several thousand desktop users. The application runs on OSX, Windows, and Linux, and can be packed into a binary for release as an "executable" for those operating systems. The details here are for the Windows version.
I do this by either installing the requisite system packages first with pacman, then as necessary rebuilding whatever system library packages that I may have modified, from source, using makepkg-mingw.
Then I build the requisite Perl modules using the CPAN shell, and the "look" command.
I use pkg-config to detect what library and header files are needed.
I then build (at minimum), the Perl Glib, Pango, Cairo, Gtk2, and Gtk3 modules using the perl Makefile.PL command.
The LIBS and INC options need to be added to that command to create a Makefile that includes the correct header files, and links to the correct libraries. The EXTRALIBS and LDLOADLIBS sections of the Makefile needs be correct.
Also ExtUtils::MM_Win32.pm ExtUtils::Liblist::Kid.pm needed to be edited due to the different archname reported by the MinGW64 perl.
I am only giving a general answer, because I was thinking offing a YouTube video on this. If this is a desired topic I will.
I have a layered cmake project with a hierarchy of libraries and applications. Each of these libraries and applications has a CMakeLists.txt and a top level CMakeLists.txt that includes the sub-cmake files.
Right now we are developing and testing entirely on an x86 Linux platform but at some point we will want to start pulling the code into a Yocto build and target arm. We want to maintain being able to build for both x86 and arm.
I've seen some Yocto guides on building for x86 but these appear to build the entire world (the toolchain, linux kernel, all libraries etc) and run the image via qemu. For our desktop use this is quite a bit of overkill when our machines have compilers and we can just run the applications directly, but it would be very helpful to have bitbake build some libraries that we have dependencies on and that need to be installed to a 'virtual root'.
How can I use use bitbake for native x86 projects (in place of or in addition to cmake) and be able to leverage the recipe files for Yocto later on?
I don't have much experience with Yocto, but I'm using another embedded Linux distribution with similar concept: Buildroot. Buildroot creates toolchainfile (output/host/usr/share/buildroot/toolchainfile.cmake) for the currently selected toolchain.
You create two output folders for your project:
build-x86
build-arm
I the first folder you just execute:
cmake ../path-to-your-source
In the second one:
cmake ../path-to-your-source -DCMAKE_TOOLCHAIN_FILE=../path-to-buildroot/output/host/usr/share/buildroot/toolchainfile.cmake
If Yocto provides a toolchainfile, you can use it directly. If not you can create it yourself. See this wiki.
Update:
This section explains, how you can add your software to Buildroot (package). Here the source folder override mechanism is described.