Undefined references when trying to link Qt app with my static library

Question

I have a static library that I have built with MinGW, I am trying to link to that library from a Qt application. I keep getting linker errors caused by one of the object files in the library. This file actually declares a couple of Boost headers, one for use of shared_ptr and the other so I can make a class noncopyable. I believe using this boost functionality is what is causing the issue but I have no idea why. If I comment out the classes in the Qt app that use the class defined in the file, the Qt app links fine. This is the error part of the output:

C:\blah\build\windows\mingw\libfoo.a(foo_ctis.cpp.obj):foo_ctis.cpp:(.text+0x10a): undefined reference to `__gxx_personality_sj0'

C:\blah\build\windows\mingw\libfoo.a(foo_ctis.cpp.obj):foo_ctis.cpp:(.text+0x12f): undefined reference to `_Unwind_SjLj_Register'

C:\blah\build\windows\mingw\libfoo.a(foo_ctis.cpp.obj):foo_ctis.cpp:(.text+0x203): undefined reference to `_Unwind_SjLj_Resume'

C:\blah\build\windows\mingw\libfoo.a(foo_ctis.cpp.obj):foo_ctis.cpp:(.text+0x20e): undefined reference to `_Unwind_SjLj_Unregister'

C:\blah\build\windows\mingw\libfoo.a(foo_ctis.cpp.obj):foo_ctis.cpp:(.text+0x226): undefined reference to `__gxx_personality_sj0'

C:\blah\build\windows\mingw\libfoo.a(foo_ctis.cpp.obj):foo_ctis.cpp:(.text+0x24b): undefined reference to `_Unwind_SjLj_Register'

C:\blah\build\windows\mingw\libfoo.a(foo_ctis.cpp.obj):foo_ctis.cpp:(.text+0x31f): undefined reference to `_Unwind_SjLj_Resume'

C:\blah\build\windows\mingw\libfoo.a(foo_ctis.cpp.obj):foo_ctis.cpp:(.text+0x32a): undefined reference to `_Unwind_SjLj_Unregister'

C:\blah\build\windows\mingw\libfoo.a(foo_ctis.cpp.obj):foo_ctis.cpp:(.text$_ZN5boost6detail12shared_countC1IN3foo25foo_SomeClassImplEEEPT_[boost::detail::shared_count::shared_count(foo::foo_SomeClassImpl*)]+0xc): undefined reference to `__gxx_personality_sj0'

C:\blah\build\windows\mingw\libfoo.a(foo_ctis.cpp.obj):foo_ctis.cpp:(.text$_ZN5boost6detail12shared_countC1IN3foo25foo_SomeClassImplEEEPT_[boost::detail::shared_count::shared_count(foo::foo_SomeClassImpl*)]+0x31): undefined reference to `_Unwind_SjLj_Register'

C:\blah\build\windows\mingw\libfoo.a(foo_ctis.cpp.obj):foo_ctis.cpp:(.text$_ZN5boost6detail12shared_countC1IN3foo25foo_SomeClassImplEEEPT_[boost::detail::shared_count::shared_count(foo::foo_SomeClassImpl*)]+0xfb): undefined reference to `_Unwind_SjLj_Resume'

C:\blah\build\windows\mingw\libfoo.a(foo_ctis.cpp.obj):foo_ctis.cpp:(.text$_ZN5boost6detail12shared_countC1IN3foo25foo_SomeClassImplEEEPT_[boost::detail::shared_count::shared_count(foo::foo_SomeClassImpl*)]+0x106): undefined reference to `_Unwind_SjLj_Unregister' collect2: ld returned 1 exit status

One other thing to mention is that I am using a pointer to implementation in this class. Any help would be much appreciated.

Solved: I figured out that I had an older version of GCC in my path that was beng included before my MinGW supplied GCC version. The old version was included in a GNUStep package that I had from awhile back. I think that configuration of these different versions was causing problems. Thanks to kemiisto, who was on the right track in solving the issue.

Gargantua

Answer 1

It seems that your static library was linked against one MinGW distribution (i.e. 3rd version) but you try to link your application with this library using other MinGW distribution (i.e. 4th version which is distributed with binary Qt). You should rebuild your library using the same MinGW which you use for your application development.

Update

May be it's another well known problem. Take a look at this topic. You probably have 2 different folders with Qt libs

C:\Qt\2009.05\bin;C:\Qt\2009.05\qt\bin 

in your path too. Libraries in the first folder (...\bin) compiled with VS2008 and libraries in the second one (...\qt\bin) compiled with MinGW. The items in path variable are looked up when your application starts. Suddenly the folder with "wrong" libraries exists before the folder with correct item in your path variable. What you can do is to copy QtCore4.dll, QtGui4.dll and other libraries that you need to folder with your application executable. Hope this helps.

Some links about this problem:

• @qtforum.org
• @some blog post (in Russian =))

Willis

Hi kemiisto, thanks for your response. I believe I am using the same version of MinGW. I am using CMake to build different types of makefiles. I tried to build makefiles for MinGW and I was getting errors so I included C:\Qt\2009.05\mingw\bin in my command prompt path. After this CMake was able to generate the MinGW makefiles and I was able to use mingw32-make to build the static library. Wouldn't that be using the same version? I don't think I have another version on my computer. – Gargantua

@csmithmaui: in that case I have one more idea. I added some info to my message. – Willis

I analyzed my path and I actually don't have either one of those you posted above in it. I just have C:\Qt\2009.05\mingw\bin. My static library builds fine at the command prompt after including the MinGW path that I just metioned. The problem is when I try to link to my library from QtCreator, I get the linker errors. I read through the links you posted but I don't think this is my problem. Also, if I take out any references to the class contained by the file in question, everything else links fine. I really appreciate your help. – Gargantua

Wanted to let you know that you were on the right track in solving the problems I was having last week. It turned out to e that GNUStep was inluded in my path and the GCC included with it was being used to build my library, which in turn was incompatible with the Qt app which was using the MinGW GCC. Thanks. – Gargantua

Answer 2

Just in case anyone else has this problem: my project rebuild was using .o files from a previous build. I changed compilers in between.

Turns out that when I rebuilt the same project, the new compiler didn't build new .o files, so they were missing some key info. After deleting the old files and rebuilding, the error was fixed.

I assume rebuilding from scratch, without the delete, would work the same.

Baccate

Answer 3

you may have used gcc instead of g++. gcc is a C compiler. but g++ is a c++ compiler.

just make sure to use g++ if you have .cpp files.

Harmonium