Thread: undefined Reference when linking a library

  1. #1
    UK2
    Join Date
    Sep 2003
    Posts
    112

    undefined Reference when linking a library

    Hello,

    I have linked a library, However, I get the following message. And can't seem to find out what the problem is. I have changed the arguments to 0 to see if that would make a difference. However, I am still getting the problem.

    I also deleted the code inside CreateSocket to make it easy to finding what the problem is.

    Many thanks for any advice on this problem,

    Steve

    steve@steve01:~/Projects/ClientApp/src$ g++ -o ../bin/client ClientApp.cpp -I ../include -L ../lib -lSocketFunctions
    /tmp/cciZxGP6.o: In function `main':
    ClientApp.cpp.text+0xc3): undefined reference to `CreateSocket()'
    collect2: ld returned 1 exit status

    My header file:
    Code:
    //SocketApp.h
    int CreateSocket();
    int SendData(int sockfd, char* buffer, int bytes);
    char* SendAndReceiveData(int sockfd, char *buffer);
    My library:
    Code:
    #include <sys/types.h>
    #include <sys/socket.h>
    #include <arpa/inet.h>
    #include <string.h>
    #include "SocketApp.h"
    
    /* Creates a new socket and return the sock file descriptor.*/
    int CreateSocket()
    {
    		return 1;
    }
    The program that uses the library.
    Code:
    #include <iostream>
    #include "SocketApp.h"
    
    using namespace std;
    
    int main(int argc, char** argv)
    {
    	cout << "******* This is the client application	********" << endl;
    	cout << endl;
    
    	int sockfd = 0;
    
    	//Create a new socket
    	sockfd = CreateSocket();
    	
    	cout << "sockfd: " << sockfd << endl;
    
    	return 0;
    }

  2. #2
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    IF the function is external, ie within another library, then you need to link against the appropriate .lib file.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #3
    UK2
    Join Date
    Sep 2003
    Posts
    112
    Hello,

    Thanks for the reply. The functions is not external it is in the lib directory.

    My directory structure is:
    bin\client
    include\SocketApp.h
    lib\libSocketFunctions.a
    src\ClientApp.cpp

    I have recompiled the library and again placed it in the lib directory. However, I am still getting the same problem.

    Many thanks for anymore suggestions,

    Steve

  4. #4
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,057
    An "external function" is one that isn't in the current file of your source code. When you use external functions (as you are doing), you need to tell the compiler which library contains the functions you are calling.

    Nevertheless, that is what you appear to be doing.
    Code:
    steve@steve01:~/Projects/ClientApp/src$ g++ -o ../bin/client ClientApp.cpp -I ../include \
    -L ../lib -lSocketFunctions
    The only thing I can think of is that your library is compiled as C with gcc, while your ClientApp.cpp is compiled as C++ with g++. If this is the case, either compile both as C++ with g++ or try something like this:
    Code:
    #include <iostream>
    extern "C" {
    #include "SocketApp.h"
    }
    
    using namespace std;
    
    int main(int argc, char** argv)
    {
    	cout << "******* This is the client application	********" << endl;
    	cout << endl;
    
    	int sockfd = 0;
    
    	//Create a new socket
    	sockfd = CreateSocket();
    	
    	cout << "sockfd: " << sockfd << endl;
    
    	return 0;
    }
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  5. #5
    UK2
    Join Date
    Sep 2003
    Posts
    112
    Hello dwk,

    Thanks for the advice. I will try that. I am not at my computer at the moment so cannot give you the results.

    Just a question about the compiling with C and C++.

    The library I have created with C and is called libSocketFunctions.a. If I had this library compiled using C++ then it will still be called libSocketFunctions.a.

    How can you tell the difference if a library has been created by either C or C++.?

    If I was to use someone else's library, how would I know what they used?

    Many thanks for your advice,

    Steve

  6. #6
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,057
    Well, one way to do it would be to look at the symbol names. C symbol names are very simple. If you create a function called func, the symbol will be called "func", or perhaps "_func" on some systems.

    C++ functions, on the other hand, are a little different. C++ supports polymorphism. This means that you can have code like this:
    Code:
    void func(char c) {}
    void func(char *s) {}
    void func(int x) {}
    In other words, you can have functions with the same name but different arguments. (Differentiating by only return value is not allowed.)

    Clearly, these functions cannot all be referenced by the symbol "func". There would be conflicts. When I say "func", which one do I mean? So C++ compilers have to "mangle" the names. They encode information about the parameters of the function into the name. Sort of like going "func_char", "func_char_star", and "func_int". But it's not that simple. You'll be more likely to end up with names like "func@94Hdm4359fF". That's completely fictional, of course, but they look sort of like that.

    And to make matters worse, different C++ compilers mangle names differently. So a library compiled with one compiler may not work with another. Unlike C libraries, which can be ported across compilers and systems, usually, if the target systems are reasonably similar. (For example, a Windows library wouldn't work under Linux. But a Linux C library might work under different UNIXes.)

    Anyway -- so you can look at the symbol names of the library. If they look strange, it was probably C++. (Or maybe some other language -- I'm not sure how they do it.) If they're readable, it was probably C.

    You can use the command "nm" (part of binutils -- if you have GCC you'll have this) to check symbols. Try it and see what you get . . .
    Code:
    $ nm executable
    That's just the first method that came to mind.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  7. #7
    UK2
    Join Date
    Sep 2003
    Posts
    112
    Hello dwk,

    Thanks very much for the reply. I coded with the extern "C". Not sure what this means, but I guess so that the application that uses the library expects a C program?

    However, I did 2 tests.
    Test 1: I compiled the library using g++ and linked the ClientApp. Everything worked ok.

    Test 2: I compiled the library using gcc and linked the ClientApp, and inserted the code below in the ClientApp.cpp:
    extern "C" {
    #include "SocketApp.h"
    }

    Both tests were successfull. So have found 2 ways to complete this application. I think I will be using test 2 in the future.

    Many thanks for your help,

    Steve

  8. #8
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,057
    Thanks very much for the reply. I coded with the extern "C". Not sure what this means, but I guess so that the application that uses the library expects a C program?
    Yes, basically. Since C functions are different from C++ functions, the linker has to be told, in C++ mode, when it's dealing with a C function.

    (C++ functions can have the same name but different arguments -- polymorphism. As such, this information has to be encoded in the function's symbolic name. Search for "c linkage" for more information.)
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Getting undefined reference error from ZThread
    By 6tr6tr in forum C++ Programming
    Replies: 3
    Last Post: 04-21-2008, 05:50 PM
  2. Problem with Makefile
    By pinkprincess in forum C Programming
    Replies: 3
    Last Post: 06-24-2007, 09:02 AM
  3. MinGW Linking GUI Program
    By Tonto in forum Tech Board
    Replies: 19
    Last Post: 08-23-2006, 03:28 PM
  4. Textbox
    By maxorator in forum Windows Programming
    Replies: 20
    Last Post: 09-25-2005, 10:04 AM
  5. How to: Use OpenGL with Jgrasp
    By Pickels in forum Game Programming
    Replies: 3
    Last Post: 08-30-2005, 10:37 AM