I'm now studying Fundamentals Of Data Structures in C++ written by Ellis Horowitz, trying to implement the example on the page 77. However, after I build the project, Eclipse Console shows up some warning.
Here's my header file:
#ifndef RECTANGLE_H_
#define RECTANGLE_H_
class Rectangle{
public:
Rectangle();
~Rectangle();
int GetHeight();
int GetWidth();
private:
int xLow, yLow, height, width;
} ;
#endif
And here's my source file:
#include <iostream>
#include "Rectangle.h"
using namespace std;
int main(){
Rectangle r, s;
Rectangle *t = &s;
if(r.GetHeight()*r.GetWidth() > t->GetHeight()*t->GetWidth())
cout << "r";
else
cout << "s";
cout << "has the greater area" << endl;
return 0;
}
And the CDT Build Console shows:
Building target: rectangle
Invoking: MacOS X C++ Linker
g++ -o "rectangle" ./main.o
Undefined symbols:
"Rectangle::Rectangle()", referenced from:
_main in main.o
_main in main.o
"Rectangle::GetWidth()", referenced from:
_main in main.o
_main in main.o
"Rectangle::GetHeight()", referenced from:
_main in main.o
_main in main.o
"Rectangle::~Rectangle()", referenced from:
_main in main.o
_main in main.o
_main in main.o
_main in main.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [rectangle] Error 1
**** Build Finished ****
Besides, will binary files automatically created after building the project?
The implementations to your Rectangle methods are really missing.
That are the methods, you see in the linker error messages:
Rectangle::Rectangle()
Rectangle::GetHeight()
Rectangle::GetWidth()
If you have a Rectangle.cpp (or .cc, .cxx) file, than you need to compile this also and link the Rectangle.o file.
since you asked, here a simplified overview, what different filename ending are for:
Rectangle.h is the header file contains the Interface to your class. Usually it's enough if I read and understand this file, to use the classes that are defined there.
Rectangle.cpp is the implementation or source file and contains the implementation. You can put them also in the header but for larger classes this makes the header file more crowded and some other disadvantages (compile time speed, less encapsulation, ...)
Rectangle.o is the object file. This is what the compiler makes out of the header and source file and is used by the linker.
You haven't defined the Rectangle class functions anywhere. Where is Rectangle.c?
The header file simply declares that the class exists, but you have provided no definitions for that class. You need a Rectangle.c that does that. Also you will have to link with Rectangle.o.
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?
While implementing class member functions in.cpp file on macOS 10.15, displaying an error:
clang: Undefined symbols for architecture x86_64:error:
"Circle::Area()", referenced from:
_main in main-4cfa92.o
"Circle::Circle(double)", referenced from:
_main in main-4cfa92.o
linker command failed with exit code 1 (use -v to see invocation)
To verrify this case, I found an example on the website to try, and it worked fine when I copied the function definitions from Circle.cpp file into Circle.h file, But when the function declaration is in Circle.h and function definition is in Circle.cpp files, respectively, an error occurs
//Circle.h
#ifndef CIRCLE_H
#define CIRCLE_H
class Circle
{
private:
double r;//radius
public:
Circle();//constructor
Circle(double R);//The constructor
double Area();//computing area
};
#endif
//Circle.cpp
#include "Circle.h"
Circle::Circle(){
this->r=5.0;
}
Circle::Circle(double R){
this->r=R;
}
double Circle::Area(){
return 3.14*r*r;
}
//main.cpp
#include <iostream>
#include "Circle.h"
using namespace std;
int main(){
Circle c(3);
cout<<"Area="<<c.Area()<<endl;
return 0;
}
Error message:
Undefined symbols for architecture x86_64:
"Circle::Area()", referenced from:
_main in main-4cfa92.o
"Circle::Circle(double)", referenced from:
_main in main-4cfa92.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Looks like you have not included Circle.cpp in the compilation step. Make sure you include both main.cpp and Circle.cpp
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.
I have looked all over Stack Overflow and other websites about this famous error, and all of them are very specific, and in my case I cannot find a solution. I am making an ncurses application and when i try to compile it, it causes the following error:
Undefined symbols for architecture x86_64:
"NCRS::End()", referenced from:
_main in crspro-85eaaf.o
"NCRS::Start()", referenced from:
_main in crspro-85eaaf.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 compile the code with the following line:
$ clang++ crspro.cpp -lncurses -o crspro
Here is the code:
crspro.cpp
#include "ncrs.h"
int main(int argc, char* argv[]) {
NCRS::Start();
getch();
NCRS::End();
return 0;
}
ncrs.h
#ifndef NCRS_H
#define NCRS_H
#include <ncurses.h>
#include <string>
typedef std::string string;
class NCRS {
private:
static bool __curses_on;
static bool __buffer;
static bool __echo;
static bool __keypad;
public:
static void Start(bool bbuffer=false, bool becho=false, bool bkeypad=false);
static void End();
};
#endif
ncrs.cpp
#include "ncrs.h"
static void NCRS::Start(bool bbuffer=false, bool becho=false, bool bkeypad=false) {
initscr();
if (bbuffer) raw();
if (becho) echo(); else noecho();
if (bkeypad) keypad(stdscr, TRUE); else keypad(stdscr, FALSE);
__buffer = bbuffer;
__echo = becho;
__keypad = bkeypad;
__curses_on = true;
}
static void NCRS::End() { nocbreak(); echo(); keypad(stdscr, FALSE); endwin(); }
I don't have any issues in the code itself as far as I can tell. I have tried even including ncrs.cpp (The horror!!) but I still get the same problems.
Can anyone help with this issue? I've had this problem before with other projects and I've had to abandon them because I couldn't find a solution.
Thanks to anyone who can help!
_
_
EDIT
compile with:
clang++ crspro.cpp ncrs.cpp -lncurses -o crspro
returns error:
Undefined symbols for architecture x86_64:
"NCRS::__curses_on", referenced from:
NCRS::Start(bool, bool, bool) in ncrs-e52041.o
"NCRS::__echo", referenced from:
NCRS::Start(bool, bool, bool) in ncrs-e52041.o
"NCRS::__buffer", referenced from:
NCRS::Start(bool, bool, bool) in ncrs-e52041.o
"NCRS::__keypad", referenced from:
NCRS::Start(bool, bool, bool) in ncrs-e52041.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Your compilation isn't including anything from ncrs.cpp, which is where both NCRS::Start() and NCRS::End() are defined. You probably want
clang++ crspro.cpp ncrs.cpp -lncurses -o crspro
Or if you want to build the object files separately and then link them:
clang++ -c crspro.cpp -c
clang++ -c ncrs.cpp -c
clang++ crspro.o ncrs.o -lncurses -o crspro
Your next error about "NCRS::__curses_on" is because you're using static variables without defining them you need to add
bool NCRS::__curses_on=false;
bool NCRS::__buffer=false;
bool NCRS::__echo=false;
bool NCRS::__keypad=false;
to one of your .cpp files. (presumably ncrs.cpp is the logical place.)
It's probably worth thinking about whether they should be static (and whether the functions should be static too) - they may need to be, but static class variables are essentially global variables, which will often come back to bite you later. They make it harder to understand the flow of the code, and can make multi-threading and testing painful.