I've written a simple c++ program, test.cpp:
#include <iostream>
#include <string>
using namespace std;
int main() {
string s;
cin >> s;
cout << s << endl;
return 0;
}
Why does runnning gcc test.cpp -o mytest give me these errors, and more?
Undefined symbols for architecture x86_64:
"std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string()", referenced from:
_main in cc8rGYVq.o
"std::cin", referenced from:
_main in cc8rGYVq.o
Don't use the executable named gcc to compile and link C++ programs; you must use g++. Not only does it select the appropriate compiler options, it also links with the right libraries for your language (which is the problem you're having here.)
"gcc" command compiles C code, in order to compile C++ code you should use "g++"
Related
I can compile a program that uses only semaphores or one that uses only the sio_client websocket library. However, when compiling a simple program that contains both libraries, I deal with gigantic compilation problems that I don't even know how to describe.
#include <iostream>
#include <thread>
#include <chrono>
// #include <sio_client.h>
#include "socket.io-client-cpp/src/sio_client.h"
#include <semaphore>
using namespace sio;
using namespace std;
sio::client io;
counting_semaphore<1>* test;
//g++-11 main.cpp -std=c++17 -o app -L /usr/local/lib -l sioclient -I /usr/local/include
void OnMessage(sio::event &m){
auto messages = m.get_messages();
io.socket()->emit("key", string("Hello"));
test->release();
}
int main()
{
sio::client io;
io.connect("http://127.0.0.1:8081");
string command = "w";
test = new counting_semaphore<1>(0);
io.socket()->on("teste", &OnMessage);
while(true){
test->acquire();
cout << " :D " << endl;
this_thread::sleep_for(100ms);
}
}
If I replace the include "socket.io-client-cpp/src/sio_client.h" by <sio_client.h> the compiler does not find the sio_client library, and if I include the library path manually, as it is in the code, the error is bigger than the bible.
It is important to point out that I did the sio_client installation process according to the README.md included in the library itself and I have already used it in other contexts, which worked perfectly.
To compile this program I'm using the following command:
g++-11 main.cpp -std=c++2a -L. -lsioclient -o app
beginning of errors:
ld: warning: dylib (/usr/local/Cellar/gcc/11.1.0_1/lib/gcc/11/libstdc++.dylib) was built for newer macOS version (11.3) than being linked (11.1)
Undefined symbols for architecture x86_64:
"__ZN3sio6client6socketERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE", referenced from:
__Z9OnMessageRN3sio5eventE in ccKuChIE.o
_main in ccKuChIE.o
"__ZN3sio6client7connectERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE", referenced from:
_main in ccKuChIE.o
"__ZN3sio6socket2onERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKSt8functionIFvRNS_5eventEEE", referenced from:
_main in ccKuChIE.o
"__ZN3sio6socket4emitERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKNS_7message4listERKSt8functionIFvSC_EE", referenced from:
__Z9OnMessageRN3sio5eventE in ccKuChIE.o
"__ZNKSt3__110error_code7messageEv", referenced from:
__ZN11websocketpp9transport4asio8endpointINS_6config11asio_client16transport_configEE9init_asioEv in libsioclient.a(sio_client_impl.cpp.o)
__ZN3sio11client_impl12connect_implERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEES9_ in libsioclient.a(sio_client_impl.cpp.o)
__ZN11websocketpp10connectionINS_6config11asio_clientEE14replace_headerERKNSt3__112basic_stringIcNS4_11char_traitsIcEENS4_9allocatorIcEEEESC_ in libsioclient.a(sio_client_impl.cpp.o)
__ZN3sio11client_impl9send_implERKNSt3__110shared_ptrIKNS1_12basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEEEEN11websocketpp5frame6opcode5valueE in libsioclient.a(sio_client_impl.cpp.o)
__ZN11websocketpp9exceptionC1ENSt3__110error_codeE in libsioclient.a(sio_client_impl.cpp.o)
__ZN11websocketpp8endpointINS_10connectionINS_6config11asio_clientEEES3_E17create_connectionEv in libsioclient.a(sio_client_impl.cpp.o)
__ZN11websocketpp10connectionINS_6config11asio_clientEE17handle_read_frameERKNSt3__110error_codeEm in libsioclient.a(sio_client_impl.cpp.o)
...
"__ZNKSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE13find_first_ofEPKcmm", referenced from:
__ZN3sio6packet5parseERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEE in libsioclient.a(sio_packet.cpp.o)
"__ZNKSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE4findEcm", referenced from:
__ZN3sio11client_impl12connect_implERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEES9_ in libsioclient.a(sio_client_impl.cpp.o)
__ZN3sio6packet5parseERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEE in libsioclient.a(sio_packet.cpp.o)
"__ZNKSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE7compareEmmPKcm", referenced from:
__ZN3sio11client_impl12connect_implERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEES9_ in libsioclient.a(sio_client_impl.cpp.o)
__ZN3sio11client_impl6socketERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEE in libsioclient.a(sio_client_impl.cpp.o)
__ZN11websocketpp4http6parser6parser12prepare_bodyEv in libsioclient.a(sio_client_impl.cpp.o)
__ZN11websocketpp3uriC2ENSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEERKS7_S9_ in libsioclient.a(sio_client_impl.cpp.o)
__ZN11websocketpp3uriC2ERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEES9_S9_S9_ in libsioclient.a(sio_client_impl.cpp.o)
__ZNK11websocketpp9processor6hybi00INS_6config11asio_clientEE18validate_handshakeERKNS_4http6parser7requestE in libsioclient.a(sio_client_impl.cpp.o)
__ZNK11websocketpp9processor6hybi13INS_6config11asio_clientEE18validate_handshakeERKNS_4http6parser7requestE in libsioclient.a(sio_client_impl.cpp.o)
...
I'm using an external library that has a class bplus_tree that is defined in a namespace bpt. The class declaration is below
// bpt.h
class bplus_tree {
public:
bplus_tree(const char *path, bool force_empty = false);
// bpt.cc
bplus_tree::bplus_tree(const char *p, bool force_empty)
: fp(NULL), fp_level(0)
{ code here }
I'm referencing it from another file main.cpp that has the following code
// main.cpp
#include "BPlusTree/bpt.h" // This is the correct path to the bpt.h file
bplus_tree tree("", false); // Error here
When I try and compile this with g++ main.cpp -o main -std=c++11, I get the following error.
error: unknown type name 'bplus_tree'; did you mean 'bpt::bplus_tree'?
When I change bplus_tree to bpt::bplus_tree, however, I get the new error:
Undefined symbols for architecture x86_64:
"bpt::bplus_tree::bplus_tree(char const*, bool)", referenced from:
_main in main_2-c3bbcc.o
ld: symbol(s) not found for architecture x86_64
I've tried a lot of different combinations for a couple hours now, and I'm honestly not sure what's going on. Is it just something obvious that I am missing or what else am I not getting?
I am writing a short program to test calling the fortran Stripack library from c++. The c++ and fortran files each compile successfully, but errors occur when linking.
The c++ code is as follows:
#include <iostream>
#include <cmath>
#ifdef __cplusplus
extern"C" {
#endif
void trmesh_(int&,float[],float[],float[],int[],int[],int[],int&,int[],int[],float[],int&);
void trlist2_(int&,int[],int[],int[],int&,int[][3],int&);
#ifdef __cplusplus
}
#endif
int main(){
// Variables for distributing points on sphere.
int polar = 16;
int azimuth = 32;
int n = polar*azimuth-azimuth+2;
float radius=1.0;
// Define variables needed by Stripack
float xs[n];
float ys[n];
float zs[n];
int list[6*(n-2)];
int lptr[6*(n-2)];
int lend[6*(n-2)];
int near[n];
int next[n];
float dist[n];
int ltri[2*n-4][3];
int lnew;
int ier;
int nt;
// Distribute n points on surface of unit sphere .
// xs, ys, zs store x, y, and z components pf each point position.
zs[0] = 1;
xs[0] = 0;
ys[0] = 0;
zs[n] = -1;
xs[n] = 0;
ys[n] = 0;
for (int ii=1; ii<polar; ii++){
for (int jj=0; jj<azimuth; jj++){
zs[(ii-1)*azimuth+jj+1] = radius*cos(ii*M_PI/polar);
xs[(ii-1)*azimuth+jj+1] = radius*sin(ii*M_PI/polar)*sin(jj*2*M_PI/azimuth);
ys[(ii-1)*azimuth+jj+1] = radius*sin(ii*M_PI/polar)*cos(jj*2*M_PI/azimuth);
}
}
// Call stripack subroutines to obtain list of triangles ltri
trmesh_(n,xs,ys,zs,list,lptr,lend,lnew,near,next,dist,ier);
trlist2_(n,list,lptr,lend,nt,ltri,ier);
// Output list of triangles
for (int ii =0; ii<n; ii++){
std::cout << ltri[ii][0] << " " << ltri[ii][1] << " " << ltri[ii][2] << std::endl;
}
}
I compile the files as follows:
ifort -c stripack.f90
clang++ -c -O0 -std=c++11 -c -o main.o main.cpp -g
clang++ -o main stripack.o main.o
The first two compilations work fine, but the last one produces the following results. It seems like the subroutines in the fortran file can't find standard fortran functions? I have tried with gfortran and the same problem occurs. Any suggestions as to what is going on would be greatly appreciated.
Undefined symbols for architecture x86_64:
"___libm_sse2_sincos", referenced from:
_trplot_ in stripack.o
_vrplot_ in stripack.o
"___svml_sincos2", referenced from:
_trans_ in stripack.o
"_for_date_and_time", referenced from:
_timestamp_ in stripack.o
"_for_stop_core", referenced from:
_trmesh_ in stripack.o
_addnod_ in stripack.o
"_for_trim", referenced from:
_timestamp_ in stripack.o
"_for_write_seq_fmt", referenced from:
_delnod_ in stripack.o
_edge_ in stripack.o
_timestamp_ in stripack.o
_trlprt_ in stripack.o
_trmesh_ in stripack.o
_addnod_ in stripack.o
_trplot_ in stripack.o
...
"_for_write_seq_fmt_xmit", referenced from:
_delnod_ in stripack.o
_edge_ in stripack.o
_timestamp_ in stripack.o
_trlprt_ in stripack.o
_trmesh_ in stripack.o
_addnod_ in stripack.o
_trplot_ in stripack.o
...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I will demonstrate this is a link issue by example, you need do a little bit more research to solve the problem, as the information you provide is not complete.
!fortran code, named as x.f90
subroutine testFDLL(str, n) bind(c, name='testFDLL_as_C')
use ISO_C_BINDING
integer(c_int), value :: n
character(kind=c_char), intent(in) :: str(n)
write(6,*)" Hello FORTRAN : let us do something ...",str
return
end
The following C code is used for demonstration (you have got C++ mostly right already).
//c named as y.c
#include <stdio.h>
#include <string.h>
int main()
{
void testFDLL_as_C(char *str, int n);
char str[] = "Hello from C";
testFDLL_as_C(str, strlen(str));
return 0;
}
If you compile and link use the following
ifort -c x.f90
gcc y.c x.o -W -Wall
Depend on version of ifort and OS, should get error similar as the following
x.o: In function `testFDLL_as_C':
x.f90:(.text+0x42): undefined reference to `for_write_seq_lis'
x.f90:(.text+0x74): undefined reference to `for_write_seq_lis_xmit'
collect2: error: ld returned 1 exit status
You may noticed the undefined reference name pattern is similar with yours, if you link with
gcc y.c x.o -W -Wall -L/path/to/your/ifort_lib -lifcore -ldl
The problem should be solved. Depend on the FORTRAN feature you used, you may need link some more ifort library. This part need you do some research and figure out.
So I just install gcc from homebrew and I have a simple code:
#include <cmath>
#include <iostream>
#include <stdio.h>
int main()
{
const int size = 256;
double sinTable[size];
#pragma omp parallel for
for(int n=0; n<size; ++n)
sinTable[n] = std::sin(2 * M_PI * n / size);
#pragma omp parallel for
for(int n=0; n<10; ++n)
{
printf(" %d", n);
}
printf(".\n");
// the table is now initialized
}
However, when I compiled, I failed:
dhcp-18-189-47-44:openmp_code myname$ gcc-4.8 tmp2.cpp
Undefined symbols for architecture x86_64:
"std::ios_base::Init::Init()", referenced from:
__static_initialization_and_destruction_0(int, int) in ccFbBrPl.o
"std::ios_base::Init::~Init()", referenced from:
__static_initialization_and_destruction_0(int, int) in ccFbBrPl.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
However, if I change it to g++-4.8, then it is successful...
dhcp-18-189-47-44:openmp_code myname$ g++-4.8 tmp2.cpp -fopenmp
I am wondering why this would happen....
You are compiling C++ code with 'gcc' (why?), so you need to link to it the standard c++ library. Add -stdc++ to the build command. When compiling with g++ it knows to link with this library automatically.
EDIT
On the other hand, your code has nothing related to C++ standard libraries. You have #include <iostream> but you use nothing from it. I think (didn't check it though) that if you comment out this include, your original build with 'gcc' should pass.
You're asking why your C++ program fails to compile with a C compiler, but compiles properly with a C++ compiler?
Then this rhetorical question is my answer.
The C compiler doesn't do things like linking in its C++ runtime. You need that runtime. Your linker errors show that the C++ runtime is not being linked. Because you're using a C compiler.
I'm trying to compile this kind of code and I get link errors when trying to build using latest Xcode (6.0) on MacOSX Yosemite:
#include <iostream>
#include <string>
int main()
{
auto x = &std::string::size;
std::string hello("hello");
std::cout << (hello.*x)() << std::endl;
return 0;
}
$ g++ --std=c++11 -stdlib=libc++ hello.cpp -o hello
KO:
Undefined symbols for architecture x86_64:
"std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::size() const", referenced from:
_main in hello-a9a7cd.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Note that the code compiles file using libstdc++:
$ g++ --std=c++11 -stdlib=libstdc++ hello.cpp -o hello
OK
I was having the same problem. See Taking pointer to member std::string::size fails to link with libc++ but works with libstdc++
Basically the solution I came up with is to force the instantiation of the std::string template class.
Here is the proposed solution:
#include <iostream>
#include <string>
template class std::basic_string<char>;
int main()
{
auto x = &std::string::size;
std::string hello("hello");
std::cout << (hello.*x)() << std::endl;
return 0;
}