I am getting the following warning when I use Code::Block / Intel C++ Compiler:
"myLib.a is an archive, but has no symbols (this can happen if ar is used where xiar is needed)"
This is followed by Linker errors for missing symbols.
The project builds fine in gcc compiler.
How do I have code blocks run xiar instead of ar ?
How do I have code blocks run xiar instead of ar?
In the Code::Blocks IDE navigate Settings -> Compiler
Set Selected Compiler = Intel C++ (whatever you have called it)
Tab to Toolchain executables -> Program files
In the edit box Linker for static libs change ar to xiar (or
possibly path/to/xiar, if the Intel tools aren't in your PATH)
Related
To build a C library with Visual Studio, the CMake command
set(WINDOWS_EXPORT_ALL_SYMBOLS ON)
saves me from adding __declspec(dllexport) or __declspec(dllimport) in front of function declarations; explicit import/export symbols are only required for global variables.
Under MinGW (read: either MinGW or its recommendable replacement Mingw-w64) this does not work. Linking applications (also built with MinGW) to my library failed until I had pasted import/export symbols in front of each function. Whereas the long answer https://stackoverflow.com/a/32284832/1017348 suggests the contrary: no need for import/export symbols under MinGW. Is that answer right? How then to get rid of the need for import/export symbols?
I just encountered the same problem. After poking through CMake source code, the fix that worked for me was to also add:
set( CMAKE_SUPPORT_WINDOWS_EXPORT_ALL_SYMBOLS 1 )
CMake says:
This property is implemented only for MS-compatible tools on Windows.
CMake enables this capability by setting CMAKE_SUPPORT_WINDOWS_EXPORT_ALL_SYMBOLS in each "Platform" file in <cmake install>/Modules/Platform that they know supports it. However, CMake doesn't model MinGW as a "Platform". Instead you just pick "Windows Makefile", "Windows Ninja", etc. and manually set the C/C++/Fortran compilers to point to the MinGW gcc compilers. Ideally CMake should recognize when the OS is Windows and the compiler is gcc and set this for us, but for now we can help it by setting it ourselves.
Incidentally CMake implements this feature with a hidden cmake -E __create_def <output-def> <input-list-of-obj-files> command. I previously thought of adding a custom rule to run that command. Though as it starts with __, it's meant for internal use and might change from one release to the next.
I'm working on a cross-platform project which has some hand-written assembly to optimize performance for various CPU architectures. I'm converting this project to CMake from a proprietary build system, starting with compiling using Visual Studio on Windows. For x86 and AMD64, I've been able to assemble and link everything just fine, but I can't get it to work on ARM64 (or presumably ARM32, though I haven't tried that yet).
I'm including the ASM files in my sources as follows:
if(CMAKE_SYSTEM_PROCESSOR MATCHES "AMD64")
list(APPEND SOURCES
amd64/aesasm.asm
...)
set_source_files_properties(
amd64/aesasm.asm
...
PROPERTY LANGUAGE ASM_MASM)
elseif(CMAKE_SYSTEM_PROCESSOR MATCHES "X86")
# ...
elseif(CMAKE_SYSTEM_PROCESSOR MATCHES "ARM64")
list(APPEND SOURCES
arm64/fdef_asm.asm
...)
set_source_files_properties(
arm64/fdef_asm.asm
...
PROPERTY LANGUAGE ASM_MASM)
Then in my top-level CMakeLists.txt, I enable MASM using enable_language(ASM_MASM). For x86 and AMD64, CMake automatically finds ml/ml64.exe, configures the Visual Studio project correctly, and everything works.
But for ARM64, if I try the same thing, I get this error from Visual Studio when trying to build: MSB3721: The command "echo MASM not supported on this platform. As far as I can tell, this is because Visual Studio considers ARM assembly to be a different dialect, "MARMASM", with a different executable name for the assembler (armasm/armasm64.exe).
I tried setting enable_language(ASM_MARMASM) in my ARM64 toolchain file, but CMake does not recognize this as an ASM dialect, and gives me this error:
CMake Error: Could not find cmake module file: CMakeDetermineASM_MARMASMCompiler.cmake
CMake Error: Could not find cmake module file: F:/os/src/symcrypt/bin/CMakeFiles/3.15.3/CMakeASM_MARMASMCompiler.cmake
CMake Error at CMakeLists.txt:49 (enable_language):
No CMAKE_ASM_MARMASM_COMPILER could be found.
I also tried manually setting the assembler:
get_filename_component(VS_TOOLS_DIRECTORY ${CMAKE_LINKER} DIRECTORY)
find_file(ARM64_COMPILER "armasm64.exe" HINTS ${VS_TOOLS_DIRECTORY})
set(CMAKE_ASM_MARMASM_COMPILER ${ARM64_COMPILER})
enable_language(ASM_MARMASM)
message(STATUS "Manually set assembler to ${CMAKE_ASM_MARMASM_COMPILER}")
But this does not work either; I still get an error that No CMAKE_ASM_MARMASM_COMPILER could be found.
How can I include ARM/ARM64 assembly in my project?
Looks like CMake (still) does not have support for this. I found some bits in the .NET source code to work around it:
https://github.com/dotnet/runtime/blob/f8f63b1fde85119c925313caa475d9936297b463/eng/native/functions.cmake#L173-L207
and
https://github.com/dotnet/runtime/blob/f8f63b1fde85119c925313caa475d9936297b463/eng/native/configurecompiler.cmake#L611-L626
edit: As reference, here's the commit for a project I had this requirement for: https://dyncall.org/pub/dyncall/dyncall/rev/451299d50c1a
The android ndk supplied by google is unable to compile call to c++11 functions such as std::to_string() and std::stoul etc. {I had tried it in r10b one from the official site}. So the suggestion in SO was to try crystax NDK. I have downloaded and placed the root folder next to the google's NDK. All I changed in my root CMakeLists.txt file was:
from:
set(PLATFORM_PREFIX "/some-path/android-ndk-r10b/platforms/android-19/arch-arm")
set(PLATFORM_FLAGS "-fPIC -Wno-psabi --sysroot=${PLATFORM_PREFIX}")
set(CMAKE_CXX_FLAGS "${PLATFORM_FLAGS} -march=armv7-a -mfloat-abi=softfp -mfpu=neon" CACHE STRING "")
To:
set(PLATFORM_PREFIX "/some-path/android-ndk-r8-crystax-1/platforms/android-14/arch-arm")
set(PLATFORM_FLAGS "-fPIC -Wno-psabi --sysroot=${PLATFORM_PREFIX}")
set(CMAKE_CXX_FLAGS "${PLATFORM_FLAGS} -march=armv7-a -mfloat-abi=softfp -mfpu=neon" CACHE STRING "")
and cmake command-line from:
cmake .. -DCMAKE_CXX_COMPILER=/some-path/android-ndk-r10b/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++ -DCMAKE_C_COMPILER=/some-path/android-ndk-r10b/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc -DANDROID_BUILD=ON -DANDROID_NDK_ROOT=/some-path/android-ndk-r10b
To:
cmake .. -DCMAKE_CXX_COMPILER=/some-path/android-ndk-r8-crystax-1/toolchains/arm-linux-androideabi-4.7/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++ -DCMAKE_C_COMPILER=/some-path/android-ndk-r8-crystax-1/toolchains/arm-linux-androideabi-4.7/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc -DANDROID_BUILD=ON -DANDROID_NDK_ROOT=/some-path/android-ndk-r8-crystax-1
ie., changed from normal ndk to crystax-ndk. The program was compiling fine previously till it tried to compile a file with call to std::to_string() etc. But after the change Cmake gives an error that it is unable to compile a simple test program because:
/some-path/android-ndk-r8-crystax-1/toolchains/arm-linux-androideabi-4.7/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.7/../../../../arm-linux-androideabi/bin/ld:
error: cannot find -lcrystax
I can see libcrystax.a and .so in directorie:
/some-path/android-ndk-r8-crystax-1/sources/crystax/libs/armeabi-v7a
I tried adding link_directories("path-to-above") right at the beginning of the CMakeLists.txt file too, but that didn't solve it either.
It should find it there (after i supply the --sysroot etc above) just like the normal ndk. So how should this be solved ? Any other cmake variable to be set or something ?
I don't know how your cmake-based build system works, but actually if you properly add path /some-path/android-ndk-r8-crystax-1/sources/crystax/libs/armeabi-v7a to linker search paths, it should find libcrystax and link with it successfully.
Please note that NDK have several parts separated each from other - i.e. sysroot, libcrystax, C++ library - all are separated. It is done to work with NDK build system which offer some flexibility choosing C++ standard library implementation, and NDK build system know where to find all of them. In your case this approach is not so good so I suggest you first make standalone toolchain, which contains all things assembled together. In other words, it would be classic cross-compile toolchain which contains sysroot, libcrystax and GNU C++ standard library in places known to compiler/linker without passing of any additional options.
To create such toolchain, cd to NDK root directory and run the following command:
./build/tools/make-standalone-toolchain.sh --system=linux-x86_64 --toolchain=arm-linux-androideabi-4.7 --platform=android-14 --install-dir=$HOME/arm-linux-androideabi
Then use $HOME/arm-linux-androideabi as full standalone toolchain for your cmake-based build system.
Please note, however, that application built with CrystaX NDK r8 will not run on newest Android 5.0 due to changes in Bionic (libc). Previous Android versions (<=4.4) are all fine. We fixed that issue (and many others) in upcoming r10 release which is on final testing stage. In the meantime you could adopt your project to our r8 release and quickly switch to r10 when it done - the same approach will work with r10 as well as with r8.
I want to write parallel program in C++ using OpenMP, so I am getting started with OpenMP.
On the other words I am a beginner and I need good OpenMP guide telling how to install it.
Does someone know how to install OpenMP on Windows, then compile and run the program?
OpenMP is not something that you install. It comes with your compiler. You just need a decent compiler that supports OpenMP and you need to know how to enable OpenMP support since it is usually disabled by default.
The standard compiler for Windows comes from Microsoft and it is the Microsoft Visual C/C++ compiler from Visual Studio. Unfortunately its OpenMP support is a bit outdated - even the latest and greatest Visual Studio only supports OpenMP 2.0 (an outdated standard version from 2002). See here for more information on how to use OpenMP in Visual Studio. There are other compilers available as well - both Intel C/C++ Compiler (commercial license required) and GCC (freely available) support newer OpenMP versions and other compilers are available too.
You can start learning OpenMP by visiting the OpenMP web site here. Also there is a great tutorial on OpenMP from Lawrence Livermore National Laboratory available here.
2020 Update: Microsoft now ships Clang for Windows with Visual Studio. Although it is a bit convoluted, one can (ab)use the Clang-cl toolset to produce working 32-bit OpenMP programs. A number of steps are necessary:
If not already installed, add Clang and Clang-cl using the Visual Studio 2019 Installer.
Set the project's platform toolset (project Properties -> General -> Platform Toolset) to "LLVM (clang-cl)".
Enable Clang OpenMP support by adding -Xclang -fopenmp to the compiler options in project Properties -> C/C++ -> All Options -> Additional Options.Important: make sure that OpenMP support is disabled before switching the platform toolset (this is the default for new C++ projects). It seems that VS remembers the setting and still passes /openmp even though the language configuration for Clang has no option for OpenMP. If clang-cl.exe throws error MSB8055 (unsupported /openmp option) during build, set the platform toolset back to "Visual Studio 2019 (vXXX)" and disable the OpenMP support in Properties -> C/C++ -> Language -> Open MP Support, then switch the platform toolset again to "LLVM (Clang-cl)".
Add libomp.lib to the additional libraries in project Properties -> Linker -> Input -> Additional Dependencies.
Add the path to libomp.lib to the linker search path by adding a new entry with value $(LLVMInstallDir)\lib in project Properties -> Linker -> General -> Additional Library Directories.
Add a post-build action that copies LLVM's libomp.dll to the project output directory (without this step, running the executable will fail unless libomp.dll is in the DLL search path). In project Properties -> Build Events -> Post-Build Event -> Command Line:
xcopy /y "$(LLVMInstallDir)\bin\libomp.dll" "$(SolutionDir)$(Configuration)"
Build and run the project.
Note: this is very much likely still unsupported by Microsoft and it only works for x86 projects since the LLVM libraries shipped with VS are 32-bit only.
So here is what I did to finally get OpenMP working on my Windows 10 PC:
Get MinGW - Download and grab what you need to get the basic gcc compiler and the g++ pakage (its really easy to do). You can always run g++ -v to make sure it is up and running
Run mingw-get upgrade --recursive "gcc<4.7.*" "gcc-g++<4.7.*" This is the "Fun" part. Because at this time there was no libgomp library supported in their 4.9.* version my gcc wasn't able to recognize <omp.h> the last support version was 4.7.2 so with this I finally was able to run my openMP
To compile run g++ -fopenmp myOpenMPFile.cpp -o myOpenMP and it will all work from there
gcc -fopenmp myOpenMPFile.cpp -o myOpenMP will also work for C code
I would like to share what I did to get OpenMP working on my Windows 10 PC (things have got even simpler in 2019)
I installed MinGW distribution from here with GCC 8.2.0 compiler. The maintainer of the distribution has already added winpthreads and OpenMP support to GCC.
I compiled my code with -fopenmp flag as follows: g++ -fopenmp main.cpp -o exec
Note: the MinGW distribution provides support for many useful libraries (such as Boost 1.69.0) and other utilities. I found it to be very useful.
I have a following setup. Although my working setup deals with ARM compiler Real View Developer Suite (RVDS) 3.2 on a Windows host, the situation could be generic for any other C compiler on any host.
I build a ARM library (static library - .a file) of C code using RVDS 3.2 compiler toolchain on Windows host. Then I link this library with an application using an ARM-Linux compiler toolchain on a Linux host, to get a ARM executable. Now when I try to debug this generated ARM executable on Linux using gdb, by trying to put a breakpoint in some function which is present in the library that is linked, gdb is not able to put breakpoint there citing source not found. So I manually copied all the source files(*.c) used to create the library in the Linux folder where the executable file is present. Still gdb fails to put a breakpoint.
So now I started thinking:
How can I do source level debugging of this library which I create on Windows using a different compiler chain by launching the executable which is generated by linking this library to an application, in gdb. Is it possible? How can I do it? Is there any compiler option in RVDS compiler toolchain to enable this library source level debug?
Do I need to copy the source files to linux in exactly same folder structure as that is present in windows for those source files?
You could try to see if mimicking the exact same directory structure works. If you're not sure what directory structure the compiler annotated in the debug info in the executable, you can always look at it with dwarfdump (on linux).
First, GDB does not need any source to put breakpoints on functions; so your description of what is actually happening is probably inaccurate. I would start by verifying that the function you want to break on is actually there in the binary:
nm /path/to/app | grep function_desired
Second, to do source level debugging, GDB needs debug info in a format GDB understands. On Linux this generally means DWARF or STABS. It is quite possible that your RVDS compiler does not emit such debug info; if so, source level debugging will not be possible.
Did you build the library with debugging enabled (-g option)? Without that, there would be difficulties identifying lines etc.
I've found that -fPIC will cause this sort of issue, but the only work around I've found is to not use -fPIC when I want to debug.