I've run into a problem trying to call boundary conditions in halide code. I'm using the binary build halide-mac-64-trunk... from the site. I've had no other problems calling other halide functions.
Image input = load_image(argv[1]);
bounded_luma = Halide::BoundaryConditions::repeat_edge(input);
Undefined symbols for architecture x86_64:
"Halide::BoundaryConditions::repeat_edge(Halide::Func const&, std::__1::vector, std::__1::allocator > > const&)", referenced from:
Halide::Func Halide::BoundaryConditions::repeat_edge, int, int, int, int>(Halide::Buffer, int, int, int, int) in main.o
ld: symbol(s) not found for architecture x86_64
The __1s indicate that it could be that libHalide was compiled with libc++, and you're compiling with libstdc++ (or vice-versa). Try adding -stdlib=libc++ or -stdlib=libstdc++ to your compile flags.
Related
I have a library that is written in a mixture of Fortran and C++. It also uses MPI at the Fortran layer. Let's say a user wants to link a new c++ program against my library. From what I've found on the internet, the best way to do this is to have them compile their code with a C++ compiler, and link against my library using the mpif90 fortran wrapper. This is to make sure you link against the correct version of MPI. But in order to make this all work, you also have to link against libc++ explicitly because otherwise your c++ program won't work. So, for example:
mpic++ their_code.cc -c
mpif90 their_code.o -o program.exe -lmylib -lstdc++
This approach has worked fine for me across many platforms and compilers (gnu, intel, etc). It also worked for clang, until the release of Xcode 9.0, which broke this process. The compiler errors appear to be related to incompatibility in the c++ standard library, because it only breaks when I call functions that pass std::string. In the Xcode release notes it says:
Projects created using this Xcode release use the new libc++ implementation of the standard C++ library. The libc++ library is available only on iOS 5.0 and later and OS X 10.7 and later. 12221787
To enable deployment on earlier releases of iOS and OS X in your project, set the C++ Standard Library build setting to libstdc++ (Gnu C++ standard library).
This leads me to believe I need to modify how I link against libc++. You can reproduce this issue with the following code (assuming you have upgraded Xcode to version 9).
main.cc:
#include<string>
using namespace std;
void fun_str(string s);
void fun_num(int n);
int main() {
string my_str = "test";
int my_num = 1;
fun_str(my_str);
fun_num(my_num);
return 0;
}
fun.cc:
#include <string>
using namespace std;
void fun_str(string s) {}
void fun_num(int n) {}
Makefile:
test: main.o fun.o
mpif90 main.o fun.o -o program.exe -lstdc++
main.o: main.cc
mpic++ main.cc -c
fun.o: fun.cc
mpic++ fun.cc -c
Notice how if you remove all the references to strings, it does compile correctly. But if not, you get the following error:
mpic++ main.cc -c
mpic++ fun.cc -c
mpif90 main.o fun.o -o program.exe -lstdc++
Undefined symbols for architecture x86_64:
"std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__init(char const*, unsigned long)", referenced from:
_main in main.o
"std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_string(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from:
_main in main.o
"std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::~basic_string()", referenced from:
_main in main.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make: *** [test] Error 1
Additionally, if you switch to GNU by setting the environment variable OMPI_CXX to g++-7, it also compiles without a hitch. So this is definitely just a Clang issue, that only showed up in the new version. Any help would be greatly appreciated :)!
I fixed this on my own, but using -lc++ instead of -lstdc++. It seems that libstdc++ is depreciated with clang.
I am currently trying to compile a Contraction Hierachies implementation by KIT which requires Boost::Regex. The supplied Makefile already makes sure (and I have also double-checked this manually) that g++ is supplied with the -lboost_regex switch. If the library is not installed, g++ will complain.
So I installed the library from my package sources and tried compiling again. This time I am getting a huge load of linker errors regarding Boost::Regex. Here is a short excerpt:
main.o: In function `boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::unwind_extra_block(bool)':
main.cpp:(.text._ZN5boost9re_detail12perl_matcherIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE18unwind_extra_blockEb[_ZN5boost9re_detail12perl_matcherIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE18unwind_extra_blockEb]+0x2c): undefined reference to `boost::re_detail::put_mem_block(void*)'
main.o: In function `void boost::re_detail::raise_error<boost::regex_traits_wrapper<boost::regex_traits<char, boost::cpp_regex_traits<char> > > >(boost::regex_traits_wrapper<boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::error_type)':
main.cpp:(.text._ZN5boost9re_detail11raise_errorINS_20regex_traits_wrapperINS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEEEEEvRKT_NS_15regex_constants10error_typeE[_ZN5boost9re_detail11raise_errorINS_20regex_traits_wrapperINS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEEEEEvRKT_NS_15regex_constants10error_typeE]+0x7d): undefined reference to `boost::re_detail::get_default_error_string(boost::regex_constants::error_type)'
main.cpp:(.text._ZN5boost9re_detail11raise_errorINS_20regex_traits_wrapperINS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEEEEEvRKT_NS_15regex_constants10error_typeE[_ZN5boost9re_detail11raise_errorINS_20regex_traits_wrapperINS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEEEEEvRKT_NS_15regex_constants10error_typeE]+0xb1): undefined reference to `boost::re_detail::raise_runtime_error(std::runtime_error const&)'
main.cpp:(.text._ZN5boost9re_detail11raise_errorINS_20regex_traits_wrapperINS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEEEEEvRKT_NS_15regex_constants10error_typeE[_ZN5boost9re_detail11raise_errorINS_20regex_traits_wrapperINS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEEEEEvRKT_NS_15regex_constants10error_typeE]+0xcb): undefined reference to `boost::re_detail::get_default_error_string(boost::regex_constants::error_type)'
main.o: In function `__gnu_cxx::__normal_iterator<char const*, std::string> boost::re_detail::re_is_set_member<__gnu_cxx::__normal_iterator<char const*, std::string>, char, boost::regex_traits<char, boost::cpp_regex_traits<char> >, unsigned int>(__gnu_cxx::__normal_iterator<char const*, std::string>, __gnu_cxx::__normal_iterator<char const*, std::string>, boost::re_detail::re_set_long<unsigned int> const*, boost::re_detail::regex_data<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, bool)':
main.cpp:(.text._ZN5boost9re_detail16re_is_set_memberIN9__gnu_cxx17__normal_iteratorIPKcSsEEcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEjEET_SB_SB_PKNS0_11re_set_longIT2_EERKNS0_10regex_dataIT0_T1_EEb[_ZN5boost9re_detail16re_is_set_memberIN9__gnu_cxx17__normal_iteratorIPKcSsEEcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEjEET_SB_SB_PKNS0_11re_set_longIT2_EERKNS0_10regex_dataIT0_T1_EEb]+0x17b): undefined reference to `boost::re_detail::cpp_regex_traits_implementation<char>::transform_primary(char const*, char const*) const'
main.cpp:(.text._ZN5boost9re_detail16re_is_set_memberIN9__gnu_cxx17__normal_iteratorIPKcSsEEcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEjEET_SB_SB_PKNS0_11re_set_longIT2_EERKNS0_10regex_dataIT0_T1_EEb[_ZN5boost9re_detail16re_is_set_memberIN9__gnu_cxx17__normal_iteratorIPKcSsEEcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEjEET_SB_SB_PKNS0_11re_set_longIT2_EERKNS0_10regex_dataIT0_T1_EEb]+0x4c0): undefined reference to `boost::re_detail::cpp_regex_traits_implementation<char>::transform(char const*, char const*) const'
main.o: In function `boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::extend_stack()':
main.cpp:(.text._ZN5boost9re_detail12perl_matcherIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE12extend_stackEv[_ZN5boost9re_detail12perl_matcherIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE12extend_stackEv]+0x18): undefined reference to `boost::re_detail::get_mem_block()'
main.o: In function `boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::match_imp()':
main.cpp:(.text._ZN5boost9re_detail12perl_matcherIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE9match_impEv[_ZN5boost9re_detail12perl_matcherIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE9match_impEv]+0xc): undefined reference to `boost::re_detail::get_mem_block()'
main.cpp:(.text._ZN5boost9re_detail12perl_matcherIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE9match_impEv[_ZN5boost9re_detail12perl_matcherIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE9match_impEv]+0x19e): undefined reference to `boost::re_detail::verify_options(unsigned int, boost::regex_constants::_match_flags)'
main.cpp:(.text._ZN5boost9re_detail12perl_matcherIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE9match_impEv[_ZN5boost9re_detail12perl_matcherIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE9match_impEv]+0x254): undefined reference to `boost::re_detail::put_mem_block(void*)'
main.cpp:(.text._ZN5boost9re_detail12perl_matcherIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE9match_impEv[_ZN5boost9re_detail12perl_matcherIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE9match_impEv]+0x3c6): undefined reference to `boost::re_detail::put_mem_block(void*)'
This looks very much like the compiler did not find the library at all. In fact, when I don't supply the -lboost_regex switch the output remains the same (I ran a hash on it).
However, running the linker with the -Wl,--verbose switch as suggested in nuwen MinGW + Boost- error linking boost_regex shows that the library is found:
attempt to open /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/libboost_regex.so succeeded
-lboost_regex (/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/libboost_regex.so)
All I know is that this is likely a different boost version than what was around when the software was written (I don't know which. I am using 1.53 now.) but from looking at the code it seems it should still work. Also I am using the headers from this boost version so the compiler should already complain if function signatures have changed.
How can I get this to link? Am I missing something?
Linker switches are in the wrong order. make tries to do this:
g++ -lboost_regex -lboost_iostreams -o main main.o
This is what actually works (at least with gcc 4.8.1):
g++ -o main main.o -lboost_regex -lboost_iostreams
So to fix the compilation error you should substitue line 6 in the Makefile with the following:
$(CXX) -o $# $^ $(LIBS) $(LINK)
Boost regex (and other boost libs, probably) may also fail to link if you have multiple versions of boost available, and the linker path and include paths point to different versions (this happened to me with cmake when using find_package(Boost ...) where a path was specified while also having a different version installed in the system root.
The solution in the case of cmake was to add include_directories(${Boost_INCLUDE_DIRS}) to CMakeLists.txt as well as ensuring the correct link ordering in the target_link_libraries.
I built the i386 flavor of OpenCV locally on my Macbook running Lion, by using
cmake -G "Unix Makefiles" -D CMAKE_OSX_ARCHITECTURES=i386 -D CMAKE_C_FLAGS=-m32 -D CMAKE_CXX_FLAGS=-m32 ..
make -j8
sudo make install
Libraries built and published fine, and I've added them to my xcode project.
However, there are link errors when building my test app, and they seem to be name mangling issues.
Undefined symbols for architecture i386:
"cv::namedWindow(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int)", referenced from:
_main in main.o
"cv::imread(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int)", referenced from:
_main in main.o
"cv::imshow(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, cv::_InputArray const&)", referenced from:
_main in main.o
Taking cv::imread as an example, it is exported from libopencv_highgui.dylib with the name:
00007510 (__TEXT,__text) external __ZN2cv6imreadERKSsi
while main.o is referencing the symbol
U __ZN2cv6imreadERKNSt3__112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEEi
On the other hand, function __ZN2cv7waitKeyEi from the same dylib links fine.
Both the test app and the framework are for i386 arch.
Any ideas what might be causing this issue?
I've had the same problem. I think the issue could be that if you have used the MacPorts to compile your OpenCV libraries, they probably got built by the GCC according to it's Portfile. I switched the compiler used in the XCode (Apple LLVM 4.1) to the LLVM GCC 4.2 and now it works.
Hope it helps.
I just had the same problem and fixed it by using libstdc++ as the C++ standard library. It was defaulted to libc++
Under Project Build settings -> APPLE LLVM compiler 4.2 - Language -> C++ Standard Library
I'm attempting to get the following Crypto++ (C++ Class Library of Cryptographic Schemes) example to work on a iMac using clang++.
Example
SHA256 hash;
byte digest[ SHA256::DIGESTSIZE ];
hash.CalculateDigest( digest, (byte*) &value[ 0 ], value.size( ) );
HexEncoder encoder;
string result = String::empty;
encoder.Attach( new StringSink( result ) );
encoder.Put( digest, sizeof( digest ) );
encoder.MessageEnd( );
Build command
Apple clang version 2.1 (tags/Apple/clang-163.7.1) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.4.0
Thread model: posix
"/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.7.4 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name checksum_impl.cpp -pic-level 2 -mdisable-fp-elim -relaxed-aliasing -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 123.2.1 -v -resource-dir /usr/bin/../lib/clang/2.1 -D framework_EXPORTS -I /Users/Ben/Dropbox/appon/build/../source -nostdinc++ -cxx-isystem /usr/include/c++/v1 -Wall -Wextra -Weffc++ -pedantic -std=c++0x -fdeprecated-macro -ferror-limit 19 -fmessage-length 175 -stack-protector 1 -fblocks -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o CMakeFiles/framework.dir/Users/Ben/Dropbox/source/example.cpp.o -x c++ /Users/Ben/Dropbox/source/example.cpp
clang -cc1 version 2.1 based upon llvm 3.0svn hosted on x86_64-apple-darwin11.4.0
#include "..." search starts here:
#include <...> search starts here:
/Users/Ben/Dropbox/build/../source
/usr/include/c++/v1
/usr/local/include
/usr/bin/../lib/clang/2.1/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
Linker output
clang: warning: argument unused during compilation: '-std=c++0x'
Undefined symbols for architecture x86_64:
"CryptoPP::Filter::TransferTo2(CryptoPP::BufferedTransformation&, unsigned long long&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, bool)", referenced from:
vtable for CryptoPP::SimpleProxyFilter in checksum_impl.cpp.o
vtable for CryptoPP::Bufferless<CryptoPP::Filter> in checksum_impl.cpp.o
vtable for CryptoPP::Unflushable<CryptoPP::Filter> in checksum_impl.cpp.o
"CryptoPP::Filter::CopyRangeTo2(CryptoPP::BufferedTransformation&, unsigned long long&, unsigned long long, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, bool) const", referenced from:
vtable for CryptoPP::SimpleProxyFilter in checksum_impl.cpp.o
vtable for CryptoPP::Bufferless<CryptoPP::Filter> in checksum_impl.cpp.o
vtable for CryptoPP::Unflushable<CryptoPP::Filter> in checksum_impl.cpp.o
"CryptoPP::BufferedTransformation::ChannelCreatePutSpace(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned long&)", referenced from:
vtable for CryptoPP::SimpleProxyFilter in checksum_impl.cpp.o
vtable for CryptoPP::Bufferless<CryptoPP::Filter> in checksum_impl.cpp.o
vtable for CryptoPP::Unflushable<CryptoPP::Filter> in checksum_impl.cpp.o
"CryptoPP::BufferedTransformation::ChannelPut2(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned char const*, unsigned long, int, bool)", referenced from:
vtable for CryptoPP::SimpleProxyFilter in checksum_impl.cpp.o
vtable for CryptoPP::Bufferless<CryptoPP::Filter> in checksum_impl.cpp.o
vtable for CryptoPP::Unflushable<CryptoPP::Filter> in checksum_impl.cpp.o
"CryptoPP::BufferedTransformation::ChannelPutModifiable2(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned char*, unsigned long, int, bool)", referenced from:
vtable for CryptoPP::SimpleProxyFilter in checksum_impl.cpp.o
vtable for CryptoPP::Bufferless<CryptoPP::Filter> in checksum_impl.cpp.o
vtable for CryptoPP::Unflushable<CryptoPP::Filter> in checksum_impl.cpp.o
"CryptoPP::BufferedTransformation::ChannelFlush(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, bool, int, bool)", referenced from:
vtable for CryptoPP::SimpleProxyFilter in checksum_impl.cpp.o
vtable for CryptoPP::Bufferless<CryptoPP::Filter> in checksum_impl.cpp.o
"CryptoPP::BufferedTransformation::ChannelMessageSeriesEnd(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int, bool)", referenced from:
vtable for CryptoPP::SimpleProxyFilter in checksum_impl.cpp.o
vtable for CryptoPP::Bufferless<CryptoPP::Filter> in checksum_impl.cpp.o
vtable for CryptoPP::Unflushable<CryptoPP::Filter> in checksum_impl.cpp.o
"CryptoPP::BufferedTransformation::SetRetrievalChannel(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from:
vtable for CryptoPP::SimpleProxyFilter in checksum_impl.cpp.o
vtable for CryptoPP::Bufferless<CryptoPP::Filter> in checksum_impl.cpp.o
vtable for CryptoPP::Unflushable<CryptoPP::Filter> in checksum_impl.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: *** [all] Error 2
I'm using the latest development version of Crypto++ 5.6.2 as the previous version 5.6.1 fails to build with clang++. However i'm encountering build issues stating that i have missing symbols for x86_64 architecture.
Any hints would be greatly appreciated.
Crypto++ 5.6.2 successfully build on LLVM version 6.1.0 (clang-602.0.53) with make options:
CXXFLAGS="-std=c++11 -stdlib=libstdc++ -DCRYPTOPP_DISABLE_ASM -Wno-c++11-narrowing"
accordingly this script: https://github.com/mapnik/mapnik-packaging/blob/master/osx/scripts/build_cryptopp.sh
-stdlib=libstdc++ need for MacOSX since Mavericks, see: When is it necessary to use use the flag -stdlib=libstdc++?
you need to link to the library that provides those symbols, which should be libcryptopp.so, using-lcryptopp in the compiler command
Looking at your "build command" (which is not the command you're running, it's the output of the command you're running, it would be a lot easier to read if you showed the actual command) it seems you are compiling a .cpp file into a .o file, but getting a linker error, which is strange as producing a .o file is usualy the step before linking. What step are you trying to do? Maybe you also need to add -c so it only compiles and doesn't try to link. You will still need -lcryptopp when linking.
In addition to Jonathon's answer because this is a fairly prevalent problem when -lcryptopp is specified...
Undefined symbols for architecture x86_64. CryptoPP::Filter::TransferTo2(CryptoPP::BufferedTransformation&, unsigned long long&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, bool)"...
The __1 indicates you are using the LLVM C++ runtime (libc++). Somewhere, you are probably mixing and matching with the GNU C++ runtime (libstdc++). The GNU C++ runtime (libstdc++) lacks the __1 decoration on its symbols.
You should go through the project and all pre-built libraries, and ensure they are using one or the other. For each, you should use CXXFLAGS of either (1) -stdlib=libc++ (LLVM), or (2) -stdlib=libstdc++ (GNU).
Be aware that IDEs like Xcode may use a different -stdlib=... setting than Crypto++. In this case, have Xcode match Crypto++, or rebuild the Crypto++ library to match Xcode.
If Xcode is using LLVM's libc++ and you have to rebuild Crypto++, then open the GNUmakefile and rework this section (around line 90):
ifeq ($(UNAME),Darwin)
AR = libtool
ARFLAGS = -static -o
CXX = c++
IS_GCC2 = $(shell $(CXX) -v 2>&1 | $(EGREP) -c gcc-932)
ifeq ($(IS_GCC2),1)
CXXFLAGS += -fno-coalesce-templates -fno-coalesce-static-vtables
LDLIBS += -lstdc++
LDFLAGS += -flat_namespace -undefined suppress -m
endif
endif
If you want to use LLVM's libc++, then remove:
# GNU C++ Runtime
LDLIBS += -lstdc++
And add:
# LLVM C++ Runtime
CXXFLAGS += -stdlib=libc++
For completeness, if you want to use GNU's runtime, then remove the LDLIBS += -lstdc++ and add CXXFLAGS += -stdlib=libstdc++.
You can also change CXX = c++ to CXX ?= c++ so the makefile will use c++ if its not specified in the environment or command line.
If interested, the __1 is an inline namespace used for versioning. See What are inline namespaces for? and Where does the __1 symbol come from when using LLVM's libc++?.
This issue was relating to Crypto++ not having been ported over to llvm-clang++. The supported compilers are listed on Platforms; supported compilers for previous releases are listed on Compiling.
My solution was to instead use GCrypt.
Sorry I can't supply anymore details on the cause of the failure.
I'm creating a browser plugin that handles joystick input across all browser and platforms. It's working on Linux and Windows, but I'm having trouble linking to the OIS library in XCode.
I've built OIS and get libOIS.a and OIS.dylib and am linking them with CMake as follows:
find_library(CARBON NAMES Carbon)
find_library(IOKIT NAMES IOKit)
target_link_libraries(${PROJECT_NAME}
${PLUGIN_INTERNAL_DEPS}
${CARBON}
${IOKIT}
"${CMAKE_CURRENT_SOURCE_DIR}/lib/libOIS.a"
)
But I'm still getting errors every time I try to use the OIS classes from my code and build the project:
ld warning: in /Users/Lana/Documents/STRd6/boomsticks/Boomstick/lib/libOIS.a, missing required architecture x86_64 in file
Undefined symbols:
"OIS::InputManager::destroyInputSystem(OIS::InputManager*)", referenced from:
JoysticksHandler::~JoysticksHandler()in Joysticks.o
JoysticksHandler::~JoysticksHandler()in Joysticks.o
"OIS::InputManager::createInputSystem(std::multimap<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >&)", referenced from:
JoysticksHandler::initialize() in Joysticks.o
"OIS::InputManager::enableAddOnFactory(OIS::InputManager::AddOnFactories)", referenced from:
JoysticksHandler::initialize() in Joysticks.o
"OIS::InputManager::getNumberOfDevices(OIS::Type)", referenced from:
JoysticksHandler::initialize() in Joysticks.o
"typeinfo for OIS::Exception", referenced from:
GCC_except_table44 in Joysticks.o
"OIS::InputManager::createInputObject(OIS::Type, bool, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)", referenced from:
JoysticksHandler::initialize() in Joysticks.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
I don't know anything about XCode, but I was able to get the same code building with a very similar process on Linux and Windows.
The linker warning here gives you a clue:
ld warning: in /...k/lib/libOIS.a, missing required architecture x86_64 in file
The linker is telling you that you're trying to link in a library file that has no implementation for the x86_64 architecture. How did you build that library?
Either you're building a universal binary executable, and the symbols are just not there for the x86_64 version... or perhaps you have a header file for a newer version of the library, but have not updated the .a file, and the symbols you reference in your application code just don't exist in the .a file in your source tree...