I have all the .a files in usr/local/lib. Moreover I've deleted all the .so libraries from the folder to ensure that it compiles statically. I'm using this command to compile it-
g++ HttpAPICall.cpp ... main.cpp -Bstatic -L/usr/local/lib/ -lPocoUtil -lPocoXML -lcrypto -lssl \
-lPocoCrypto -lgumbo -lPocoNet -lPocoJSON -lPocoNetSSL -lPocoFoundation -luuid -std=gnu++11 -o analyzer
I'm getting the following error-
/usr/local/lib//libPocoNetSSL.a(SSLManager.o): In function `Poco::Net::SSLManager::appConfig()':
SSLManager.cpp:(.text+0x383): undefined reference to `Poco::Util::Application::_pInstance'
SSLManager.cpp:(.text+0x3b5): undefined reference to `Poco::Util::Application::_pInstance'
/usr/local/lib//libPocoNetSSL.a(SSLManager.o): In function `Poco::Net::SSLManager::initPassphraseHandler(bool)':
SSLManager.cpp:(.text+0xd58): undefined reference to `Poco::Util::AbstractConfiguration::getString(std::string const&, std::string const&) const'
SSLManager.cpp:(.text+0xdd6): undefined reference to `Poco::Util::UnknownOptionException::UnknownOptionException(std::string const&, int)'
SSLManager.cpp:(.text+0xe01): undefined reference to `Poco::Util::UnknownOptionException::~UnknownOptionException()'
SSLManager.cpp:(.text+0xe06): undefined reference to `typeinfo for Poco::Util::UnknownOptionException'
/usr/local/lib//libPocoNetSSL.a(SSLManager.o): In function `Poco::Net::SSLManager::initCertificateHandler(bool)':
SSLManager.cpp:(.text+0x15a8): undefined reference to `Poco::Util::AbstractConfiguration::getString(std::string const&, std::string const&) const'
I've read that the order or compilation matters in such case. I've tried -WL,--start-group --end-group as well. No luck with that. The same code using mac static libraries is getting compiled easily on xcode. Also, by using the dynamic libraries, the code compiles fine on linux as well. Kindly help me with static compiling on linux.
Related
I download nsis-2.46-src.tar.bz2 from https://sourceforge.net/projects/nsis/files/ and I'm trying to compile makensis but get the errors like:
/usr/bin/ld: i386 architecture of input file `build/release/makensis/winchar.o' is incompatible with i386:x86-64 output
build.cpp:(.text+0x35eb): undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::append(char const*, unsigned int)'
What is wrong? And where I can get Stubs, Plugins, Include components after compilation of makensis? Help me please.
Before compilation I have install mingw-w64, gcc, g++
I encounters some weird situations about ndk's stlport linking.
My snippet codes as follows:
#include <cstdlib>
#include "igslib_imodule_manager.h"
#include "serial_manager_sample.h"
#include "rtc_sample.h"
int main(int argc,char** argv)
{
igslib::IModuleManager* mm = GetModuleManagerInstance();
int rtn = EXIT_SUCCESS;
//igslib::serial_manager_sample::UartSend(mm);
//igslib::serial_manager_sample::UartReceive(mm);
//igslib::rtc_sample::GetTime(mm);
return rtn;
}
That will result in stlport linking errors as follows:
naivechou#~/project/igslib/google_code/build/components_sample/jni>ndk-build
Android NDK: WARNING:/cygdrive/c/project/igslib/google_code/build/components_sample/jni/Android.mk:components_sample: non-system libraries in linker flags: -ligslib_module_manager
Android NDK: This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES
Android NDK: or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the
Android NDK: current module
[armeabi] Compile++ thumb: components_sample <= main.cpp
[armeabi] Executable : components_sample
C:/bin/android-ndk-r10c/toolchains/arm-linux-androideabi-4.6/prebuilt/windows-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld.exe: ../../../out/libigslib_module_manager.a(igslib_module_manager.o): in function std::basic_streambuf<char, std::char_traits<char> >::~basic_streambuf():C:/bin/android-ndk-r10c/sources/cxx-stl/stlport/stlport/stl/_streambuf.c:41: error: undefined reference to 'std::locale::~locale()'
C:/bin/android-ndk-r10c/toolchains/arm-linux-androideabi-4.6/prebuilt/windows-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld.exe: ../../../out/libigslib_module_manager.a(igslib_module_manager.o): in function std::basic_ios<char, std::char_traits<char> >::~basic_ios():C:/bin/android-ndk-r10c/sources/cxx-stl/stlport/stlport/stl/_ios.h:59: error: undefined reference to 'std::ios_base::~ios_base()'
C:/bin/android-ndk-r10c/toolchains/arm-linux-androideabi-4.6/prebuilt/windows-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld.exe: ../../../out/libigslib_module_manager.a(igslib_module_manager.o): in function std::__node_alloc::allocate(unsigned int&):C:/bin/android-ndk-r10c/sources/cxx-stl/stlport/stlport/stl/_alloc.h:158: error: undefined reference to 'std::__node_alloc::_M_allocate(unsigned int&)'
C:/bin/android-ndk-r10c/toolchains/arm-linux-androideabi-4.6/prebuilt/windows-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld.exe: ../../../out/libigslib_module_manager.a(igslib_module_manager.o): in function std::__node_alloc::deallocate(void*, unsigned int):C:/bin/android-ndk-r10c/sources/cxx-stl/stlport/stlport/stl/_alloc.h:161: error: undefined reference to 'std::__node_alloc::_M_deallocate(void*, unsigned int)'
C:/bin/android-ndk-r10c/toolchains/arm-linux-androideabi-4.6/prebuilt/windows-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld.exe: ../../../out/libigslib_module_manager.a(igslib_module_manager.o): in function igslib::CModuleManager::GetInstance():C:/project/igslib/google_code/build/module_manager/jni/../../../src/module_manager/igslib_module_manager.cpp:19: error: undefined reference to '__cxa_end_cleanup'
C:/bin/android-ndk-r10c/toolchains/arm-linux-androideabi-4.6/prebuilt/windows-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld.exe: ../../../out/libigslib_module_manager.a(igslib_module_manager.o):(.ARM.extab.text._ZN6igslib14CModuleManager11GetInstanceEv+0x0): error: undefined reference to '__gxx_personality_v0'
C:/bin/android-ndk-r10c/toolchains/arm-linux-androideabi-4.6/prebuilt/windows-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld.exe: ../../../out/libigslib_module_manager.a(igslib_module_manager.o): in function std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::~basic_stringbuf():C:/bin/android-ndk-r10c/sources/cxx-stl/stlport/stlport/stl/_sstream.c:59: error: undefined reference to '__cxa_end_cleanup'
C:/bin/android-ndk-r10c/toolchains/arm-linux-androideabi-4.6/prebuilt/windows-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld.exe: ../../../out/libigslib_module_manager.a(igslib_module_manager.o):(.ARM.extab.text._ZNSt15basic_stringbufIcSt11char_traitsIcESaIcEED2Ev+0x0): error: undefined reference to '__gxx_personality_v0'
C:/bin/android-ndk-r10c/toolchains/arm-linux-androideabi-4.6/prebuilt/windows-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld.exe: ../../../out/libigslib_module_manager.a(igslib_module_manager.o): in function std::pair<std::string const, igslib::CModuleManager::SModuleInfo>::~pair():C:/bin/android-ndk-r10c/sources/cxx-stl/stlport/stlport/stl/_string_base.h:156: error: undefined reference to '__cxa_end_cleanup'
C:/bin/android-ndk-r10c/toolchains/arm-linux-androideabi-4.6/prebuilt/windows-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld.exe: ../../../out/libigslib_module_manager.a(igslib_module_manager.o):(.ARM.extab.text._ZNSt4pairIKSsN6igslib14CModuleManager11SModuleInfoEED2Ev+0x0): error: undefined reference to '__gxx_personality_v0'
C:/bin/android-ndk-r10c/toolchains/arm-linux-androideabi-4.6/prebuilt/windows-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld.exe: ../../../out/libigslib_module_manager.a(igslib_module_manager.o): in function std::vector<igslib::CModuleManager::SModuleInfo, std::allocator<igslib::CModuleManager::SModuleInfo> >::~vector():C:/bin/android-ndk-r10c/sources/cxx-stl/stlport/stlport/stl/_alloc.h:323: error: undefined reference to '__cxa_end_cleanup'
...(After the text ellipsis)...
But if I uncomment the first line igslib::serial_manager_sample::UartSend(mm);, everything's fine:
naivechou#~/project/igslib/google_code/build/components_sample/jni>ndk-build
Android NDK: WARNING:/cygdrive/c/project/igslib/google_code/build/components_sample/jni/Android.mk:components_sample: non-system libraries in linker flags: -ligslib_module_manager
Android NDK: This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES
Android NDK: or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the
Android NDK: current module
[armeabi] Compile++ thumb: components_sample <= main.cpp
[armeabi] Executable : components_sample
[armeabi] Install : components_sample => libs/armeabi/components_sample
[custom install path]: ../../../out
I just can't figure out what happens? Why I DON'T insert codes will raise errors?
It's difficult to tell without seeing your Application.mk and Android.mk, but it looks like you are using LOCAL_LDLIBS to list the igslib_module_manager library as a dependency to your executable.
This is not a good idea because ndk-build doesn't know about this library's own dependencies when you do this, and the final link command will not be correct (the way Unix linking works is pretty sophisticated, but explains the behaviour you're seeing). That's why ndk-build complains with a WARNING by the way.
You should instead define a module for igslib_module_manager, even if the library is prebuilt, then use LOCAL_STATIC_LIBRARIES += igslib_module_manager to your Android.mk instead.
As a side note, the reason why uncommenting the line 'solves' the issue is because this introduces an additional dependency in the generated object file for 'main.cpp' that ends up pulling just the right amount of STLport into the final link command. But that's really just by chance, you should really list your dependencies properly to ensure everything works properly everytime.
Here's the project I'm developing: https://github.com/bigdatadev/riemannpp
I'm a relative beginner to autotools, and I'm having difficulty getting my shared object riemannpp to link against another library called riemann-client (link in the README.md).
I find the compile / link flags for riemann-client using PKG_CHECK_MODULES in configure.ac (ln. 38). I then use the flags in Makefile.am when I build the .so using LIBADD (ln. 29).
If you try to compile the sources (make), libriemannpp.so will build, but seems that I am doing something very wrong when I try to link the client and unit tests. I add the reference to libriemannpp.so by referencing libriemannpp.la (Makefile.am ln. 41).
The error I'm getting is undefined references to functions from the riemann-client library which riemannpp.so depends. nm shows that riemannpp.so has undefined references, but ldd shows no dependency on riemann-client, which nm shows does exports the missing symbols. I have tried fiddling with the Makefile.am to get the riemannpp library to link properly, but I'm giving in and am hoping an expert will be able to help me out.
If anyone can help me understand what I'm doing wrong and how to fix it I would be very grateful.
I'm using Ubuntu 14.04 with default system packages for gcc, autoconf, automake and libtool.
EDIT: Some more information
ldd output on libriemannpp.so:
linux-vdso.so.1 => (0x00007fff36b29000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f9b13f54000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9b13b8e000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f9b13977000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9b13671000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9b14488000)
nm output on libriemannpp.so:
U _Z17riemann_event_newv
U _Z17riemann_event_setP6_Eventz
U _Z17riemann_query_newPKc
U _Z18riemann_client_newv
U _Z18riemann_event_freeP6_Event
U _Z18riemann_query_freeP6_Query
... etc ...
nm output on libriemann-client.so:
0000000000002c70 T riemann_event_attribute_add
0000000000002cd0 T riemann_event_create
0000000000002610 T riemann_event_free
00000000000025f0 T riemann_event_new
... etc ...
So it seems that the symbols are correctly defined in libriemann-client.so. At least I'm not going completely insane...
The offending build output:
/bin/bash ./libtool --tag=CXX --mode=link g++ -g -O2 -std=c++11 -o src/client/riemannpp src/client/riemannpp.o ./src/riemannpp/libriemannpp.la -L/usr/local/lib -lriemann-client
libtool: link: g++ -g -O2 -std=c++11 -o src/client/.libs/riemannpp src/client/riemannpp.o ./src/riemannpp/.libs/libriemannpp.so -L/usr/local/lib /usr/local/lib/libriemann-client.so
./src/riemannpp/.libs/libriemannpp.so: undefined reference to `riemann_client_send_message(_riemann_client_t*, _Msg*)'
./src/riemannpp/.libs/libriemannpp.so: undefined reference to `riemann_query_set_string(_Query*, char const*)'
./src/riemannpp/.libs/libriemannpp.so: undefined reference to `riemann_client_send_message_oneshot(_riemann_client_t*, _Msg*)'
./src/riemannpp/.libs/libriemannpp.so: undefined reference to `riemann_client_disconnect(_riemann_client_t*)'
./src/riemannpp/.libs/libriemannpp.so: undefined reference to `riemann_attribute_set(_Attribute*, char const*, char const*)'
./src/riemannpp/.libs/libriemannpp.so: undefined reference to `riemann_client_new()'
./src/riemannpp/.libs/libriemannpp.so: undefined reference to `riemann_attribute_free(_Attribute*)'
./src/riemannpp/.libs/libriemannpp.so: undefined reference to `riemann_event_new()'
./src/riemannpp/.libs/libriemannpp.so: undefined reference to `riemann_client_free(_riemann_client_t*)'
./src/riemannpp/.libs/libriemannpp.so: undefined reference to `riemann_query_new(char const*)'
./src/riemannpp/.libs/libriemannpp.so: undefined reference to `riemann_attribute_create(char const*, char const*)'
./src/riemannpp/.libs/libriemannpp.so: undefined reference to `riemann_message_set_query(_Msg*, _Query*)'
./src/riemannpp/.libs/libriemannpp.so: undefined reference to `riemann_event_set(_Event*, ...)'
./src/riemannpp/.libs/libriemannpp.so: undefined reference to `riemann_query_free(_Query*)'
./src/riemannpp/.libs/libriemannpp.so: undefined reference to `riemann_event_attribute_add(_Event*, _Attribute*)'
./src/riemannpp/.libs/libriemannpp.so: undefined reference to `riemann_attribute_set_value(_Attribute*, char const*)'
./src/riemannpp/.libs/libriemannpp.so: undefined reference to `riemann_attribute_new()'
./src/riemannpp/.libs/libriemannpp.so: undefined reference to `riemann_message_new()'
./src/riemannpp/.libs/libriemannpp.so: undefined reference to `riemann_client_connect(_riemann_client_t*, riemann_client_type_t, char const*, int)'
./src/riemannpp/.libs/libriemannpp.so: undefined reference to `riemann_event_tag_add(_Event*, char const*)'
./src/riemannpp/.libs/libriemannpp.so: undefined reference to `riemann_message_free(_Msg*)'
./src/riemannpp/.libs/libriemannpp.so: undefined reference to `riemann_attribute_set_key(_Attribute*, char const*)'
./src/riemannpp/.libs/libriemannpp.so: undefined reference to `riemann_message_set_events_n(_Msg*, unsigned long, _Event**)'
./src/riemannpp/.libs/libriemannpp.so: undefined reference to `riemann_client_create(riemann_client_type_t, char const*, int)'
./src/riemannpp/.libs/libriemannpp.so: undefined reference to `riemann_event_free(_Event*)'
Steps to try it out:
$ git clone git#github.com:algernon/riemann-c-client.git
$ cd riemann-c-client
$ sudo apt-get install protobuf-c-compiler # ubuntu
$ ./configure && make && sudo make install
$ cd ..
$ git clone git#github.com:bigdatadev/riemannpp.git
$ cd riemannpp
$ ./autogen.sh
$ ./configure && make
Note that you will have unresolved symbol references in libriemannpp.so when compiling the client program, despite libriemannpp having references to the riemann-c-client (obtained via pkg-config riemann-client --cflags --libs).
EDIT: I get the same problem even if I run ./configure --disable-shared, which seems to rule out any possibility of a bug in the shared object I'm building. I'm clearly missing how to add the dependency information to the library, but Google isn't giving any answers away.
It seems very unlikely that this is a bug in the riemann-client library, as that builds and passes its unit tests flawlessly.
riemann-client fails to use
#ifdef __cplusplus
extern "C" {
#endif
...
#ifdef __cplusplus
}
#endif
in its header files, therefore your riemanpp code parts think it is calling C++ code when in fact it is C.
And you cannot just use
#ifdef __cplusplus
extern "C" {
#endif
#include <riemann/event.h>
...
as that could possibly subject C++ headers to be wrongly wrapped into C calling conventions. (Meaning the fix must occur in riemann-client)
I am trying to compile a v4l2 example in Ubuntu but I am getting the following error:
guilherme#notedev01:~/Downloads/V4l2_samples-0.4.1$ make
gcc -O2 -L/usr/include -lX11 -lXext -o viewer viewer.c
/tmp/ccUjnjWQ.o: In function `image_destroy':
viewer.c:(.text+0x234): undefined reference to `XDestroyImage'
viewer.c:(.text+0x256): undefined reference to `XFreeGC'
viewer.c:(.text+0x277): undefined reference to `XShmDetach'
viewer.c:(.text+0x2ac): undefined reference to `XFreePixmap'
/tmp/ccUjnjWQ.o: In function `image_create':
viewer.c:(.text+0x305): undefined reference to `XCreateGC'
viewer.c:(.text+0x31d): undefined reference to `XGetWindowAttributes'
viewer.c:(.text+0x39e): undefined reference to `XShmCreateImage'
viewer.c:(.text+0x3f5): undefined reference to `XShmAttach'
viewer.c:(.text+0x44e): undefined reference to `XCreateImage'
viewer.c:(.text+0x494): undefined reference to `XShmQueryExtension'
viewer.c:(.text+0x4b4): undefined reference to `XShmPixmapFormat'
viewer.c:(.text+0x4dc): undefined reference to `XShmCreatePixmap'
/tmp/ccUjnjWQ.o: In function `image_put':
viewer.c:(.text+0x54c): undefined reference to `XPutImage'
viewer.c:(.text+0x586): undefined reference to `XShmPutImage'
/tmp/ccUjnjWQ.o: In function `main':
viewer.c:(.text.startup+0x18b): undefined reference to `XOpenDisplay'
viewer.c:(.text.startup+0x1b1): undefined reference to `XScreenOfDisplay'
viewer.c:(.text.startup+0x1ee): undefined reference to `XCreateSimpleWindow'
viewer.c:(.text.startup+0x249): undefined reference to `XMapRaised'
viewer.c:(.text.startup+0x263): undefined reference to `XStoreName'
viewer.c:(.text.startup+0x280): undefined reference to `XGetWindowAttributes'
viewer.c:(.text.startup+0x92f): undefined reference to `XPending'
viewer.c:(.text.startup+0x94c): undefined reference to `XNextEvent'
viewer.c:(.text.startup+0xaee): undefined reference to `XPending'
viewer.c:(.text.startup+0xb0b): undefined reference to `XNextEvent'
viewer.c:(.text.startup+0xf39): undefined reference to `XPending'
viewer.c:(.text.startup+0xf56): undefined reference to `XNextEvent'
collect2: error: ld returned 1 exit status
make: *** [viewer] Error 1
What I can see is that the path for -lx11 and -lXext isn't -L/usr/include.
How can I find the right path for those libraries?
Thanks.
as Chris has pointed out, the order is wrong, you need to put the -lX11 -lXext after the source-code/object-files.
this is because modern compilers try to optimize the final result and not link against unused libraries.
they do so by maintaining a list of unresolved symbols within an object and use any binary files that come aferwards in the linker arguments to resolve those symbols.
example
your program test uses the function do_foo() from libfoo and the function do_bar_do() from libbar.
you link it using:
$ gcc -o test test.o -lfoo -lbar
the linker first searches test.o and notices that some symbols (do_foo and do_bar_do) are not defined anywhere. it then proceeds to libfoo (specified right after test.o) and finds that it provides do_foo, so it creates code to use it from your program. do_bar_do is still unresolved, until the linker checks upon libbar.
consider doing it the wrong way:
$ gcc -o test -lfoo test.o -lbar
the linker will first check libfoo and see that it doesn't contain any unresolved symbols. cool. it will then proceed to test.o and notice do_bar_do and do_foo. do_bar_do is resolved by the right-hand libbar but do_foo is not resolved at all, and you get an error:
undefined reference to `do_foo'
"but the code is meant to be a tutorial..."
so why is it not working?
older compilers where a bit lax about the order of dependencies (they would check all binaries/libraries/objects whether a given symbol could be resolved); that's why you can still find code out there that puts the libraries to link against before the object files.
The -lX11 -lXext must come after the viewer.c in the command line (and should probably be in the order -lXext -lX11). Also, ensure that the libx11-6-dev and libxext6-dev packages are installed.
System libraries are usually in /lib and /usr/lib, and you do not need to use -L to specify those directories.
I'm beginner in ogre3D and I'm build mi first program in Ogre3D, but when I try to compile the program I get this error:
In function `main':
test.cpp:(.text+0x14): undefined reference to `std::allocator<char>::allocator()'
test.cpp:(.text+0x30): undefined reference to `std::basic_string<char,
std::char_traits<char>, std::allocator<char> >::basic_string(char const*,
std::allocator<char> const&)'
test.cpp:(.text+0x40): undefined reference to `std::allocator<char>::allocator()'
test.cpp:(.text+0x5c): undefined reference to `std::basic_string<char,
std::char_traits<char>, std::allocator<char> >::basic_string(char const*,
std::allocator<char> const&)'
test.cpp:(.text+0x6c): undefined reference to `std::allocator<char>::allocator()'
test.cpp:(.text+0x88): undefined reference to `std::basic_string<char,
std::char_traits<char>, std::allocator<char> >::basic_string(char const*,
std::allocator<char> const&)'
And Continue the fix
I Compile the program manually:
gcc test.cpp -o test.o test
And my file test is this:
#include <Ogre.h>
using namespace Ogre;
int main()
{
Root* root= new Root();
if( !root->restoreConfig() )
{
root->showConfigDialog();
root->saveConfig();
}
return 0;
}
How to fix my problem?
I'm use Debian Wheezy.
The Version Ogre3D: 1.8
Thanks for your answers.
This is a linker error.
Use pkg-config --libs to retrieve the correct linker options
g++ -o test test.cpp -Wall $(pkg-config --cflags OGRE) $(pkg-config --libs OGRE) -lboost_system
If you have installed OGRE in a nonstandard location (say /opt/ogre), you may need to call pkg-config with the PKG_CONFIG_PATH environment variable set:
PKG_CONFIG_PATH=/opt/ogre/lib/pkgconfig pkg-config --libs OGRE
This is a linker error, but not to Ogre3d, but to the STL (Standard Template Library). The reason for this is that you are using gcc, when you should be using g++. However, I am surprised that you aren't getting linker errors to Ogre as well, and the solution to that is like Thomas suggested (though he also uses "g++" in his example).