Results 1 to 3 of 3

Thread: how to identify what parts of library to include?

  1. #1
    Join Date
    Jul 2008

    Unhappy how to identify what parts of library to include?

    I have learned c++ - but never ever tried to use '3rd party libraries' in any code that i have tried to write. I have been limited to using the stl. Of course things are much simpler that way. I am confused about using 'external libraries' in my programs and need to understand more about this. so can you point me to a good basic tutorial on this? Also :

    1. If say i am building a app that requires use of clan lib display functions - the directory in clanlib is called Display... why do i need to compile with '-I /usr/local/include/ClanLib-0.8/ -l clanDisplay..' ? is there documentation about this naming convention?

    2. the second question is a generalisation of the first one. Suppose I need to link to a X11 library. How can I learn to understand what module/source files need to be stated in the compile command? For example, i am trying to compile a program that uses the X11 library. The declaration/header file in this library is keysym.h. I have scanned through this file but it does not give any clue what source file it supports. So how can I possibly know what directory / file must be mentioned on the command line?
    And what would be the naming convention for using it?

  2. #2
    Master Sorcerer
    Join Date
    Sep 2006


    Generally there are many resources out on the Internet and in books that explain about how the compiler and linker works. If you need more information, I suggest you google it or visit a bookstore, but here's a quick rundown:

    When you compile a source file (.cc or .cpp), the compiler generates an object file (.o or .obj). An object fle contains all the functions and static variables in compiled form. See it as a kind of zip file where each function or variable has been compiled and stored individually, where each stored item is called a symbol.

    The next step in producing an executable is to take all these object files and link them together into one big file - this is what the linker does. How exactly it does this varies between platforms and compilers, generally speaking it does this by including all the symbols (functions and static variables) that your application needs to be able to run.

    A simple example of how to produce the obj files (compile) and the final exe (link):

    g++ -c file1.cpp -o file1.o
    g++ -c file2.cpp -o file2.o
    g++ file1.o file2.o -o myprogram
    A static library is basically just a list of object files concatenated together and stored as a single file. I cannot remember the actual command line syntax right now for doing this, but the resulting filename you get under unix is a .a file (for archive).

    Now lets say that we are compiling ClanLib - first it produces all the .o files, then it puts them all in the same file. In principle we could name this file whatever we want, but in ClanLib's case it is named libclanDisplay.a for the clanDisplay library. In Windows, the file is named clanDisplay.lib.

    It also possible to create dynamic libraries. Those have the extension .so on unixes and .dll in Windows. The idea behind dynamic libraries is that the linker do not actually copy the library symbols into the executable, but instead keeps them in the library file. Then when the application starts, the application loads the dynamic library into memory and 'links' it at run time. Because linking can be a complicated process, this works differently depending on what OS and compiler you are using. I'm not going to get into what those differences are and so on, because you can write books about this stuff!

    Anyway to link with a library, static or dynamic, the syntax for g++ is -l<library>. The convention in unix is to name your library libXX.a/, and because unix folks are generally very lazy when they type, the -l command adds a 'lib' prefix to the name you type. So if you type -lclanDisplay, the linker goes looking for

    OK, now to answer your two questions:

    The naming convention of libraries and where the header files are placed is up to every single 3rd party library out there. It also depends on the distribution you use. Generally library headers installed by package systems are placed in /usr/include and the library files in /usr/lib. Likewise, generally, libraries tend to install them in /usr/local/include and /usr/local/lib if you compile and install them using their makefiles. However, how they name themselves and if the include files get a subdirectory (like ClanLib) or not highly depends on the individual library.

    There have been various attempts to help the developer with this mess - one of them is called pkgconfig and is the system used by ClanLib. The idea behind that system is that you run pkgconfig and it returns the parameters you need to pass on to the compiler. You do not have to use pkgconfig if you don't feel like it though - it is perfectly okay to simply specify the needed -L -l and -I parameters manually.

    In an ideal world you could read where clanlib installs things in the documentation, but this isn't an ideal world so you can't. Mostly you are left with the problem of figuring out where things are located yourself.

    Regarding your second question, X11 is actually a good example of the chaos. Depending on your OS and distribution, those files can be placed in all kinds of odd places - sometimes they are in /usr/include and /usr/lib, sometimes they are in /usr/X11R6/include or whatever other weird positions someone felt was logical to them.

  3. #3
    Join Date
    Jul 2008


    Ok thanks ..this suggests that it is not really practical for me to try to compile from the command line manually using g++. I thought all libraries followed strict rules about file locations etc. I just wanted to try to get a basic understanding of what was going on. thats why i wanted to start off without using any script / makefile automation.

    ive failed to make even the example program work due to linking problems so i have now started to use kdevelop. This itself has introduced its own problem which i dont no how to solve as i have never used this type of ide while learning basic c++.

    but thanks for this explanation which has helped some.

    If you or anyone else reading can help with this kdevelop problem i will be grateful: the generates the '-l clanCore etc ...' so the ide can see clanlib. the problem seems to be with permissions & running auto-make??
    (kdevelop messages window when building program)
    ----------------------------------- Output-------------------------------------------
    cd '/usr/home/neil/code/hh' && WANT_AUTOCONF_2_5="1" WANT_AUTOMAKE_1_6="1" ./ && mkdir '/usr/home/neil/code/hh/debug' && cd '/usr/home/neil/code/hh/debug' && CXXFLAGS="-O0 -g3" "/usr/home/neil/code/hh/configure" --enable-debug=full && cd '/usr/home/neil/code/hh/debug/src' && WANT_AUTOCONF_2_5="1" WANT_AUTOMAKE_1_6="1" gmake -k main.lo
    ./ Permission denied
    *** Exited with status: 126 ***
    ----------------------------------- end of output-----------------------------------

    i dont understand this as i am writing the project in my home directory that i have permissions to. infact i can just as easily run kdevelop as root if this is what i am supposed to do.

    thnaks for reading this.

Similar Threads

  1. How do i set up the system to simply use <include.h>?
    By NVanGogh in forum Official ClanLib SDK Forums
    Replies: 4
    Last Post: 09-01-2008, 07:03 AM
  2. x11 Library location?
    By Oblivious in forum Official ClanLib SDK Forums
    Replies: 8
    Last Post: 12-28-2007, 04:37 PM
  3. Documentation bug: please include OSX equivalents to hotkeys
    By whisperstorm in forum Novashell Game Creation System
    Replies: 2
    Last Post: 01-13-2007, 03:55 AM
  4. Error while Building clanDisplay Library
    By thfai2000 in forum Official ClanLib SDK Forums
    Replies: 1
    Last Post: 12-21-2006, 07:21 PM



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts