Cannot use xtensor-blas on Windows - cmake

Disclaimer: I'm a noob at building/make/packages/cmake.
My goal: Use xtensor-blas library in C++
My env: Win10 x64, CLion2021
My problem: Can't get the simplest examples to compile. Sth about project dependencies.
I tried: 1) downloading and compiling openBLAST manually using every tutorial I could google - always stopped at different problems. Either I don't have "nmake" or build failed for some reason, or I get "undefined reference" etc. - I've been overwhelmed for a couple of days. A step-by-step walkthrough would be appreciated.
2) the closest I got was using anaconda conda install -c conda-forge openblas, then copy-pasting "include" directories from xtl,xtensor,xtensor-blas to my project. My CMakeLists.txt:
cmake_minimum_required(VERSION 3.19)
project(tstxtensor3)
set(CMAKE_CXX_STANDARD 20)
add_executable(tstxtensor3 main.cpp)
include_directories(.)
add_definitions(-DHAVE_CBLAS=1)
set(OpenBLAS_DIR c:/Users/pruglo/anaconda3/envs/evn/Library/share/cmake/OpenBLAS/)
find_package(OpenBLAS REQUIRED)
if (OpenBLAS_FOUND)
include_directories(${OpenBLAS_INCLUDE_DIRS})
target_link_libraries(tstxtensor3 c:/Users/pruglo/anaconda3/envs/evn/Library/lib/openblas.lib ${OpenBLAS_LIBRARY})
else ()
message("OpenBLAS NOT FOUND!")
endif ()
Cmake loads successfuly, and OpenBLAS_FOUND is true. But when I compile my cpp, I get error while loading shared libraries: openblas.dll: cannot open shared object file: No such file or directory Process finished with exit code 127
Note: OpenBLAS_INCLUDE_DIRS expands to c:/Users/pruglo/anaconda3/envs/evn/Library/include/openblas and OpenBLAS_LIBRARY expands to c:/Users/pruglo/anaconda3/envs/evn/Library/bin/openblas.dll
Extra questions:
do I need LAPACK or other stuff for xtensor-blas?
can I build my project portably so that I don't need to install everything for every pc I develop on?

Disclaimer: I'm far from a Windows expert (I just use it in Continuous Integration for testing).
You should be able to use the target provided by xtensor-blas. So what should be possible is to do (on any platform):
cmake_minimum_required(VERSION 3.1)
set(CMAKE_BUILD_TYPE Release)
project(myexec)
find_package(xtensor)
find_package(xtensor-blas)
add_executable(${PROJECT_NAME} main.cpp)
target_link_libraries(${PROJECT_NAME} xtensor xtensor-blas)
Since you talk about conda, that is indeed what I find easiest and works on all platforms. I really had to do not much else than
conda install -c conda-forge cmake xtensor xtensor-blas
(in my loaded environment).
There could be a pitfall here: Notice that I used CMake from conda. It might be that is it configured with the right paths for conda (but I'm not really sure to be honest).
For completeness, I think that you can use (from your source directory, with your conda environment loaded):
conda install -c conda-forge ninja
cmake -G "NMake Makefiles" -Bbuild
cd build
nmake
To be stand-alone, I tested with an example from the docs:
#include <xtensor.hpp>
#include <xtensor-blas/xlinalg.hpp>
int main()
{
xt::xarray<double> a = {{1, 2, 3}, {4, 5, 6}, {7, 8, 9}};
auto d = xt::linalg::det(a);
std::cout << d << std::endl; // 6.661338e-16
return 0;
}

Related

C++20 modules with cmake + ninja [duplicate]

Clang and MSVC already supports Modules TS from unfinished C++20 standard.
Can I build my modules based project with CMake or other build system and how?
I tried build2, it supports modules and it works very well, but i have a question about it's dependency management (UPD: question is closed).
CMake currently does not support C++20 modules.
See also the relevant issue in the CMake issue tracker. Note that supporting modules requires far more support from the build system than inserting a new compiler option. It fundamentally changes how dependencies between source files have to be handled during the build: In a pre-modules world all cpp source files can be built independently in any order. With modules that is no longer true, which has implications not only for CMake itself, but also for the downstream build system.
Take a look at the CMake Fortran modules paper for the gory details. From a build system's point of view, Fortran's modules behave very similar to the C++20 modules.
Update: CMake 3.20 introduces experimental support for Modules with the Ninja Generator (and only for Ninja). Details can be found in the respective pull request. At this stage, this feature is still highly experimental and not intended for production use. If you intend to play around with this anyway, you really should be reading both the Fortran modules paper and the dependency format paper to understand what you're getting into.
This works on Linux Manjaro (same as Arch), but should work on any Unix OS. Of course, you need to build with new clang (tested with clang-10).
helloworld.cpp:
export module helloworld;
import <cstdio>;
export void hello() { puts("Hello world!"); }
main.cpp:
import helloworld; // import declaration
int main() {
hello();
}
CMakeLists.txt:
cmake_minimum_required(VERSION 3.16)
project(main)
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)
set(PREBUILT_MODULE_PATH ${CMAKE_BINARY_DIR}/modules)
function(add_module name)
file(MAKE_DIRECTORY ${PREBUILT_MODULE_PATH})
add_custom_target(${name}.pcm
COMMAND
${CMAKE_CXX_COMPILER}
-std=c++20
-stdlib=libc++
-fmodules
-c
${CMAKE_CURRENT_SOURCE_DIR}/${ARGN}
-Xclang -emit-module-interface
-o ${PREBUILT_MODULE_PATH}/${name}.pcm
)
endfunction()
add_compile_options(-fmodules)
add_compile_options(-stdlib=libc++)
add_compile_options(-fbuiltin-module-map)
add_compile_options(-fimplicit-module-maps)
add_compile_options(-fprebuilt-module-path=${PREBUILT_MODULE_PATH})
add_module(helloworld helloworld.cpp)
add_executable(main
main.cpp
helloworld.cpp
)
add_dependencies(main helloworld.pcm)
Assuming that you're using gcc 11 with a Makefile generator, the following code should work even without CMake support for C++20:
cmake_minimum_required(VERSION 3.19) # Lower versions should also be supported
project(cpp20-modules)
# Add target to build iostream module
add_custom_target(std_modules ALL
COMMAND ${CMAKE_COMMAND} -E echo "Building standard library modules"
COMMAND g++ -fmodules-ts -std=c++20 -c -x c++-system-header iostream
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
)
# Function to set up modules in GCC
function (prepare_for_module TGT)
target_compile_options(${TGT} PUBLIC -fmodules-ts)
set_property(TARGET ${TGT} PROPERTY CXX_STANDARD 20)
set_property(TARGET ${TGT} PROPERTY CXX_EXTENSIONS OFF)
add_dependencies(${TGT} std_modules)
endfunction()
# Program name and sources
set (TARGET prog)
set (SOURCES main.cpp)
set (MODULES mymod.cpp)
# Setup program modules object library
set (MODULE_TARGET prog-modules)
add_library(${MODULE_TARGET} OBJECT ${MODULES})
prepare_for_module(${MODULE_TARGET})
# Setup executable
add_executable(${TARGET} ${SOURCES})
prepare_for_module(${TARGET})
# Add modules to application using object library
target_link_libraries(${TARGET} PRIVATE ${MODULE_TARGET})
Some explanation:
A custom target is added to build the standard library modules, in case you want to include standard library header units (search for "Standard Library Header Units" here). For simplicity, I just added iostream here.
Next, a function is added to conveniently enable C++20 and Modules TS for targets
We first create an object library to build the user modules
Finally, we create our executable and link it to the object library created in the previous step.
Not consider the following main.cpp:
import mymod;
int main() {
helloModule();
}
and mymod.cpp:
module;
export module mymod;
import <iostream>;
export void helloModule() {
std::cout << "Hello module!\n";
}
Using the above CMakeLists.txt, your example should compile fine (successfully tested in Ubuntu WSL with gcc 1.11.0).
Update:
Sometimes when changing the CMakeLists.txt and recompiling, you may encounter an error
error: import "/usr/include/c++/11/iostream" has CRC mismatch
Probably the reason is that every new module will attempt to build the standard library modules, but I'm not sure. Unfortunately I didn't find a proper solution to this (avoiding rebuild if the gcm.cache directory already exists is bad if you want to add new standard modules, and doing it per-module is a maintenance nightmare). My Q&D solution is to delete ${CMAKE_BINARY_DIR}/gcm.cache and rebuild the modules. I'm happy for better suggestions though.
CMake ships with experimental support for C++20 modules:
https://gitlab.kitware.com/cmake/cmake/-/blob/master/Help/dev/experimental.rst
This is tracked in this issue:
https://gitlab.kitware.com/cmake/cmake/-/issues/18355
There is also a CMakeCXXModules repository that adds support for modules to CMake.
https://github.com/NTSFka/CMakeCxxModules
While waiting for proper C++20 modules support in CMake, I've found that if using MSVC Windows, for right now you can make-believe it's there by hacking around the build instead of around CMakeLists.txt: continously generate with latest VS generator, and open/build the .sln with VS2020. The IFC dependency chain gets taken care of automatically (import <iostream>; just works). Haven't tried Windows clang or cross-compiling. It's not ideal but for now at least another decently workable alternative today, so far.
Important afterthought: use .cppm and .ixx extensions.
CMake does not currently support C++20 modules like the others have stated. However, module support for Fortran is very similar, and perhaps this could be easily changed to support modules in C++20.
http://fortranwiki.org/fortran/show/Build+tools
Now, perhaps there i an easy way to modify this to support C++20 directly. Not sure. It is worth exploring and doing a pull request should you resolve it.
Add MSVC version (revised from #warchantua 's answer):
cmake_minimum_required(VERSION 3.16)
project(Cpp20)
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)
set(PREBUILT_MODULE_DIR ${CMAKE_BINARY_DIR}/modules)
set(STD_MODULES_DIR "D:/MSVC/VC/Tools/MSVC/14.29.30133/ifc/x64") # macro "$(VC_IFCPath)" in MSVC
function(add_module name)
file(MAKE_DIRECTORY ${PREBUILT_MODULE_DIR})
add_custom_target(${name}.ifc
COMMAND
${CMAKE_CXX_COMPILER}
/std:c++latest
/stdIfcDir ${STD_MODULES_DIR}
/experimental:module
/c
/EHsc
/MD
${CMAKE_CURRENT_SOURCE_DIR}/${ARGN}
/module:export
/ifcOutput
${PREBUILT_MODULE_DIR}/${name}.ifc
/Fo${PREBUILT_MODULE_DIR}/${name}.obj
)
endfunction()
set(CUSTOM_MODULES_DIR ${CMAKE_CURRENT_SOURCE_DIR}/modules)
add_module(my_module ${CUSTOM_MODULES_DIR}/my_module.ixx)
add_executable(test
test.cpp
)
target_compile_options(test
BEFORE
PRIVATE
/std:c++latest
/experimental:module
/stdIfcDir ${STD_MODULES_DIR}
/ifcSearchDir ${PREBUILT_MODULE_DIR}
/reference my_module=${PREBUILT_MODULE_DIR}/my_module.ifc
/EHsc
/MD
)
target_link_libraries(test ${PREBUILT_MODULE_DIR}/my_module.obj)
add_dependencies(test my_module.ifc)
I was not able to find Cmake support for modules. Here is an example how to use modules using clang. I am using Mac and this example works ok on my system. It took me quite a while to figure this out so unsure how general this is across linux or Windows.
Source code in file driver.cxx
import hello;
int main() { say_hello("Modules"); }
Source code in file hello.cxx
#include <iostream>
module hello;
void say_hello(const char *n) {
std::cout << "Hello, " << n << "!" << std::endl;
}
Source code in file hello.mxx
export module hello;
export void say_hello (const char* name);
And to compile the code with above source files, here are command lines on terminal
clang++ \
-std=c++2a \
-fmodules-ts \
--precompile \
-x c++-module \
-Xclang -fmodules-embed-all-files \
-Xclang -fmodules-codegen \
-Xclang -fmodules-debuginfo \
-o hello.pcm hello.mxx
clang++ -std=c++2a -fmodules-ts -o hello.pcm.o -c hello.pcm
clang++ -std=c++2a -fmodules-ts -x c++ -o hello.o \
-fmodule-file=hello.pcm -c hello.cxx
clang++ -std=c++2a -fmodules-ts -x c++ -o driver.o \
-fmodule-file=hello=hello.pcm -c driver.cxx
clang++ -o hello hello.pcm.o driver.o hello.o
and to get clean start on next compile
rm -f *.o
rm -f hello
rm -f hello.pcm
expected output
./hello
Hello, Modules!
Hope this helps, all the best.
With C++20 Modules the file compilation order matters, which is totally new. That's why the implementation is complicated and still experimental in 2023. Please read the authors blogpost

Use LLVM in a cmake build

I'm trying to build my own project that use LLVM. I downloaded the source code and the precompiled package on the official web site (last version).
http://releases.llvm.org/download.html
I downloaded :
LLVM source code
Clang for Windows (64-bit)
FYI, I don't build LLVM... only want to use it !
I followed the instruction here :
http://llvm.org/docs/CMake.html#embedding-llvm-in-your-project
in the section : "Embedding LLVM in your project"
So, I added this code :
find_package(LLVM REQUIRED CONFIG)
message(STATUS "Found LLVM ${LLVM_PACKAGE_VERSION}")
message(STATUS "Using LLVMConfig.cmake in: ${LLVM_DIR}")
message("LLVM_INCLUDE_DIRS=${LLVM_INCLUDE_DIRS}")
message("LLVM_DEFINITIONS=${LLVM_DEFINITIONS}")
But I got several cmake error messages, here is my output :
-- Using LLVMConfig.cmake in: C:\\Luciad_src\\libs\\LLVM\\cmake\\modules
LLVM_INCLUDE_DIRS=
LLVM_DEFINITIONS=
CMake Error at C:/Luciad_src/libs/LLVM/cmake/modules/LLVM-Config.cmake:31 (list):
list sub-command REMOVE_ITEM requires two or more arguments.
Call Stack (most recent call first):
C:/Luciad_src/libs/LLVM/cmake/modules/LLVM-Config.cmake:256 (is_llvm_target_library)
components/query/CMakeLists.txt:15 (llvm_map_components_to_libnames)
Is there a problem with my script, or the packages I use ? Any idea ?
Thanks for your help
You can have the LLVM as binary or source package.
The binary package does not include CMake support. If you compare both installations (binary on the left, source after building and installing it on the right) you can see the difference:
LLVM-5.0.0-win64.exe
<=> llvm-5.0.1.src.tar.xz (build and installed)
So you need to build and install the source package first to get CMake support. On my Windows machine I needed a cmd shell with administrator rights, a Visual Studio installation, go to the downloaded and extracted sources and do:
> mkdir mybuilddir
> cd mybuilddir
> cmake ..
> cmake --build . --config Release --target INSTALL
If I now use your CMake example I get:
-- Found LLVM 5.0.1
-- Using LLVMConfig.cmake in: C:/Program Files (x86)/LLVM/lib/cmake/llvm
LLVM_INCLUDE_DIRS=C:/Program Files (x86)/LLVM/include
LLVM_DEFINITIONS=-DLLVM_BUILD_GLOBAL_ISEL -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -DUNICODE -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-- Configuring done

cmake with git for windows, MinGW and make

Firstly, I have installed MinGW from https://sourceforge.net/projects/mingw/files/ and the mingw32-gcc-g++ and mingw32-gcc-objs with it. I have added C:\MinGW\bin to my path.
Secondly, I have installed Git for windows (not really important, the result is the same on cmd.exe).
Thirdly, I have installed the complete package "make" with http://gnuwin32.sourceforge.net/packages/make.htm
After that, I have installed cmake 3.5.1 with the .msi.
But when I run cmake ../src the result is :
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:5 (project):
No CMAKE_C_COMPILER could be found.
CMake Error at CMakeLists.txt:5 (project):
No CMAKE_CXX_COMPILER could be found.
-- Configuring incomplete, errors occurred!
See also "C:/Users/pauka/Dropbox/ETUDE/SRI/S8/STA_Stage/sources/tests/bin/CMakeFiles/CMakeOutput.log".
See also "C:/Users/pauka/Dropbox/ETUDE/SRI/S8/STA_Stage/sources/tests/bin/CMakeFiles/CMakeError.log".
So cmake can't find gcc or g++. But when I run gcc -version, the output is good... What should I configure for cmake ?
My CMakeLists.txt is :
# Ajustez en fonction de votre version de CMake
cmake_minimum_required (VERSION 2.8)
# Nom du projet
project (main)
find_package (OpenCV REQUIRED)
# Exécutable "main", compilé à partir du fichier main.cpp
add_executable (tracking_color tracking_color.cpp)
add_executable (feuille feuille.cpp)
add_executable (detect_circles detect_circles.cpp)
add_executable (segmentation segmentation.cpp)
add_executable (watershed_perso watershed_perso.cpp)
add_executable (main main.cpp utils.h)
add_executable (info_coins info_coins.cpp)
# main sera linké avec les bibliothèques d'OpenCV
target_link_libraries (tracking_color ${OpenCV_LIBS})
target_link_libraries (feuille ${OpenCV_LIBS})
target_link_libraries (detect_circles ${OpenCV_LIBS})
target_link_libraries (segmentation ${OpenCV_LIBS})
target_link_libraries (watershed_perso ${OpenCV_LIBS})
target_link_libraries (info_coins ${OpenCV_LIBS})
target_link_libraries (main ${OpenCV_LIBS})
Ok, shame on me,
I had to restart my computer and select "MinGW Makefiles" in the CMake GUI. Click Configure, and after that Generate.
Next, you must not use Git for windows because there is sh.exe and it's a cmake bug.
PS: to use OpenCV, you must compile it :
cd C:\opencv
mkdir my_build
cd my_build
cmake -G "MinGW Makefiles" ../sources
mingw32-make # took 2 hours on my computer
and next add, C:\opencv\my_build and C:\opencv\my_build\bin to the system path.
You can try setting manually the cxx path, see CMAKE_C_COMPILER from link which tells you more or less link this:
CXX=C:\path\to\g++ cmake ..
But, I would recommend you to see why cmake doesn't recognize your cxx compiler. I would double check your environment paths.
Maybe not the best answer but get things going. Install Bash On Ubuntu On Windows and install cmake and make using sudo apt-get install cmake and sudo apt-get install build-essential if you don't already have them installed. However, Bash On Ubuntu On Windows only comes with Windows 10 and for accessing a specific drive you should use /mnt/c instead of C:\
Follow this official tutorial to install Bash On Ubuntu On Windows.
mona#DESKTOP-0JQ770H:/mnt/c$ cmake -version
cmake version 2.8.12.2
mona#DESKTOP-0JQ770H:/mnt/c$ make -version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for x86_64-pc-linux-gnu
Additionally, of course you can install git in Bash On Ubuntu On Windows
sudo apt-get install git
mona#DESKTOP-0JQ770H:/mnt/c$ git --version
git version 1.9.1
though I don't suggest using a Linux-based git for pushing to github for a Windows specific SDK/code. I would still stick to Git Bash for dealing with git.
*I used to use CMAKE GUI for dealing with CMake in Windows 10 and then port my stuff to Visual Studio. That is also a neat solution depending on your codebase.

Unable to link against Boost.Python on OS X

I am trying to build a really trivial example with Boost.Python. I have installed boost and boost-python with homebrew. I am using python 3.4.3 and boost 1.59. My OS is El Capitan.
Boost.Python was installed with python3 like this:
brew install boost-python --with-python3
I have 3 files:
/* greet.hpp */
#ifndef BOOSTPYTHONHELLOWORLD_GREET_HPP
#define BOOSTPYTHONHELLOWORLD_GREET_HPP
char const* greet();
#endif //BOOSTPYTHONHELLOWORLD_GREET_HPP
/* greet.cpp */
#include "greet.hpp"
char const* greet()
{
return "Hello world";
}
/* greet_ext.cpp */
#include "greet.hpp"
#include <boost/python.hpp>
BOOST_PYTHON_MODULE(greet_ext)
{
using namespace boost::python;
def("greet", greet);
}
My CMakeLists.txt file looks like this:
cmake_minimum_required(VERSION 3.3)
project(BoostPythonHelloWorld)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
set(PYTHON_LIBRARY "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/libpython3.4m.dylib")
set(PYTHON_INCLUDE_DIR "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/include/python3.4m")
FIND_PACKAGE(PythonLibs 3.4 REQUIRED)
FIND_PACKAGE(Boost COMPONENTS python)
if(NOT WIN32)
add_definitions(-DBOOST_ALL_DYN_LINK=1)
add_definitions(-DBOOST_TEST_DYN_LINK)
endif()
INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS} ${PYTHON_INCLUDE_DIRS})
add_library(greet SHARED greet.cpp)
add_library(greet_ext SHARED greet_ext.cpp)
target_link_libraries(greet_ext greet)
target_link_libraries(greet_ext ${PYTHON_LIBRARIES})
target_link_libraries(greet_ext ${Boost_LIBRARIES})
set_target_properties(greet_ext PROPERTIES PREFIX "")
When I run CMake it finds all the correct python libraries (because I specified them manually as you can see in the file above).
During build I get the following link error:
Scanning dependencies of target greet
[ 25%] Building CXX object CMakeFiles/greet.dir/greet.cpp.o
[ 50%] Linking CXX shared library libgreet.dylib
[ 50%] Built target greet
Scanning dependencies of target greet_ext
[ 75%] Building CXX object CMakeFiles/greet_ext.dir/greet_ext.cpp.o
[100%] Linking CXX shared library greet_ext.dylib
Undefined symbols for architecture x86_64:
"boost::python::detail::init_module(PyModuleDef&, void (*)())", referenced from:
_PyInit_greet_ext in greet_ext.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [greet_ext.dylib] Error 1
make[1]: *** [CMakeFiles/greet_ext.dir/all] Error 2
make: *** [all] Error 2
Anyone have any idea why this is happening?
EDIT
If I link against Python 2.7 it works, which means boost-python was built against python 2.7 instead of 3.4, even though I specified the --with-python3 options..
So, the questions is, how to build boost-python against python 3.4?
The solution I am currently using is to reinstall boost-python without python 2.7 support.
The steps I took were:
Uninstall boost-python if already installed: brew uninstall boost-python.
Install boost-python with python3 support but without python 2.7 support: brew install boost-python --with-python3 --without-python.
In order to use boost-python with python 3 you need to change this in your CMakeLists.txt:
FIND_PACKAGE(Boost COMPONENTS python)
to this:
FIND_PACKAGE(Boost COMPONENTS python3)
That way you can recompile boost with python 2 support and still use python 3.
I'd suggest installing boost-python3 via brew.
You still need to give the minor version number as well and possibly the library path. The following worked for me:
BOOST_LIBRARYDIR=/usr/local/Cellar/boost-python3/1.67.0/lib cmake ..
with CMakeLists.txt (located in ..) containing
FIND_PACKAGE(Boost COMPONENTS python36)
(for Boost 1.67.0 and Python 3.6, obviously).

Using libdl.so in MinGW

I want to generate a dll file in MinGW, I have several object dependencies in order to do that, one of my object dependencies is libdl.so, I add this object in unix simply as :
g++ xx.o yy.o /usr/lib/libdl.so -o module.so
but in MinGW, I don't have any idea how to add this object. any ideas?
There is a MinGW port of libdl that you can use just like under Unix. Quote from the website:
This library implements a wrapper for dlfcn, as specified in POSIX and SUS, around the dynamic link library functions found in the Windows API.
It requires MinGW to build.
You may get pre-built binaries (with MinGW gcc 3.4.5) and a bundled source code from the Downloads section.
The following commands build and install it in a standard MinGW installation (to be run from your MinGW shell):
./configure --prefix=/ --libdir=/lib --incdir=/include && make && make install
To compile your library as a DLL, use the following command:
g++ -shared xx.o yy.o -ldl -o module.dll
I encountered the same problem (msys2, 32bit version of compiler etc.).
For me I found out that the libdl.a was available in /usr/lib but not in /mingw32/lib. I was able to solve the problem by linking it to the /mingw32/lib folder:
ln -s /usr/lib/libdl.a /mingw32/lib