I am trying to understand openjdk vm code specifically gc code base. i tried to open in CLion but it shows lot of errors. Is there a document which explains how to setup and navigate code?
The OpenJDK source distribution includes NetBeans project nbproject - just open this project in NetBeans IDE with C/C++ development pack. The project already contains configurations for Solaris, Linux, and MacOS. Here is step-by-step instructions(I didn't check them):
http://marcelinorc.com/2016/02/17/using-netbeans-to-hack-openjdk9-in-ubuntu/
https://dzone.com/articles/hack-openjdk-netbeans-ide
In case of CLion you can use the following instructions.
If you are interested in hotspot project - you can use this CMakeLists.txt
cmake_minimum_required(VERSION 3.6)
project(hotspot)
set(CMAKE_CXX_STANDARD 98)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -D_GNU_SOURCE \
-D_REENTRANT \
-DLINUX -DINCLUDE_SUFFIX_OS=_linux -DVM_LITTLE_ENDIAN \
-DTARGET_COMPILER_gcc \
-DAMD64 -DHOTSPOT_LIB_ARCH='amd64' -DINCLUDE_SUFFIX_CPU=_x86 -D_LP64 -DTARGET_ARCH_x86 \
-DCOMPILER1 -DCOMPILER2")
include_directories(
src/share/vm
src/os/linux/vm
src/cpu/x86/vm
src/os_cpu/linux_x86/vm
src/share/vm/precompiled)
set(SOURCE_FILES
// CLion will generate includes here automatically on project initialization
)
add_executable(hotspot ${SOURCE_FILES})
Related
I am trying to debug a port of some c and c++ code to WASM. I worked out how to source level debug in the browser with a simple 10 line .c program but now I want to make that work with a non trivial code base. (mixed c and c++). The wasm code works in a simple app but not in my more complex use case, hence the need to debug it
I use CMake to generate ninja build files
Here is where I am setting flags in my CMakeLists.txt
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} \
-s MODULARIZE=1 \
-s SINGLE_FILE=1 \
-s EXPORT_NAME=aubio \
-g --bind")
this was basically copied from the original codebase (the -g instead of -Oz is mine), I am not a CMake nor ninja nor emscripten wizard. When I build this I can see that the CXX flags are not passed to the emc++ compile passes, only to the 'linker' phase
I am not even sure where the -g (perhaps with source-map) needs to be for a multi-file project 'linked' into a single file. Should it be on the compile passes or the link pass , or maybe both. But certainly at the moment I do not get any symbols anywhere, no 'map' file(s) (embedded DWARF?, since the browser plugin claims to support it)
set(CMAKE_BUILD_TYPE Debug)
seems to embed DWARF to WASM file.
I don't know why set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -g") nor target_compile_options(foo PUBLIC -g) doesn't work in Release build.
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
The software will eventually run on an embedded Linux platform. To start, we wrote a library, with all C files in the same folder, and C++ files in a test folder under it.
MyLib
a.c
b.c
MyLib/test
test.cpp
This works on Windows 10, using CMake, Ninja and CLang plus doctest as a test framework. All of these tools are installed under vcpkg.
I am now trying to get everything configured and running on Ubuntu 16.04. All of the tools and source code have been retrieved from our repository. I have tried to build the library and test with Qt, cmake-gui and the command line without success.
Using CMake-gui, after browsing to the source and destination, clicking the Configure button causes the error
CMake Error: CMake was unable to find a build program corresponding to "Ninja".
CMAKE_MAKE_PROGRAM was not set.
The ninja program is in ~/../vcpkg/downloads/tools/ninja-1.8.2-linux/ folder.
I had different errors when trying to build from the command line.
Are there any examples of configurations that work with controlled tools instead of those in the environment?
Edit: added
CMakeLists.txt
cmake_minimum_required(VERSION 3.14)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)
project(PSOC_LIB)
option(BUILD_TESTS "bulid tests project" OFF)
set(psoc_lib_VERSION_MAJOR 0)
set(psoc_lib_VERSION_MINOR 1)
set(psoc_lib_VERSION_PATCH 0)
set(psoc_lib_VERSION "${psoc_lib_VERSION_MAJOR}.${psoc_lib_VERSION_MINOR}.${psoc_lib_VERSION_PATCH}")
set(PROJ_NAME "\"PSOC Library\"") # PROJECT_NAME is a predefined variable
set(PROJECT_DESCRIPTION "\"Crossplatform library for products\"")
configure_file(include/psoc/config.h.in
${CMAKE_BINARY_DIR}/include/psoc/config.h
)
set(SOURCES
# 5 *.c files
)
add_library(PSOC_LIB ${SOURCES})
target_include_directories(PSOC_LIB PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include)
target_compile_definitions(PSOC_LIB PRIVATE _CRT_SECURE_NO_WARNINGS=1)
if (BUILD_TESTS)
include(CTest)
enable_testing()
add_subdirectory(test)
endif (BUILD_TESTS)
test/CmakeLists.txt
cmake_minimum_required(VERSION 3.10)
set(TEST_SOURCES
test.cpp
)
find_package(doctest CONFIG REQUIRED)
add_executable(test_runner test_runner.cpp ${TEST_SOURCES})
target_compile_definitions(test_runner PRIVATE _SILENCE_CXX17_ALLOCATOR_VOID_DEPRECATION_WARNING) #silence warnings about allocator<void> deprecation
target_compile_definitions(test_runner PRIVATE _WIN32_WINNT=0x0601) #target windows 7
target_link_libraries(test_runner PSOC_LIB doctest::doctest)
add_test(all_tests test_runner)
Under Windows, the files in the test folder are build even when BUILD_TESTS is OFF. Under Linux, the test and Testing folders are created only when BUILD_TESTS is ON.
I created a shell script that builds an executable test file.
#!/bin/bash
# Build a debug version of the PSOC_LIB and related tests
mkdir build
cd build
../../../vcpkg_pml/vcpkg/downloads/tools/cmake-3.14.0-linux/cmake-3.14.0-Linux-x86_64/bin/cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug -S ../
ninja
I'm trying to cross compile some c++ library for QNX neutrino using cmake. In CMakeLists.txt file I specified CMAKE_CXX_STANDARD 14 required, but the resulting compiler command line does not contain the -std=c++14 option.
set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)
I've tried using target compile features:
target_compile_features(my_library PRIVATE cxx_std_14)
but that gives me the following error:
CMake Error at CMakeLists.txt:53 (target_compile_features):
target_compile_features no known features for CXX compiler
"QCC"
version 5.4.0.
When I'm using check_cxx_compiler_flag feature, it seems to recognize the option:
include(CheckCXXCompilerFlag)
check_cxx_compiler_flag(-std=c++14 CXX14_SUPPORT)
if(CXX14_SUPPORT)
message("c++14 support found")
else()
message("c++14 unsupported")
endif()
This outputs message
c++14 support found
Running qcc manually it accepts the -std=c++14 option just fine and the code using std::make_unique compiles just fine.
Also using the native compiler (Ubuntu 18.04, gcc) everything work fine with cmake generated makefiles. make VERBOSE=1 displays the following command line (I removed some directories):
/usr/local/bin/c++ -Dshm_transfer_EXPORTS -I... -fPIC -std=gnu++14 -o CMakeFiles/shm_transfer.dir/src/SharedMemoryTransfer.cpp.o -c .../SharedMemoryTransfer.cpp
as opposed to the command line using qcc toolchain:
.../qnx700/host/linux/x86_64/usr/bin/qcc -lang-c++ -Vgcc_ntox86_64 -lang-c++ -Dshm_transfer_EXPORTS -I... -fPIC -o CMakeFiles/shm_transfer.dir/src/SharedMemoryTransfer.cpp.o -c .../SharedMemoryTransfer.cpp
I would have expected the cmake command to recognize that qcc supports the -std=c++14 option and generates the corresponding command lines because of the CMAKE_CXX_STANDARD setting.
Use
set_property(TARGET ${PROJECT_NAME} PROPERTY LINKER_LANGUAGE CXX)
set_property(TARGET ${PROJECT_NAME} PROPERTY CXX_STANDARD 14)
. Using this you can stick the compiler setting to the target, while global flags are dis encouraged and can be overwritten by other cmake consumers. This the reason I assume why the deprecated set(CMAKE_CXX_STANDARD 14) did not help you: I can not see your full CMakeLists.txt and bet you have many sub folders and other targets, which could reset the CMAKE_CXX_STANDARD them selfs. Also make sure of the ordering of the CMake commands.
And you can replace ${PROJECT_NAME} with my_library if you want.
add_compile_options(-std=gnu++14)
Add this to your project level CMakeLists.txt file, not in toolchain.
I need to force my Cmake to build and link my MPI code with MPICH. My MPICH is installed using the Ubuntu Package manager, in a standard location /usr/lib/mpich/. However, CMake still looks for the OpenMPI libraries, which I do not use. How can I instruct CMake to look for MPICH instead?
Below, you can see the output of some basic diagnostics:
$ whereis openmpi
openmpi:
$ whereis mpich
mpich: /usr/lib/mpich /usr/include/mpich
$ mpicc -v
mpicc for MPICH version 3.2
Below, I also provide the Cmake script and the errors I get from cmake and the mpirun.mpich. My Cmake is 3.5.1 and I run on Ubuntu Xenial 16.04.
cmake_minimum_required(VERSION 3.0)
message (STATUS "Adding mpiService")
find_package(MPI REQUIRED)
set(CMAKE_C_COMPILER mpicc)
set(CMAKE_CXX_COMPILER mpicxx)
set(MPI_GUESS_LIBRARY_NAME MPICH2)
message(STATUS ${MPI_INCLUDE_PATH})
message(STATUS ${MPI_C_LIBRARIES})
#add_definitions(-DOMPI_SKIP_MPICXX)
add_executable(mpiService main.cpp)
set(CMAKE_VERBOSE_MAKEFILE ON)
include_directories(SYSTEM ${MPI_INCLUDE_PATH})
target_link_libraries(
mpiService
PRIVATE
${MPI_C_LIBRARIES}
)
From the Cmake STATUS I get the following output:
/usr/lib/openmpi/include/openmpi/opal/mca/event/libevent2021/libevent/usr/lib/openmpi/include/openmpi/opal/mca/event/libevent2021/libevent/include/usr/lib/openmpi/include/usr/lib/openmpi/include/openmpi
/usr/lib/openmpi/lib/libmpi.so
And when I run the binary I get the following:
ubuntu#node1:~$ mpirun.mpich -np 2 --host node1,node2 mpiService
mpiService: error while loading shared libraries: libmpi.so.12: cannot open shared object file: No such file or directory
mpiService: error while loading shared libraries: libmpi.so.12: cannot open shared object file: No such file or directory
How can I instruct CMake to look for MPICH instead?
According to FindMPI documentation, you may set MPI_<lang>_COMPILER variable to the desired MPI compiler:
Set MPI_<lang>_COMPILER to the MPI wrapper (mpicc, etc.) of your
choice and reconfigure. FindMPI will attempt to determine all the
necessary variables using THAT compiler's compile and link flags.
set(MPI_CXX_COMPILER <path-to-mpich-compiler>)
find_package(MPI REQUIRED)
Alternatively, since CMake version 3.10, variable MPI_EXECUTABLE_SUFFIX can be set instead:
A suffix which is appended to all names that are being looked for. For instance you may set this to .mpich or .openmpi to prefer the one or the other on Debian and its derivatives.
set(MPI_EXECUTABLE_SUFFIX ".mpich")
find_package(MPI REQUIRED)
Herewith my current solution.
find_package(MPI REQUIRED)
# ----------------
# This is the only thing that made it work
# ----------------
set(MPI_C_LIBRARIES "/usr/lib/mpich/lib/libmpich.so")
set(MPI_INCLUDE_PATH "/usr/include/mpich")
# ----------------
add_executable(mpiService main.cpp)
include_directories(SYSTEM ${MPI_INCLUDE_PATH})
target_link_libraries(
mpiService
${MPI_C_LIBRARIES}
)
I personally do not like this solution, as I have to explicitly specify the path. Any other proposed solution was still building with OpenMPI. If I find a better alternative, I will re-post.