Since the recent update Mavericks, I have a problem linking with the library json_spirit.
I installed the new Command Line Tools, but I'm using gcc47 installed via macports. Json spirit (v4.06) has been compiled with the same gcc (after the update).
gcc (MacPorts gcc47 4.7.3_3) 4.7.3
I boiled it down to the following example :
test.cpp
#include <iostream>
#include "json_spirit_reader_template.h"
#include "json_spirit_writer_template.h"
#include "json_spirit_writer.h"
int main(int argc, char **argv) {
json_spirit::mValue a;
std::string s("[]");
json_spirit::read_string(s, a);
std::cout << json_spirit::write_formatted(a) << std::endl;
return 0;
}
which I compile with the following :
g++ -I/usr/local/include test.cpp -o test -L/usr/local/lib -ljson_spirit
And it gives this error :
Undefined symbols for architecture x86_64:
"json_spirit::write_formatted(json_spirit::Value_impl<json_spirit::Config_map<std::basic_strin g<char, std::char_traits<char>, std::allocator<char> > > > const&)", referenced from:
_main in ccwUclng.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
And finally, using "nm -g /usr/local/lib/libjson_spirit.a | grep write_formatted" :
nm: no name list
0000000000000150 T __ZN11json_spirit15write_formattedERKNS_10Value_implINS_10Config_mapINSt3__112basic_stringIcNS2_11char_traitsIcEENS2_9allocatorIcEEEEEEEE
000000000003afa8 S __ZN11json_spirit15write_formattedERKNS_10Value_implINS_10Config_mapINSt3__112basic_stringIcNS2_11char_traitsIcEENS2_9allocatorIcEEEEEEEE.eh
0000000000000120 T __ZN11json_spirit15write_formattedERKNS_10Value_implINS_10Config_mapINSt3__112basic_stringIcNS2_11char_traitsIcEENS2_9allocatorIcEEEEEEEERNS2_13basic_ostreamIcS5_EE
000000000003af80 S __ZN11json_spirit15write_formattedERKNS_10Value_implINS_10Config_mapINSt3__112basic_stringIcNS2_11char_traitsIcEENS2_9allocatorIcEEEEEEEERNS2_13basic_ostreamIcS5_EE.eh
0000000000000270 T __ZN11json_spirit15write_formattedERKNS_10Value_implINS_10Config_mapINSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwEEEEEEEE
000000000003b118 S __ZN11json_spirit15write_formattedERKNS_10Value_implINS_10Config_mapINSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwEEEEEEEE.eh
0000000000000240 T __ZN11json_spirit15write_formattedERKNS_10Value_implINS_10Config_mapINSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwEEEEEEEERNS2_13basic_ostreamIwS5_EE
000000000003b0c8 S __ZN11json_spirit15write_formattedERKNS_10Value_implINS_10Config_mapINSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwEEEEEEEERNS2_13basic_ostreamIwS5_EE.eh
0000000000000090 T __ZN11json_spirit15write_formattedERKNS_10Value_implINS_13Config_vectorINSt3__112basic_stringIcNS2_11char_traitsIcEENS2_9allocatorIcEEEEEEEE
000000000003aeb0 S __ZN11json_spirit15write_formattedERKNS_10Value_implINS_13Config_vectorINSt3__112basic_stringIcNS2_11char_traitsIcEENS2_9allocatorIcEEEEEEEE.eh
0000000000000060 T __ZN11json_spirit15write_formattedERKNS_10Value_implINS_13Config_vectorINSt3__112basic_stringIcNS2_11char_traitsIcEENS2_9allocatorIcEEEEEEEERNS2_13basic_ostreamIcS5_EE
000000000003ae88 S __ZN11json_spirit15write_formattedERKNS_10Value_implINS_13Config_vectorINSt3__112basic_stringIcNS2_11char_traitsIcEENS2_9allocatorIcEEEEEEEERNS2_13basic_ostreamIcS5_EE.eh
0000000000000210 T __ZN11json_spirit15write_formattedERKNS_10Value_implINS_13Config_vectorINSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwEEEEEEEE
000000000003b0a0 S __ZN11json_spirit15write_formattedERKNS_10Value_implINS_13Config_vectorINSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwEEEEEEEE.eh
00000000000001e0 T __ZN11json_spirit15write_formattedERKNS_10Value_implINS_13Config_vectorINSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwEEEEEEEERNS2_13basic_ostreamIwS5_EE
000000000003b078 S __ZN11json_spirit15write_formattedERKNS_10Value_implINS_13Config_vectorINSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwEEEEEEEERNS2_13basic_ostreamIwS5_EE.eh
I don't know how to read the nm output, so I may be missing something obvious.
I've tried to install and uninstall every component (boost ..) one by one, compiling with the gcc from macports and / or the default, which is :
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
Well, this is a half answer, because I never really got to explain exactly what happened, but I fixed it, so..
The answer was to rebuild boost from scratch, (icu as well) with the new system and the same compiler everywhere, for me it's gcc 4.7.3 installed with macports.
Also, I was trying to upgrade from boost 1.53 to boost 1.54, so it may have been part of the problem, but now anyway I went back to boost 1.53.
Related
I am trying to compile some C++ that depends on QuantLib, which in turn depends on Boost. I am working on a MacBook Pro M1 (ARM architecture). I installed Boost and QuantLib using the instructions on this page: https://www.quantlib.org/install/macosx.shtml. I then tried to compile the following source code:
#include <iostream>
#include <ql/quantlib.hpp>
int main(int, char*[])
{
QuantLib::Option::Type OptionType(QuantLib::Option::Call);
std::cout << "Option Type = " << OptionType << std::endl;
return 0;
}
using the following command:
clang++ -std=c++11 ql_ex1.cpp -o build/ql_ex1 $(INC) $(LIB) \
-I/opt/homebrew/Cellar/quantlib/1.23/include -I/opt/homebrew/Cellar/boost/1.76.0/include \
-L/opt/homebrew/Cellar/boost/1.76.0/lib -L/opt/homebrew/Cellar/quantlib/1.23/lib
This gave me the following error message:
Undefined symbols for architecture arm64:
"boost::assertion_failed(char const*, char const*, char const*, long)", referenced from:
long double boost::math::detail::sinpx<long double>(long double) in ql_ex1-044d3e.o
"boost::assertion_failed_msg(char const*, char const*, char const*, char const*, long)", referenced from:
boost::array<long double, 171ul>::operator[](unsigned long) const in ql_ex1-044d3e.o
...
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1
So far I have tried the following approaches,
Install x86 binaries and run clang++ in emulation. I see the same Undefined symbols error.
Try to identify a Boost shared library file that I need to link to. I have not been able to find anything that contains the assertion_failed symbol.
Can someone point me to where (if anywhere) this symbol is defined? It would be useful to know if I am just missing the right compiler options or whether there is a more fundamental issue that needs to be addressed.
I think you're missing a -lQuantLib in your command line? You're telling the compiler where to look for the libraries (the -L switches`) but not which libraries to link.
Also, check whether homebrew also installed a quantlib-config script on your computer. If so, it should provide the switches you need; try running
quantlib-config --cflags
which should output the -I flags specifying the location of the QuantLib headers (and possibly the -std=c++11 flag you're passing manually), and
quantlib-config --libs
which should output the corresponding -L switches as well as the -lQuantLib you missed.
If they work, you can use the command
clang++ ql_ex1.cpp -o build/ql_ex1 $(INC) $(LIB) \
-I/opt/homebrew/Cellar/boost/1.76.0/include \
`quantlib-config --cflags` `quantlib-config --libs`
and let the script fill in the info for you.
I am trying to build a simple SSH client from Wil Allsopp's pen testing book. Working on Mac OS High Sierra with gcc-4.2 with libssh installed using Homebrew. The simplest version of the code is:
#include <libssh/libssh.h>
#include <stdlib.h>
#include <stdio.h>
int main()
{
ssh_session my_ssh_session;
my_ssh_session = ssh_new();
ssh_free(my_ssh_session);
return 0;
}
However a simple gcc build (gcc -Wall ssh_client.c) produces the following error:
Undefined symbols for architecture x86_64:
"_ssh_free", referenced from:
_main in ssh_client-aa8f09.o
"_ssh_new", referenced from:
_main in ssh_client-aa8f09.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1
Can anyone explain these errors and how I can fix them?
Your build line doesn't appear to contain any include and linker flags. I imagine it is picking up the headers but not the library for ssh to link against. Have a look into pkgconfig for an easy way to maintain this.
I built gcc 4.9.0 from source, and was also planning on building clang 3.4.2, however something seems to have gone awry with regards to libstdc++, as the clang build baled pretty quickly with the linker complaining about various undefined references from std.
Indeed, I then tried compiling and linking the trivial program:
#include <iostream>
int main() {
std::cout << 42;
}
and again hit linker errors:
/tmp/ccrptgVW.o:temp.cpp:function main: error: undefined reference to 'std::cout'
/tmp/ccrptgVW.o:temp.cpp:function main: error: undefined reference to 'std::ostream::operator<<(int)'
/tmp/ccrptgVW.o:temp.cpp:function __static_initialization_and_destruction_0(int, int): error: undefined reference to 'std::ios_base::Init::Init()'
/tmp/ccrptgVW.o:temp.cpp:function __static_initialization_and_destruction_0(int, int): error: undefined reference to 'std::ios_base::Init::~Init()'
collect2: error: ld returned 1 exit status
(full gcc -v output), both with my freshly-minted gcc 4.9.0 and my Ubuntu's stock gcc 4.6.3.
libstdc++.so exists, in /usr/local/lib64:
ls /usr/local/lib64/libstd*
/usr/local/lib64/libstdc++.a
/usr/local/lib64/libstdc++.so
/usr/local/lib64/libstdc++.so.6.0.20
/usr/local/lib64/libstdc++.la
/usr/local/lib64/libstdc++.so.6
/usr/local/lib64/libstdc++.so.6.0.20-gdb.py
and this directory appears in LIBRARY_PATH and as an -L argument to collect2 in the verbose gcc output.
How do I restore sanity to my system and have the linker find the shared library?
As turns out from your comment, you compiled with gcc rather than g++.
Do not take it as an error, as the compilation went fine! What's showing up is a linker error. Indeed, gcc will tell ld to link against the C standard library rather than the C++ standard one.
To solve, either go for g++ directly or pass -lstdc++.
I try to build a simple Qt 5 program on Mac. But I failed.
The code is very simple:
#include <QtWidgets/QApplication>
int main(int argc, char *argv[])
{
QApplication app (argc, argv);
return app.exec();
}
I used:
clang++ -I ~/Qt5.0.0/5.0.0/clang_64/include -L/Users/crazylion/Qt5.0.0/5.0.0/clang_64/lib test.cpp
Then I got this error:
Undefined symbols for architecture x86_64:
"QApplication::exec()", referenced from:
_main in test-jPGORy.o
"QApplication::QApplication(int&, char**, int)", referenced from:
_main in test-jPGORy.o
"QApplication::~QApplication()", referenced from:
_main in test-jPGORy.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Is there anything i missing?
Firstly, don't compile and link Qt projects by hand; use qmake and project files.
Run qmake -project in your source directory to generate a basic project file.
Edit the project file and add the following line: QT += widgets
Now run qmake to generate a makefile.
Now run make to build your program.
Secondly, you can simply #include <QApplication>
If you want to use clang++ in favor of qmake, you need to specify libraries to link against to, along with the library directory (which you supplied).
clang++ -I ~/Qt5.0.0/5.0.0/clang_64/include -L/Users/crazylion/Qt5.0.0/5.0.0/clang_64/lib -lQtCore -lQtGui test.cpp
I had the same problems and it seems to me that there is some sort of bug in the release it gave me some errors because out of a fresh install (using qt creator) i didn't have some obscure qt library (not the normal qt5 modules but some sort of library in development) so I tend to think that it could be qt's problem
That said I have some questions to better understand:
-are you using a IDE?
-if you are using one which is it?
-are you including all the modules in the *.pro for quake?
-have you used 4.8 version, did you experienced these problems with that?
P.S. if you do not have any particular necessity I suggest you to stick to version 4.8 for some time (as I am doing without problem) since 5.0 is just been released
I have been using OpenCV for a while and also the imwrite function, but unfortunately this is not working any more.
I am running with OpenCV 2.4.3 with following sample code:
imwrite("somepath/somefile.png", myMat);
The error:
Undefined symbols for architecture x86_64:
"cv::imwrite(std::string const&, cv::_InputArray const&, std::__debug::vector<int, std::allocator<int> > const&)", referenced from:
MyProject::this_callback(int, void*) in MyProject.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
The error looks somewhat familiar but i cannot determine whats wrong.
Yes, I've thought you were using XCode. I had the same problem. :)
If you change the project setup so that:
you use GNU++11 as C++ language dialect
libstdc++ (GNU C++ standard) as C++ standard library
your linking problem will go away.
I use Apple LLVM 4.1.
When I had this problem, I have tried just adding a new target to one of my old projects I knew, worked. Then I've just made that target a one-source-file program.
This must be a "magic" part of XCode as I think there was a time I could not get the same project working after a restart. :S
I did what Barnabas did and also got the issue on cvdef.h. I was getting desperate so and what I did was just changed the header file.
in /usr/local/cvdef.h line 205:
I changed
include <cstdint>
typedef std::uint32_t uint;
to:
include <tr1/cstdint>
typedef std::tr1::uint32_t uint;
based on this post
I think opencv devs should apply some changes to the code for 64bit..
use something like clang version 3.8.0 (trunk 257459), instead of gcc version 4.9.2 (MacPorts gcc49 4.9.2_1+universal) to compile
for reference, cmd: clang++ -std=c++11 `pkg-config --cflags --libs opencv` code.cpp -o code