I have encounter EXEC_BAD_ACCESS error in my local environment (Mac OS X 10.9.2, boost 1.55.0, mlpack 1.0.8, llvm 5.1 clang-503.0.38), and I have narrowed down the error in a very simple snippet:
#include "mlpack/methods/range_search/range_search.hpp"
int main(int argc, const char *argv[])
{
return 0;
}
The g++ version is
iMac:build dongli$ g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix
and compile the snippet by
g++ -std=c++11 main.cpp -o main -lmlpack -I/usr/include/libxml2
(you may change to your case)
Run main in terminal will give you
iMac:build dongli$ ./main
Bus error: 10
and run it in lldb will give you more information
iMac:build dongli$ lldb ./main
Current executable set to './main' (x86_64).
(lldb) r
Process 79449 launched: './main' (x86_64)
Process 79449 stopped
* thread #1: tid = 0xb4a75, 0x00000001000500eb libmlpack.1.0.dylib`long double boost::math::lanczos::lanczos17m64::lanczos_sum<long double>(long double const&) + 59, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x100001d80)
frame #0: 0x00000001000500eb libmlpack.1.0.dylib`long double boost::math::lanczos::lanczos17m64::lanczos_sum<long double>(long double const&) + 59
libmlpack.1.0.dylib`long double boost::math::lanczos::lanczos17m64::lanczos_sum<long double>(long double const&) + 59:
-> 0x1000500eb: fstpt (%rax)
0x1000500ed: fldt 0x26c8d(%rip) ; .memset_pattern99 + 1296
0x1000500f3: fstpt 0x10(%rax)
0x1000500f6: fldt 0x26c94(%rip) ; .memset_pattern99 + 1312
As you can see, it point me to boost::math::lanczos::lanczos17m64::lanczos_sum, but I have no idea what is the problem.
But when -std=c++11 is absent, no error occurs. I also tried to reinstall boost with --c++11 by homebrew.
Thanks in advance!
EDIT:
I have only installed one boost:
iMac:~ dongli$ ls /usr/local/Cellar/boost/
1.55.0
with command:
brew install boost --c++11
You could
check that the actual shared library file is marked executable and is accessible to the user that runs the application?
It that isn't it, this probably means that at runtime you find a conflicting version of the library. Fix/override the runtime library path, or compile against the same version of the library if so
After I removed all the C++11 features from my codes (e.g., initializer_list and default template argument), and removed the -std=c++11 option, the error is gone. I think I have installed boost, mlpack with -std=c++11 by using homebrew, but the error persisted, so my experience is not use the new features if they are not necessary.
Related
I am compiling C++, Fortran, and OpenMPI code using Homebrew installed packages. I also use the make (GNU Make 4.3) and cmake (3.24.1) packages installed with Homebrew.
I compile the test programs as follows:
### C++ ###
int main (int argc, char** argv)
{
int x=2;
return 0;
}
$ g++ test.cc
> clang: error: invalid version number in '-mmacosx-version-min=12.5'
### Fortran ###
program hello
print *, "Hello, world!"
end program hello
$ gfortran test.f90
> clang: error: invalid version number in '-mmacosx-version-min=12.5'
I get a clang error: clang: error: invalid version number in '-mmacosx-version-min=12.5' when using gcc-12 and gfortran-12. The version number requirement in the above error changes depending on the gcc version installed. For example, gcc-10 and gcc-11 result in clang: error: invalid version number in '-mmacosx-version-min=12.0'.
What's interesting is that the error invoked is coming from Apple clang even though I am not using it for compiling any of the programs.
Some relevant specs:
macOS Monterey 12.5.1
xcode-select version 2395
xcode-select path: /Library/Developer/CommandLineTools
$ /usr/bin/clang --version
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
Update: I now installed gfortran using the intel standalone installer here, I still get the same error.
Someone who seem to have had the same problem:
Found solution: reinstalling the Command Line Tools and exporting SYSTEM_VERSION_COMPAT=1 worked for me. Another possible solution could be to force the compilation to occur through GCC only, but this is not something I tried.
note: compilation was performed without including MPI software.
note2: pkg-config had to be installed as an extra dependency, but this was probably required by CMake.
https://groups.google.com/g/hande-user/c/dtGvyFTJFWE
I have gcc 11.3.0 installed using Homebrew on a MacBook Air with Apple Silicon M1 CPU. The binary is the aarch64 native version, not Rosetta emulated. The installed OS is macOS Monterey 12.3.
I'm having an issue compiling a program which uses the ARMv8.2-A SHA-3 extension instructions, which are supported by the M1 CPU. This is a minimal reproducible example:
#include <arm_neon.h>
int main() {
uint64x2_t a = {0}, b = {0}, c = {0};
veor3q_u64(a, b, c);
return 0;
}
This code compiles just fine with the Apple supplied clang compiler.
I compiled it using the following command line for gcc 11:
gcc-11 -o test test.c -march=armv8-a+sha3
This results in the following error:
In file included from test.c:1:
test.c: In function 'main':
/opt/homebrew/Cellar/gcc/11.3.0/lib/gcc/11/gcc/aarch64-apple-darwin21/11/include/arm_neon.h:32320:1: error: inlining failed in call to 'always_inline' 'veor3q_u64': target specific option mismatch
32320 | veor3q_u64 (uint64x2_t __a, uint64x2_t __b, uint64x2_t __c)
| ^~~~~~~~~~
test.c:5:5: note: called from here
5 | veor3q_u64(a, b, c);
| ^~~~~~~~~~~~~~~~~~~
Is this a bug in this particular hardware/software combination, or is there some command-line option I can pass to gcc to make this particular program compile?
Solved the problem. It turns out that gcc requires -march=armv8.2-a+sha3 rather than just -march=armv8-a+sha3 to compile this intrinsic. Indeed, in gcc's version of arm_neon.h, one can find this right before the block of intrinsics which includes veor3q_u64:
#pragma GCC target ("arch=armv8.2-a+sha3")
I am using Mac OS X Sierra, and I found that clang (LLVM version 8.1.0 (clang-802.0.38)) does not support OpenMP:
when I run clang -fopenmp program_name.c, I got the following error:
clang: error: unsupported option '-fopenmp'
It seems that clang does not support -fopenmp flag.
I could not find any openmp library in homebrew. According to LLVM website, LLVM already supports OpenMP. But I could not find a way to enable it during compiling.
Does this mean that the default clang in Mac does not support OpenMP?
Could you provide any suggestions?
(When I switch to GCC to compile the same program (gcc is installed using brew install gcc --without-multilib), and the compilation is successful.)
Try using Homebrew's llvm:
brew install llvm
You then have all the llvm binaries in /usr/local/opt/llvm/bin.
Compile the OpenMP Hello World program. Put omp_hello.c
/******************************************************************************
* FILE: omp_hello.c
* DESCRIPTION:
* OpenMP Example - Hello World - C/C++ Version
* In this simple example, the master thread forks a parallel region.
* All threads in the team obtain their unique thread number and print it.
* The master thread only prints the total number of threads. Two OpenMP
* library routines are used to obtain the number of threads and each
* thread's number.
* AUTHOR: Blaise Barney 5/99
* LAST REVISED: 04/06/05
******************************************************************************/
#include <omp.h>
#include <stdio.h>
#include <stdlib.h>
int main (int argc, char *argv[])
{
int nthreads, tid;
/* Fork a team of threads giving them their own copies of variables */
#pragma omp parallel private(nthreads, tid)
{
/* Obtain thread number */
tid = omp_get_thread_num();
printf("Hello World from thread = %d\n", tid);
/* Only master thread does this */
if (tid == 0)
{
nthreads = omp_get_num_threads();
printf("Number of threads = %d\n", nthreads);
}
} /* All threads join master thread and disband */
}
in a file and use:
/usr/local/opt/llvm/bin/clang -fopenmp -L/usr/local/opt/llvm/lib omp_hello.c -o hello
You might also have to set the CPPFLAGS with -I/usr/local/opt/llvm/include.
The makefile should look like this:
CPP = /usr/local/opt/llvm/bin/clang
CPPFLAGS = -I/usr/local/opt/llvm/include -fopenmp
LDFLAGS = -L/usr/local/opt/llvm/lib
omp_hello: omp_hello.c
$(CPP) $(CPPFLAGS) $^ -o $# $(LDFLAGS)
Update
In macOS 10.14 (Mojave) you might get an error like
/usr/local/Cellar/llvm/7.0.1/lib/clang/7.0.1/include/omp.h:118:13: fatal error: 'stdlib.h' file not found
If this happens, the macOS SDK headers are missing from /usr/include. They moved into the SDK itself with Xcode 10. Install the headers into /usr/include with
open /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
Other people have given one solution (using Homebrew llvm). You can also use OpenMP with Apple Clang and Homebrew libomp (brew install libomp). Just replace a command like clang -fopenmp test.c with clang -Xpreprocessor -fopenmp test.c -lomp.
MacOS Mojave with CMake
Install LLVM with openmp and libomp with brew
brew update
brew install llvm libomp
add include directories and link directories in CMakeList.txt
include_directories("/usr/local/include" "/usr/local/opt/llvm/include")
link_directories("/usr/local/lib" "/usr/local/opt/llvm/lib")
run CMake with the new compilers
cmake -DCMAKE_C_COMPILER="/usr/local/opt/llvm/bin/clang" -DCMAKE_CXX_COMPILER="/usr/local/opt/llvm/bin/clang++" ..
The clang version is 7.0.1 at time of writing
Conda-Based Compilation Environment
Conda uses clang for OSX compilation (umbrella package cxx-compiler), but I hit similar issues with using llvm-openmp and the -fopenmp flag throwing errors. Solution is rather similar to other answers, but I am including here in case others have more exactly this issue.
Specific solution was to include the Conda environment's include/ directory in the CFLAGS, namely:
CFLAGS="-I${CONDA_PREFIX}/include"
Note, I also needed to add -lstdc++ -Wl,-rpath ${CONDA_PREFIX}/lib -L${CONDA_PREFIX}/lib when linking, similar to this GitHub Issue.
I am running fedora 23 and just compiled and installed casadi 2.4.1 (however, I do not think that this is casadi specific).
I am trying to compile and run a simple test program:
#include <iostream>
#include <casadi/casadi.hpp>
using namespace casadi;
int main () {
const SX m(42);
const SX n(23);
const SX x = m + n ;
std::cout << x << std::endl;
}
It works fine with gcc:
$ g++ test.cpp -std=c++11 -I$HOME/local/include -L$HOME/local/lib -lcasadi && ./a.out
SX(65)
But using clang, I get a linker error:
$ clang++ test.cpp -std=c++11 -I$HOME/local/include -L$HOME/local/lib -lcasadi && ./a.out
/tmp/test-cde41f.o: In function `casadi::GenericMatrix<casadi::Matrix<casadi::SXElement> >::dimString() const':
test.cpp:(.text._ZNK6casadi13GenericMatrixINS_6MatrixINS_9SXElementEEEE9dimStringEv[_ZNK6casadi13GenericMatrixINS_6MatrixINS_9SXElementEEEE9dimStringEv]+0x2b): undefined reference to `casadi::Sparsity::dimString() const'
/tmp/test-cde41f.o: In function `void casadi::Sparsity::set<casadi::SXElement>(casadi::SXElement*, casadi::SXElement const*, casadi::Sparsity const&) const':
test.cpp:(.text._ZNK6casadi8Sparsity3setINS_9SXElementEEEvPT_PKS3_RKS0_[_ZNK6casadi8Sparsity3setINS_9SXElementEEEvPT_PKS3_RKS0_]+0x6f0): undefined reference to `casadi::Sparsity::dimString() const'
test.cpp:(.text._ZNK6casadi8Sparsity3setINS_9SXElementEEEvPT_PKS3_RKS0_[_ZNK6casadi8Sparsity3setINS_9SXElementEEEvPT_PKS3_RKS0_]+0x743): undefined reference to `casadi::Sparsity::dimString() const'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I am pretty confident that the symbol is defined in the library. However, I fail to understand what clang is missing here. Is there some special c++11 ABI flag that I need to pass to the linker or something like that?
I would suspect version skew. Unless you do something special, clang uses some gcc stdc++ library, for which it searches. That was the case the last time I used clang for much. They may use their own std c++ library now. But if casadi was compiled with one version of gcc and you used clang which uses the std c++ library for another version of gcc, you can see linker errors like this.
You may learn something if you run clang -V to get version information. Also, gcc -v to get gcc version information, and verify that the version of gcc clang wants is the same as the version with which you are compiling.
Problem
I am having an issue implementing the g++48 compiler in QT Creator. I built this compiler using MacPorts. It appears that QT Creator ignores my compiler and defaults xcode g++42. How do I properly setup the compiler to override this?
Troubleshooting
Did you install gcc/g++ correctly and is it the main one selected?
I have ensured that gcc was installed correctly and the path is correct by doing the follows:
:~ which gcc:
/opt/local/bin/g++
:~ g++ --version:
g++ (MacPorts gcc48 4.8.1_3) 4.8.1
What system are you using?
My system: Mac OSX 10.9 Mavericks. QT Creator 2.8.1 Based on QT 5.1.0.
Toolchain setup: In QT Creator I specified the custom GCC compiler by going Compilers_Add_GCC and putting in the compiler path /opt/local/bin/g++. If I hover the mouse over any of the #include lines in *.cpp then it properly displays the path /opt/local/include/gcc48/{headerName}. I suspect the problem is related to the QT Mkspecs, but I really don't understand what this is or how to write a custom one for my custom gcc installation (if necessary). Can this be explained?
Kit updated in QT Creator? The kit was updated by following the directions that here: Qt Creator use another GCC Version located in another Place
Why do you suspect g++42 is being used? This is based on the results I get from inspecting the build log file.
12:30:19: Running steps for project untitled...
12:30:19: Configuration unchanged, skipping qmake step.
12:30:19: Starting: "/usr/bin/make"
/Applications/Xcode.app/Contents/Developer/usr/bin/g++ -c -pipe -std=c++11 -g -gdwarf-2 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -mmacosx-version-min=10.6 -Wall -W -fPIE -DQT_QML_DEBUG -DQT_DECLARATIVE_DEBUG -I/Users/raymondvaldes/Qt/5.1.0/clang_64/mkspecs/macx-g++ -I/Users/raymondvaldes/Documents/code/untitled -I. -o main.o /Users/raymondvaldes/Documents/code/untitled/main.cpp
/Users/raymondvaldes/Documents/code/untitled/main.cpp:4:10: fatal error: 'random' file not found
#include <random>
^
1 error generated.
make: *** [main.o] Error 1
12:30:20: The process "/usr/bin/make" exited with code 2.
Error while building/deploying project untitled (kit: gcc48)
When executing step 'Make'
12:30:20: Elapsed time: 00:01.
and
RAYMONDs-MacBook-Air:~ raymondvaldes$ /Applications/Xcode.app/Contents/Developer/usr/bin/g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix
Finally, here is my simple working example:
#include <iostream>
#include <complex>
#include <cmath>
#include <random>
int main()
{
std::cout << "Hello World!" << std::endl;
return 0;
}
and my pro file.
cache()
TEMPLATE = app
CONFIG += console
CONFIG -= app_bundle
CONFIG -= qt
QMAKE_CXXFLAGS += -std=c++11
SOURCES += main.cpp
Thank you.
I finally solved this issue and I am now able to use my MacPorts GCC48 compiler in QT Creator. As I suspected I needed to create a gcc48 mkspecs folder in the QT Directory and feed the folder name to the QT Creator custom compiler setup screen. I created "macs-g++48" folder that was copied from the generic "macs-g++" folder in "~path~QT/5.1.x/clang_64/mkspecs". I had to modify qmake.conf. I commented out
#include(../common/g++-macx.conf)
#include(g++-base.conf)
and placed their contents within quake.conf while making the following modifications:
QMAKE_CC = gcc-mp-4.8
QMAKE_CXX = g++-mp-4.8