Re: [CMake] Linking problem
On 07/27/2011 01:14 PM, Sanatan Rai wrote:
Hi,
This is a newbie question. So apologies in advance if this is covered
somewhere in the docs (I haven't been able to find a satisfactory
explanation).
The issue is this:
* I have a library called (lib)atmath as per:
include_directories(${at_SOURCE_DIR})
add_library(atfwmath RngStream.cpp RngStream.h coin.cpp coin.hpp)
target_link_libraries(atfwmath)
Where coin.hpp:
#ifndef COIN_HPP_INCLUDED
#define COIN_HPP_INCLUDED
#include sstream
#include fw/math/RngStream.h
using namespace std;
class coin
{
private:
static string name()
{
static unsigned long id(0);
stringstream str;
str Coin_ (++id) _stream;
return str.str();
}
double p;
RngStream *rng;
void init();
public:
coin();
coin(double _p);
~coin();
bool toss();
void reset(double _p);
};
#endif
and coin.cpp:
#include fw/math/coin.hpp
coin::coin() : p(0.5), rng(0) { init();}
coin::coin(double _p) : p(_p), rng(0)
{
if ((p 0) || (p 1))
throw;
init();
}
coin::~coin()
{
delete rng, rng = 0;
}
void coin::init()
{
rng = new RngStream(name().c_str());
}
bool coin::toss()
{
double u(rng-RandU01());
return (u = p);
}
void coin::reset(double _p)
{
if ((_p 0) || (_p 1)) throw;
p = _p;
}
I use these classes in another library:
add_library(atidt STATIC idt.cpp)
target_link_libraries(atidt atmath boost_date_time boost_signals)
which is then linked to the final executable:
add_executable(bt bt.cpp)
target_link_libraries(bt atidt atmath boost_date_time boost_program_options)
target_link_libraries(bt -Wl,-whole-archive -L../idt/ -latidt
-Wl,-no-whole-archive)
When I run make:
* libatmath compiles fine.
* libatidt complies fine.
* when compiling bt, it complains about coin::coin, coin::reset etc
being undefined.
Ie it would see it is not finding them in the linked libraries.
Even though:
$ ar t libatmath.a
RngStream.cpp.o
coin.cpp.o
What am I missing here? It is also quite bizarre as it doesn't
complain about the declarations in
RngStream.h which are defined in RngStream.c.
Thanks in advance!
--Sanatan
AFAICS, the problem arises from bt's TARGET_LINK_LIBRARIES() commands:
target_link_libraries(bt atidt atmath ...)
target_link_libraries(bt -Wl,-whole-archive -L../idt/ -latidt
-Wl,-no-whole-archive)
In this way, -latidt appears at last in the linker command line without
a chance for CMake to mention atmath afterwards, but the former depends
on the latter as can be concluded from atidt's TARGET_LINK_LIBRARIES()
command. Finally, the whole-archive switch forces the linker to include
every object file - regardless if it is referred to or not - so atidt's
references to atmath can not be resolved. What do you intend with this
second TARGET_LINK_LIBRARIES() command? To me, it does not make much
sense at the first glance. Moreover:
(1) Since you force all object files from atidt to be included in the
final executable, you might also get errors from multiple definitions
as the executable is linked against atidt once before.
(2) Don't use using namespace std; at the global scope in a header.
'hope that helps.
Regards,
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Linking problem
Hi,
This is a newbie question. So apologies in advance if this is covered
somewhere in the docs (I haven't been able to find a satisfactory explanation).
The issue is this:
* I have a library called (lib)atmath as per:
include_directories(${at_SOURCE_DIR})
add_library(atfwmath RngStream.cpp RngStream.h coin.cpp coin.hpp)
target_link_libraries(atfwmath)
Where coin.hpp:
#ifndef COIN_HPP_INCLUDED
#define COIN_HPP_INCLUDED
#include sstream
#include fw/math/RngStream.h
using namespace std;
class coin
{
private:
static string name()
{
static unsigned long id(0);
stringstream str;
str Coin_ (++id) _stream;
return str.str();
}
double p;
RngStream *rng;
void init();
public:
coin();
coin(double _p);
~coin();
bool toss();
void reset(double _p);
};
#endif
and coin.cpp:
#include fw/math/coin.hpp
coin::coin() : p(0.5), rng(0) { init();}
coin::coin(double _p) : p(_p), rng(0)
{
if ((p 0) || (p 1))
throw;
init();
}
coin::~coin()
{
delete rng, rng = 0;
}
void coin::init()
{
rng = new RngStream(name().c_str());
}
bool coin::toss()
{
double u(rng-RandU01());
return (u = p);
}
void coin::reset(double _p)
{
if ((_p 0) || (_p 1)) throw;
p = _p;
}
I use these classes in another library:
add_library(atidt STATIC idt.cpp)
target_link_libraries(atidt atmath boost_date_time boost_signals)
which is then linked to the final executable:
add_executable(bt bt.cpp)
target_link_libraries(bt atidt atmath boost_date_time boost_program_options)
target_link_libraries(bt -Wl,-whole-archive -L../idt/ -latidt
-Wl,-no-whole-archive)
When I run make:
* libatmath compiles fine.
* libatidt complies fine.
* when compiling bt, it complains about coin::coin, coin::reset etc
being undefined.
Ie it would see it is not finding them in the linked libraries.
Even though:
$ ar t libatmath.a
RngStream.cpp.o
coin.cpp.o
What am I missing here? It is also quite bizarre as it doesn't
complain about the declarations in
RngStream.h which are defined in RngStream.c.
Thanks in advance!
--Sanatan
--
Sanatan Rai
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On Wed, 2011-07-27 at 12:14 +0100, Sanatan Rai wrote:
Hi,
This is a newbie question. So apologies in advance if this is
covered
somewhere in the docs (I haven't been able to find a satisfactory
explanation).
The issue is this:
* I have a library called (lib)atmath as per:
include_directories(${at_SOURCE_DIR})
add_library(atfwmath RngStream.cpp RngStream.h coin.cpp coin.hpp)
target_link_libraries(atfwmath)
Where coin.hpp:
#ifndef COIN_HPP_INCLUDED
#define COIN_HPP_INCLUDED
#include sstream
#include fw/math/RngStream.h
using namespace std;
class coin
{
private:
static string name()
{
static unsigned long id(0);
stringstream str;
str Coin_ (++id) _stream;
return str.str();
}
double p;
RngStream *rng;
void init();
public:
coin();
coin(double _p);
~coin();
bool toss();
void reset(double _p);
};
#endif
and coin.cpp:
#include fw/math/coin.hpp
coin::coin() : p(0.5), rng(0) { init();}
coin::coin(double _p) : p(_p), rng(0)
{
if ((p 0) || (p 1))
throw;
init();
}
coin::~coin()
{
delete rng, rng = 0;
}
void coin::init()
{
rng = new RngStream(name().c_str());
}
bool coin::toss()
{
double u(rng-RandU01());
return (u = p);
}
void coin::reset(double _p)
{
if ((_p 0) || (_p 1)) throw;
p = _p;
}
I use these classes in another library:
add_library(atidt STATIC idt.cpp)
target_link_libraries(atidt atmath boost_date_time boost_signals)
which is then linked to the final executable:
add_executable(bt bt.cpp)
target_link_libraries(bt atidt atmath boost_date_time
boost_program_options)
target_link_libraries(bt -Wl,-whole-archive -L../idt/ -latidt
-Wl,-no-whole-archive)
When I run make:
* libatmath compiles fine.
* libatidt complies fine.
* when compiling bt, it complains about coin::coin, coin::reset etc
being undefined.
Ie it would see it is not finding them in the linked libraries.
Even though:
$ ar t libatmath.a
RngStream.cpp.o
coin.cpp.o
What am I missing here? It is also quite bizarre as it doesn't
complain about the declarations in
RngStream.h which are defined in RngStream.c.
Thanks in advance!
--Sanatan
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
Hi Sanatan, If you didn't make any copy/paste errors, then I think you made a typo. add_library(atfwmath RngStream.cpp RngStream.h coin.cpp coin.hpp) : : target_link_libraries(bt atidt atmath boost_date_time boost_program_options) See: atfwmath versus atmath. You should fix your add_library() line. Best regards, Marcel Loose. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
include_directories(${at_SOURCE_DIR})
add_library(atfwmath RngStream.cpp RngStream.h coin.cpp coin.hpp)
target_link_libraries(atfwmath)
You are telling CMake here that atfwmath should be linked against
something. But you don't tell it against what.
Eike
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 27 July 2011 12:33, Marcel Loose lo...@astron.nl wrote: Hi Sanatan, If you didn't make any copy/paste errors, then I think you made a typo. add_library(atfwmath RngStream.cpp RngStream.h coin.cpp coin.hpp) : : target_link_libraries(bt atidt atmath boost_date_time boost_program_options) See: atfwmath versus atmath. You should fix your add_library() line. Sorry, I typed the example in, so that's just a typo. There's no typo in the original CMakeLists.txt files. -- Sanatan Rai ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 27 July 2011 12:37, Rolf Eike Beer e...@sf-mail.de wrote:
include_directories(${at_SOURCE_DIR})
add_library(atfwmath RngStream.cpp RngStream.h coin.cpp coin.hpp)
target_link_libraries(atfwmath)
You are telling CMake here that atfwmath should be linked against
something. But you don't tell it against what.
There are no other dependencies. Originally, this line was not there.
I added it to see if it would fix the problem.
--
Sanatan Rai
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
Hi,
is that a valid CMake instruction ?
target_link_libraries(bt -Wl,-whole-archive -L../idt/ -latidt
-Wl,-no-whole-archive)
I thought you were supposed to use
set_target_properties(bt PROPERTIES LINK_FLAGS -Wl,-whole-archive -L../idt/
-latidt -Wl,-no-whole-archive)
Maxime
2011/7/27 Sanatan Rai sana...@gmail.com
On 27 July 2011 12:37, Rolf Eike Beer e...@sf-mail.de wrote:
include_directories(${at_SOURCE_DIR})
add_library(atfwmath RngStream.cpp RngStream.h coin.cpp coin.hpp)
target_link_libraries(atfwmath)
You are telling CMake here that atfwmath should be linked against
something. But you don't tell it against what.
There are no other dependencies. Originally, this line was not there.
I added it to see if it would fix the problem.
--
Sanatan Rai
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 27 July 2011 13:20, Maxime Lecourt maxime.leco...@gmail.com wrote: Hi, is that a valid CMake instruction ? target_link_libraries(bt -Wl,-whole-archive -L../idt/ -latidt -Wl,-no-whole-archive) Yes, it certainly works. I thought you were supposed to use set_target_properties(bt PROPERTIES LINK_FLAGS -Wl,-whole-archive -L../idt/ -latidt -Wl,-no-whole-archive) Thanks for the pointer. -- Sanatan Rai ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On Nov 7, 2007 2:12 AM, Salvatore Iovene [EMAIL PROTECTED] wrote: Hi, I'm not 100% sure this is really a CMake related question, but I'll fire it up anyway: I'm building a series of static libraries, name them liba.a, libb.a and libc.a, and linking them into a shared library libfoo.so. Then I'm building libx.a liby.a and libz.a and linking them into the shared libbar.so. Then I have an executable whatever.exe that's linked to to libfoo.so and libbar.so. The linking of the executable fails complaining of certain missing simbols. Some symbols from liba.a are missing in libbar.so. I'm not a linking expert, but why should static symbols that you embedded in libfoo.so be visible to libbar.so? So far I have fixed the issue by linking one of the libs of libfoo.so (say libx.a) to libbar.so. But this smells of nasy workaround. Why should it be? You're saying you really don't want those underlying static libs to know about each other. If you want symbols from a to be visible to everyone, you should be making it a dynamic liba.so. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 11/7/07, Brandon Van Every [EMAIL PROTECTED] wrote: On Nov 7, 2007 2:12 AM, Salvatore Iovene [EMAIL PROTECTED] wrote: Hi, I'm not 100% sure this is really a CMake related question, but I'll fire it up anyway: I'm building a series of static libraries, name them liba.a, libb.a and libc.a, and linking them into a shared library libfoo.so. Then I'm building libx.a liby.a and libz.a and linking them into the shared libbar.so. Then I have an executable whatever.exe that's linked to to libfoo.so and libbar.so. The linking of the executable fails complaining of certain missing simbols. Some symbols from liba.a are missing in libbar.so. I'm not a linking expert, but why should static symbols that you embedded in libfoo.so be visible to libbar.so? Because libbar uses libfoo. So far I have fixed the issue by linking one of the libs of libfoo.so (say libx.a) to libbar.so. But this smells of nasy workaround. Why should it be? You're saying you really don't want those underlying static libs to know about each other. If you want symbols from a to be visible to everyone, you should be making it a dynamic liba.so. My assumption here is that linking all the static libs liba.a, libb.a and libc.a in libfoo.so, the symbols in liba, libb and libc will be visible from libraries that link against libfoo. Maybe this is the problem? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 07 Nov 2007, at 09:59, Salvatore Iovene wrote: On 11/7/07, Brandon Van Every [EMAIL PROTECTED] wrote: On Nov 7, 2007 2:12 AM, Salvatore Iovene [EMAIL PROTECTED] wrote: Hi, I'm not 100% sure this is really a CMake related question, but I'll fire it up anyway: I'm building a series of static libraries, name them liba.a, libb.a and libc.a, and linking them into a shared library libfoo.so. Then I'm building libx.a liby.a and libz.a and linking them into the shared libbar.so. Then I have an executable whatever.exe that's linked to to libfoo.so and libbar.so. The linking of the executable fails complaining of certain missing simbols. Some symbols from liba.a are missing in libbar.so. Let's say that there's a symbol S in liba.a, that S is the only symbol in its object, and that S is not used by libfoo. In Darwin, S will not be included in libfoo, and the result you get is expectable. I don't know if this simple explanation translates to Linux. Renaud. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 11/7/07, Renaud Detry [EMAIL PROTECTED] wrote: On 07 Nov 2007, at 09:59, Salvatore Iovene wrote: On 11/7/07, Brandon Van Every [EMAIL PROTECTED] wrote: On Nov 7, 2007 2:12 AM, Salvatore Iovene [EMAIL PROTECTED] wrote: Hi, I'm not 100% sure this is really a CMake related question, but I'll fire it up anyway: I'm building a series of static libraries, name them liba.a, libb.a and libc.a, and linking them into a shared library libfoo.so. Then I'm building libx.a liby.a and libz.a and linking them into the shared libbar.so. Then I have an executable whatever.exe that's linked to to libfoo.so and libbar.so. The linking of the executable fails complaining of certain missing simbols. Some symbols from liba.a are missing in libbar.so. Let's say that there's a symbol S in liba.a, that S is the only symbol in its object, and that S is not used by libfoo. In Darwin, S will not be included in libfoo, and the result you get is expectable. I don't know if this simple explanation translates to Linux. I don't know either, but that seems to be the case. Any ideas on how to fix it? -- Salvatore Iovene http://www.iovene.com/ Key Fingerprint: 5647 944D D5AD 2E87 00B4 7D54 2864 359D FF20 16D8 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 11/7/07, Renaud Detry [EMAIL PROTECTED] wrote: On 07 Nov 2007, at 11:04, Salvatore Iovene wrote: On 11/7/07, Renaud Detry [EMAIL PROTECTED] wrote: On 07 Nov 2007, at 09:59, Salvatore Iovene wrote: On 11/7/07, Brandon Van Every [EMAIL PROTECTED] wrote: On Nov 7, 2007 2:12 AM, Salvatore Iovene [EMAIL PROTECTED] wrote: Hi, I'm not 100% sure this is really a CMake related question, but I'll fire it up anyway: I'm building a series of static libraries, name them liba.a, libb.a and libc.a, and linking them into a shared library libfoo.so. Then I'm building libx.a liby.a and libz.a and linking them into the shared libbar.so. Then I have an executable whatever.exe that's linked to to libfoo.so and libbar.so. The linking of the executable fails complaining of certain missing simbols. Some symbols from liba.a are missing in libbar.so. Let's say that there's a symbol S in liba.a, that S is the only symbol in its object, and that S is not used by libfoo. In Darwin, S will not be included in libfoo, and the result you get is expectable. I don't know if this simple explanation translates to Linux. I don't know either, but that seems to be the case. Any ideas on how to fix it? IMHO, you shouldn't use symbols from liba in libbar if libbar doesn't link against liba. I think you could do either of 1.- make all your static libs dynamic, and link libbar against liba if libbar uses symbols from liba. 2.- link neither libfoo nor libbar to liba, but link whatever.exe to liba. This will require an extra flag about undefined symbols under Darwin, but I don't think ld will complain under Linux. Option (1) seems far nicer to me. Hope this helps. Renaud. Thanks. Your options seem very reasonable. The thing is, though, that the various liba, libb, libc were meant to be only used to build a bigger library called libfoo. So what I really want is that symbols in liba are defined in libfoo even if libfoo doesn't use them. Does it make sense? -- Salvatore Iovene http://www.iovene.com/ Key Fingerprint: 5647 944D D5AD 2E87 00B4 7D54 2864 359D FF20 16D8 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 07 Nov 2007, at 11:35, Salvatore Iovene wrote: On 11/7/07, Renaud Detry [EMAIL PROTECTED] wrote: On 07 Nov 2007, at 11:04, Salvatore Iovene wrote: On 11/7/07, Renaud Detry [EMAIL PROTECTED] wrote: On 07 Nov 2007, at 09:59, Salvatore Iovene wrote: On 11/7/07, Brandon Van Every [EMAIL PROTECTED] wrote: On Nov 7, 2007 2:12 AM, Salvatore Iovene [EMAIL PROTECTED] wrote: Hi, I'm not 100% sure this is really a CMake related question, but I'll fire it up anyway: I'm building a series of static libraries, name them liba.a, libb.a and libc.a, and linking them into a shared library libfoo.so. Then I'm building libx.a liby.a and libz.a and linking them into the shared libbar.so. Then I have an executable whatever.exe that's linked to to libfoo.so and libbar.so. The linking of the executable fails complaining of certain missing simbols. Some symbols from liba.a are missing in libbar.so. Let's say that there's a symbol S in liba.a, that S is the only symbol in its object, and that S is not used by libfoo. In Darwin, S will not be included in libfoo, and the result you get is expectable. I don't know if this simple explanation translates to Linux. I don't know either, but that seems to be the case. Any ideas on how to fix it? IMHO, you shouldn't use symbols from liba in libbar if libbar doesn't link against liba. I think you could do either of 1.- make all your static libs dynamic, and link libbar against liba if libbar uses symbols from liba. 2.- link neither libfoo nor libbar to liba, but link whatever.exe to liba. This will require an extra flag about undefined symbols under Darwin, but I don't think ld will complain under Linux. Option (1) seems far nicer to me. Hope this helps. Renaud. Thanks. Your options seem very reasonable. The thing is, though, that the various liba, libb, libc were meant to be only used to build a bigger library called libfoo. Then why don't you build all objects from foo, a, b, c to be PIC and pack them all together in foo? Or if you really want intermediate archives, maybe you can build the objects of a, b, c to be PIC, archive them in .a archives, and use ld to put them together. But this is not the same thing as linking foo to a, b, c using gcc and -la -lb -lc, which means to only fetch needed symbols. The bottom line is, what you mean to do is probably not very common, and I don't think there will be a high-level CMake primitive that will do that for you. This is just my opinion though :-) Renaud. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 07 Nov 2007, at 11:04, Salvatore Iovene wrote: On 11/7/07, Renaud Detry [EMAIL PROTECTED] wrote: On 07 Nov 2007, at 09:59, Salvatore Iovene wrote: On 11/7/07, Brandon Van Every [EMAIL PROTECTED] wrote: On Nov 7, 2007 2:12 AM, Salvatore Iovene [EMAIL PROTECTED] wrote: Hi, I'm not 100% sure this is really a CMake related question, but I'll fire it up anyway: I'm building a series of static libraries, name them liba.a, libb.a and libc.a, and linking them into a shared library libfoo.so. Then I'm building libx.a liby.a and libz.a and linking them into the shared libbar.so. Then I have an executable whatever.exe that's linked to to libfoo.so and libbar.so. The linking of the executable fails complaining of certain missing simbols. Some symbols from liba.a are missing in libbar.so. Let's say that there's a symbol S in liba.a, that S is the only symbol in its object, and that S is not used by libfoo. In Darwin, S will not be included in libfoo, and the result you get is expectable. I don't know if this simple explanation translates to Linux. I don't know either, but that seems to be the case. Any ideas on how to fix it? IMHO, you shouldn't use symbols from liba in libbar if libbar doesn't link against liba. I think you could do either of 1.- make all your static libs dynamic, and link libbar against liba if libbar uses symbols from liba. 2.- link neither libfoo nor libbar to liba, but link whatever.exe to liba. This will require an extra flag about undefined symbols under Darwin, but I don't think ld will complain under Linux. Option (1) seems far nicer to me. Hope this helps. Renaud. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 11/7/07, Renaud Detry [EMAIL PROTECTED] wrote: On 07 Nov 2007, at 11:35, Salvatore Iovene wrote: On 11/7/07, Renaud Detry [EMAIL PROTECTED] wrote: On 07 Nov 2007, at 11:04, Salvatore Iovene wrote: On 11/7/07, Renaud Detry [EMAIL PROTECTED] wrote: On 07 Nov 2007, at 09:59, Salvatore Iovene wrote: On 11/7/07, Brandon Van Every [EMAIL PROTECTED] wrote: On Nov 7, 2007 2:12 AM, Salvatore Iovene [EMAIL PROTECTED] wrote: Hi, I'm not 100% sure this is really a CMake related question, but I'll fire it up anyway: I'm building a series of static libraries, name them liba.a, libb.a and libc.a, and linking them into a shared library libfoo.so. Then I'm building libx.a liby.a and libz.a and linking them into the shared libbar.so. Then I have an executable whatever.exe that's linked to to libfoo.so and libbar.so. The linking of the executable fails complaining of certain missing simbols. Some symbols from liba.a are missing in libbar.so. Let's say that there's a symbol S in liba.a, that S is the only symbol in its object, and that S is not used by libfoo. In Darwin, S will not be included in libfoo, and the result you get is expectable. I don't know if this simple explanation translates to Linux. I don't know either, but that seems to be the case. Any ideas on how to fix it? IMHO, you shouldn't use symbols from liba in libbar if libbar doesn't link against liba. I think you could do either of 1.- make all your static libs dynamic, and link libbar against liba if libbar uses symbols from liba. 2.- link neither libfoo nor libbar to liba, but link whatever.exe to liba. This will require an extra flag about undefined symbols under Darwin, but I don't think ld will complain under Linux. Option (1) seems far nicer to me. Hope this helps. Renaud. Thanks. Your options seem very reasonable. The thing is, though, that the various liba, libb, libc were meant to be only used to build a bigger library called libfoo. Then why don't you build all objects from foo, a, b, c to be PIC and pack them all together in foo? Or if you really want intermediate archives, maybe you can build the objects of a, b, c to be PIC, archive them in .a archives, and use ld to put them together. But this is not the same thing as linking foo to a, b, c using gcc and -la -lb -lc, which means to only fetch needed symbols. The bottom line is, what you mean to do is probably not very common, and I don't think there will be a high-level CMake primitive that will do that for you. This is just my opinion though :-) What do you mean by PIC? Thanks! -- Salvatore Iovene http://www.iovene.com/ Key Fingerprint: 5647 944D D5AD 2E87 00B4 7D54 2864 359D FF20 16D8 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 11/7/07, Hendrik Sattler [EMAIL PROTECTED] wrote: Quoting Salvatore Iovene [EMAIL PROTECTED]: On 11/7/07, Salvatore Iovene [EMAIL PROTECTED] wrote: What do you mean by PIC? Thanks! Oh, -fPIC. I figured it out. Seems to work fine on Linux. I still have to try it on Windows tho. I hope it's good as a solution and not just a hack! :) Windows DLLs work differently. When putting code into shared object under Linux, they _must_ be compiled as PIC. Back to your problem: GNU ld has an option to forcibly include all symbols during linking instead of only the used ones, take a look at its manpage. Thanks f or your answer. I checked ld man page and I think you refer to the --export-dynamic option. Building my libs with -fPIC seemed to fix the problem on Linux, so do I really need that ld option? -- Salvatore Iovene http://www.iovene.com/ Key Fingerprint: 5647 944D D5AD 2E87 00B4 7D54 2864 359D FF20 16D8 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 11/7/07, Salvatore Iovene [EMAIL PROTECTED] wrote: What do you mean by PIC? Thanks! Oh, -fPIC. I figured it out. Seems to work fine on Linux. I still have to try it on Windows tho. I hope it's good as a solution and not just a hack! :) -- Salvatore Iovene http://www.iovene.com/ Key Fingerprint: 5647 944D D5AD 2E87 00B4 7D54 2864 359D FF20 16D8 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
Quoting Salvatore Iovene [EMAIL PROTECTED]: On 11/7/07, Salvatore Iovene [EMAIL PROTECTED] wrote: What do you mean by PIC? Thanks! Oh, -fPIC. I figured it out. Seems to work fine on Linux. I still have to try it on Windows tho. I hope it's good as a solution and not just a hack! :) Windows DLLs work differently. When putting code into shared object under Linux, they _must_ be compiled as PIC. Back to your problem: GNU ld has an option to forcibly include all symbols during linking instead of only the used ones, take a look at its manpage. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On Nov 7, 2007 11:08 AM, KSpam [EMAIL PROTECTED] wrote: Static linking is a strange beast. When you link in a static library, it will only resolve symbols that are currently being used. All other symbols from the static library are pruned out. The nice thing is that this reduces the binary object size. On the other hand, symbols that may be needed further down the chain are not resolved, as you have found out. I don't see why people think this is strange. Granted, the word static is overloaded in C parlance, but generally it means the scope of the data is hidden. If you put static stuff into a dynamic library, the only intent is to make all the dynamic functions work and export properly. It's not to reveal all your underlying static gunk + the dynamic functions. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
Hello, There a much nicer platform independent writeup on this at: http://www.cmake.org/Wiki/CMake_FAQ#Does_that_mean_I_have_to_build_all_my_library_objects_twice.2C_once_for_shared_and_once_for_static.3F.21__I_don.27t_like_that.21 There may be a couple of syntactical issues with the writeup. For example, you may need to have at least one source file composing the shared library, in addition to the static libraries that you want to ad. The -fPIC should be set in SET_TARGET_PROPERTIES and not in ADD_LIBRARY. I believe the example I have below to be correct, but your mileage may vary. Regards, Juan Juan Sanchez wrote: Two things with convenience libraries. Part of this may be in the FAQ: On linux, compile the code fPIC or fpic (slightly different meanings). So for library hello: SET_TARGET_PROPERTIES( hello PROPERTIES OUTPUT_NAME hello CLEAN_DIRECT_OUTPUT 1 COMPILE_FLAGS -fPIC ) where hello is the name of your static convenience library. Make sure all symbols get put into the so: target_link_libraries(mywrap -Wl,-whole-archive hello -Wl,-no-whole-archive) where mywrap is the name of the shared library, and hello is the static library you want attached to it. If you are attaching multiple libraries, linker order may be important. Juan Salvatore Iovene wrote: Hi, I'm not 100% sure this is really a CMake related question, but I'll fire it up anyway: I'm building a series of static libraries, name them liba.a, libb.a and libc.a, and linking them into a shared library libfoo.so. Then I'm building libx.a liby.a and libz.a and linking them into the shared libbar.so. Then I have an executable whatever.exe that's linked to to libfoo.so and libbar.so. The linking of the executable fails complaining of certain missing simbols. Some symbols from liba.a are missing in libbar.so. So far I have fixed the issue by linking one of the libs of libfoo.so (say libx.a) to libbar.so. But this smells of nasy workaround. Obviously I'm doing something wrong here, so could anyone please help? Thanks! -- Juan Sanchez [EMAIL PROTECTED] 800-538-8450 Ext. 54395 512-602-4395 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
Two things with convenience libraries. Part of this may be in the FAQ: On linux, compile the code fPIC or fpic (slightly different meanings). So for library hello: SET_TARGET_PROPERTIES( hello PROPERTIES OUTPUT_NAME hello CLEAN_DIRECT_OUTPUT 1 COMPILE_FLAGS -fPIC ) where hello is the name of your static convenience library. Make sure all symbols get put into the so: target_link_libraries(mywrap -Wl,-whole-archive hello -Wl,-no-whole-archive) where mywrap is the name of the shared library, and hello is the static library you want attached to it. If you are attaching multiple libraries, linker order may be important. Juan Salvatore Iovene wrote: Hi, I'm not 100% sure this is really a CMake related question, but I'll fire it up anyway: I'm building a series of static libraries, name them liba.a, libb.a and libc.a, and linking them into a shared library libfoo.so. Then I'm building libx.a liby.a and libz.a and linking them into the shared libbar.so. Then I have an executable whatever.exe that's linked to to libfoo.so and libbar.so. The linking of the executable fails complaining of certain missing simbols. Some symbols from liba.a are missing in libbar.so. So far I have fixed the issue by linking one of the libs of libfoo.so (say libx.a) to libbar.so. But this smells of nasy workaround. Obviously I'm doing something wrong here, so could anyone please help? Thanks! -- Juan Sanchez [EMAIL PROTECTED] 800-538-8450 Ext. 54395 512-602-4395 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
Salvatore, It sounds like your static libraries were meant strictly as convenience libraries (i.e. libraries that are only used internal to the build system to make building other libraries easier). In CMake, it is much easier to not use convenience libraries. Instead, just add all of the sources from the static libraries into the appropriate shared library source list. In other words skip the middle man. Static linking is a strange beast. When you link in a static library, it will only resolve symbols that are currently being used. All other symbols from the static library are pruned out. The nice thing is that this reduces the binary object size. On the other hand, symbols that may be needed further down the chain are not resolved, as you have found out. Justin ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
I believe this to be the more accurate than the FAQ and my previous example. In addition, the static and shared libraries can have the same name. Note that cat.cc is an empty file, since the linker will not work without at least one object file on the dynamic target. IF(CMAKE_SYSTEM_NAME STREQUAL Linux AND CMAKE_COMPILER_IS_GNUCC) ADD_LIBRARY(zzSTATIC STATIC dog.cc) ADD_LIBRARY(zzDYNAMIC SHARED cat.cc) TARGET_LINK_LIBRARIES(zzDYNAMIC -Wl,-whole-archive zzSTATIC -Wl,-no-whole-archive) SET_TARGET_PROPERTIES( zzSTATIC PROPERTIES OUTPUT_NAME zz CLEAN_DIRECT_OUTPUT 1 COMPILE_FLAGS -fPIC ) SET_TARGET_PROPERTIES( zzDYNAMIC PROPERTIES OUTPUT_NAME zz CLEAN_DIRECT_OUTPUT 1 ) ENDIF(CMAKE_SYSTEM_NAME STREQUAL Linux AND CMAKE_COMPILER_IS_GNUCC) Regards, Juan Juan Sanchez wrote: Hello, There a much nicer platform independent writeup on this at: http://www.cmake.org/Wiki/CMake_FAQ#Does_that_mean_I_have_to_build_all_my_library_objects_twice.2C_once_for_shared_and_once_for_static.3F.21__I_don.27t_like_that.21 There may be a couple of syntactical issues with the writeup. For example, you may need to have at least one source file composing the shared library, in addition to the static libraries that you want to ad. The -fPIC should be set in SET_TARGET_PROPERTIES and not in ADD_LIBRARY. I believe the example I have below to be correct, but your mileage may vary. Regards, Juan Juan Sanchez wrote: Two things with convenience libraries. Part of this may be in the FAQ: On linux, compile the code fPIC or fpic (slightly different meanings). So for library hello: SET_TARGET_PROPERTIES( hello PROPERTIES OUTPUT_NAME hello CLEAN_DIRECT_OUTPUT 1 COMPILE_FLAGS -fPIC ) where hello is the name of your static convenience library. Make sure all symbols get put into the so: target_link_libraries(mywrap -Wl,-whole-archive hello -Wl,-no-whole-archive) where mywrap is the name of the shared library, and hello is the static library you want attached to it. If you are attaching multiple libraries, linker order may be important. Juan Salvatore Iovene wrote: Hi, I'm not 100% sure this is really a CMake related question, but I'll fire it up anyway: I'm building a series of static libraries, name them liba.a, libb.a and libc.a, and linking them into a shared library libfoo.so. Then I'm building libx.a liby.a and libz.a and linking them into the shared libbar.so. Then I have an executable whatever.exe that's linked to to libfoo.so and libbar.so. The linking of the executable fails complaining of certain missing simbols. Some symbols from liba.a are missing in libbar.so. So far I have fixed the issue by linking one of the libs of libfoo.so (say libx.a) to libbar.so. But this smells of nasy workaround. Obviously I'm doing something wrong here, so could anyone please help? Thanks! -- Juan Sanchez [EMAIL PROTECTED] 800-538-8450 Ext. 54395 512-602-4395 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 2007-11-07 11:55-0500 Brandon Van Every wrote: On Nov 7, 2007 11:08 AM, KSpam [EMAIL PROTECTED] wrote: Static linking is a strange beast. When you link in a static library, it will only resolve symbols that are currently being used. All other symbols from the static library are pruned out. The nice thing is that this reduces the binary object size. On the other hand, symbols that may be needed further down the chain are not resolved, as you have found out. I don't see why people think this is strange. Granted, the word static is overloaded in C parlance, but generally it means the scope of the data is hidden. If you put static stuff into a dynamic library, the only intent is to make all the dynamic functions work and export properly. It's not to reveal all your underlying static gunk + the dynamic functions. I agree static has overloaded meanings depending on context, but I don't agree with your interpreation of the meaning of static in the case of Unix libraries. (I have no clue about the windows linking case so my remarks below may only apply to the Unix case.) Let's take the simple case of one main programme linked to one library. If the library is static, then linking simply creates an executable consisting of the main routine and copies of the subset of routines that it directly or indirectly uses from the library. The result is a large, completely independent executable. The shared library case is quite different. The linking produces a small incomplete executable consisting of just the main routine plus some minimal extra information to allow the run-time loader to do its job. That executable is essentially completed at run time by the run-time loader which uses routines from the shared library as required to resolve the symbols in the main routine. Thus, the shared library code that is actually used at run time depends on what exists at run time in the library and not what existed in say a previous version of the library at link time. The practical advantage of the static libraries case is simplicity. The practical advantage of the shared libraries case is it is a more flexible linking system which allows fixing bugs in libraries without having to recompile or relink executables. For CMake (and all other build systems I am aware of), the user has a choice of making static libraries or shared libraries from exactly the same library source code. There is no intention to hide the scope of the symbols or anything like that since it is exactly the same library source code in both cases. For more complicated cases of say when you are linking a shared library with a static library, just like the simpler case above the static library code subset that the shared library uses becomes part of the shared library (which is why the -fPIC compile option must be used for the static library code for this case). For real world cases where you have a large collection of interdependent libraries being built for some software project that also depend on external libraries, there are some KISS rules I follow that greatly simplify linking issues. (1) No circular dependencies allowed. (2) For every library that is linked, all symbols in that library must be resolved by explicitly mentioning all libraries at link time that supply the required symbol definitions. I enforce that rule in the Linux case by periodically testing every library that I create with CMake using the ldd -r command. (3) Note, the above two rules are all you really need for the shared libraries case (which is my principal development focus). However, if you have external libraries that are static or if you choose static libraries for the libraries you are building internally with CMake, then a third rule is the static libraries a given executable or library depends upon must be listed in the correct order when linking. If, for example, you are linking an executable which depends on static libraries libb and libc, and libb in turn depends on libc (i.e., has symbols that are resolved by code in libc), then you must mention the libraries in the order libb and libc for the link step and not in the order libc, libb. These KISS linking rules are not all demanded by the Linux linking environment but I follow them anyway because all cross-platform linking issues just simply disappear, and life is good. Thus, I recommend them to others. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __
[CMake] Linking problem
Hi, I'm not 100% sure this is really a CMake related question, but I'll fire it up anyway: I'm building a series of static libraries, name them liba.a, libb.a and libc.a, and linking them into a shared library libfoo.so. Then I'm building libx.a liby.a and libz.a and linking them into the shared libbar.so. Then I have an executable whatever.exe that's linked to to libfoo.so and libbar.so. The linking of the executable fails complaining of certain missing simbols. Some symbols from liba.a are missing in libbar.so. So far I have fixed the issue by linking one of the libs of libfoo.so (say libx.a) to libbar.so. But this smells of nasy workaround. Obviously I'm doing something wrong here, so could anyone please help? Thanks! -- Salvatore Iovene http://www.iovene.com/ Key Fingerprint: 5647 944D D5AD 2E87 00B4 7D54 2864 359D FF20 16D8 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake linking problem
On Friday 13 July 2007 07:26, Anders Sandholm wrote:
Hi
...
Now when I build in vs2005 it says:
---
-
1-- Build started: Project: qtproject, Configuration: Release Win32
-- 1Linking...
1window.obj : error LNK2019: unresolved external symbol public:
static struct QMetaObject const Window::staticMetaObject
([EMAIL PROTECTED]@@2UQMetaObject@@B) referenced in function
public: static class QString __cdecl Window::tr(char const *,char
const *) ([EMAIL PROTECTED]@@SA?AVQString@@[EMAIL PROTECTED])
I think these are moc problems.
# tell cmake to create .moc files for all files in the variable
qtproject_SRCS that require such a file.
# note: this assumes that you use #include header.moc in your files
qt4_automoc(${qtproject_SRCS})
So, do your source files include the moc files ?
If not, you have to use qt4_wrap_cpp() to generate the moc sources (which I
would recommend anyway).
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: cmake linking problem
Hi
Thank you all, problem solved, off course it was a case of RTFM... I
have just left out the generating of the moc files
Thanks
best regards
Anders
On 7/13/07, Anders Sandholm [EMAIL PROTECTED] wrote:
Hi
Using Cmake (vtk) with QT and trying to build using visual studio
2005. Now I have compiled both vtk and QT with visual studio 2005, and
simple QT applications (like hello world workes perfekt) but now I try
to do some a little more advanced and I get a linking problem.
The source code that I try to compile is the Sliders Example
(http://doc.trolltech.com/4.0/widgets-sliders.html)
(the HelloWorld example I can compile with cmake)
Now I am new to CMake, but the CMake file I am using look like:
PROJECT (Test)
FIND_PACKAGE(VTK REQUIRED)
find_package(Qt4 REQUIRED)
IF(NOT VTK_USE_RENDERING)
MESSAGE(FATAL_ERROR Example ${PROJECT_NAME} requires VTK_USE_RENDERING.)
ENDIF(NOT VTK_USE_RENDERING)
INCLUDE(${VTK_USE_FILE})
include(${QT_USE_FILE})
# the next line sets up include and link directories and defines some
variables that we will use.
# you can modify the behavior by setting some variables, e.g.
# set(QT_USE_OPENGL TRUE)
# - this will cause cmake to include and link against the OpenGL module
include(${QT_USE_FILE})
# the variable qtproject_SRCS contains all .cpp files of this project
set(qtproject_SRCS
main.cpp
window.h
window.cpp
slidersgroup.h
slidersgroup.cpp
)
INCLUDE_DIRECTORIES(qtproject_SRCS
${QT_INCLUDE_DIR}
${QT_QTNETWORK_INCLUDE_DIR}
${QT_QTTEST_INCLUDE_DIR}
)
link_directories(qtproject_srcs
${QT_LIBRARIES}
${QT_QTNETWORK_LIBRARIES}
${QT_QTTEST_LIBRARIES}
)
# tell cmake to create .moc files for all files in the variable
qtproject_SRCS that require such a file.
# note: this assumes that you use #include header.moc in your files
qt4_automoc(${qtproject_SRCS})
# create an executable file named qtproject from the source files in
the variable qtproject_SRCS.
add_executable(qtproject ${qtproject_SRCS})
TARGET_LINK_LIBRARIES(qtproject
${QT_LIBRARIES}
${QT_QTNETWORK_LIBRARIES}
${QT_QTTEST_LIBRARIES}
)
Now when I build in vs2005 it says:
1-- Build started: Project: qtproject, Configuration: Release Win32 --
1Linking...
1window.obj : error LNK2019: unresolved external symbol public:
static struct QMetaObject const Window::staticMetaObject
([EMAIL PROTECTED]@@2UQMetaObject@@B) referenced in function
public: static class QString __cdecl Window::tr(char const *,char
const *) ([EMAIL PROTECTED]@@SA?AVQString@@[EMAIL PROTECTED])
1window.obj : error LNK2001: unresolved external symbol public:
virtual struct QMetaObject const * __thiscall
Window::metaObject(void)const
([EMAIL PROTECTED]@@UBEPBUQMetaObject@@XZ)
1window.obj : error LNK2001: unresolved external symbol public:
virtual void * __thiscall Window::qt_metacast(char const *)
([EMAIL PROTECTED]@@[EMAIL PROTECTED])
1window.obj : error LNK2001: unresolved external symbol public:
virtual int __thiscall Window::qt_metacall(enum
QMetaObject::Call,int,void * *)
([EMAIL PROTECTED]@@[EMAIL PROTECTED]@@[EMAIL PROTECTED])
1slidersgroup.obj : error LNK2001: unresolved external symbol
public: virtual struct QMetaObject const * __thiscall
SlidersGroup::metaObject(void)const
([EMAIL PROTECTED]@@UBEPBUQMetaObject@@XZ)
1slidersgroup.obj : error LNK2001: unresolved external symbol
public: virtual void * __thiscall SlidersGroup::qt_metacast(char
const *) ([EMAIL PROTECTED]@@[EMAIL PROTECTED])
1slidersgroup.obj : error LNK2001: unresolved external symbol
public: virtual int __thiscall SlidersGroup::qt_metacall(enum
QMetaObject::Call,int,void * *)
([EMAIL PROTECTED]@@[EMAIL PROTECTED]@@[EMAIL PROTECTED])
1Release\qtproject.exe : fatal error LNK1120: 7 unresolved externals
1Build log was saved at file://z:\temp2\qtproject.dir\Release\BuildLog.htm
1qtproject - 8 error(s), 0 warning(s)
== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ==
The BuildLog.htm says
Build Log Build started: Project: qtproject, Configuration: Release|Win32
Command Lines Creating temporary file
z:\temp2\qtproject.dir\Release\RSP0136204020.rsp with contents
[
/OUT:Release\qtproject.exe /VERSION:0.0 /INCREMENTAL:NO
/LIBPATH:c:\vtkBin\bin\Release /LIBPATH:c:\vtkBin\bin
/LIBPATH:qtproject_srcs\Release /LIBPATH:qtproject_srcs
/LIBPATH:optimized\Release /LIBPATH:optimized
/LIBPATH:c:\QT\lib\QtGui4.lib\Release
/LIBPATH:c:\QT\lib\QtGui4.lib /LIBPATH:debug\Release
/LIBPATH:debug /LIBPATH:c:\QT\lib\QtGuid4.lib\Release
[CMake] cmake linking problem
Hi
Using Cmake (vtk) with QT and trying to build using visual studio
2005. Now I have compiled both vtk and QT with visual studio 2005, and
simple QT applications (like hello world workes perfekt) but now I try
to do some a little more advanced and I get a linking problem.
The source code that I try to compile is the Sliders Example
(http://doc.trolltech.com/4.0/widgets-sliders.html)
(the HelloWorld example I can compile with cmake)
Now I am new to CMake, but the CMake file I am using look like:
PROJECT (Test)
FIND_PACKAGE(VTK REQUIRED)
find_package(Qt4 REQUIRED)
IF(NOT VTK_USE_RENDERING)
MESSAGE(FATAL_ERROR Example ${PROJECT_NAME} requires VTK_USE_RENDERING.)
ENDIF(NOT VTK_USE_RENDERING)
INCLUDE(${VTK_USE_FILE})
include(${QT_USE_FILE})
# the next line sets up include and link directories and defines some
variables that we will use.
# you can modify the behavior by setting some variables, e.g.
# set(QT_USE_OPENGL TRUE)
# - this will cause cmake to include and link against the OpenGL module
include(${QT_USE_FILE})
# the variable qtproject_SRCS contains all .cpp files of this project
set(qtproject_SRCS
main.cpp
window.h
window.cpp
slidersgroup.h
slidersgroup.cpp
)
INCLUDE_DIRECTORIES(qtproject_SRCS
${QT_INCLUDE_DIR}
${QT_QTNETWORK_INCLUDE_DIR}
${QT_QTTEST_INCLUDE_DIR}
)
link_directories(qtproject_srcs
${QT_LIBRARIES}
${QT_QTNETWORK_LIBRARIES}
${QT_QTTEST_LIBRARIES}
)
# tell cmake to create .moc files for all files in the variable
qtproject_SRCS that require such a file.
# note: this assumes that you use #include header.moc in your files
qt4_automoc(${qtproject_SRCS})
# create an executable file named qtproject from the source files in
the variable qtproject_SRCS.
add_executable(qtproject ${qtproject_SRCS})
TARGET_LINK_LIBRARIES(qtproject
${QT_LIBRARIES}
${QT_QTNETWORK_LIBRARIES}
${QT_QTTEST_LIBRARIES}
)
Now when I build in vs2005 it says:
1-- Build started: Project: qtproject, Configuration: Release Win32 --
1Linking...
1window.obj : error LNK2019: unresolved external symbol public:
static struct QMetaObject const Window::staticMetaObject
([EMAIL PROTECTED]@@2UQMetaObject@@B) referenced in function
public: static class QString __cdecl Window::tr(char const *,char
const *) ([EMAIL PROTECTED]@@SA?AVQString@@[EMAIL PROTECTED])
1window.obj : error LNK2001: unresolved external symbol public:
virtual struct QMetaObject const * __thiscall
Window::metaObject(void)const
([EMAIL PROTECTED]@@UBEPBUQMetaObject@@XZ)
1window.obj : error LNK2001: unresolved external symbol public:
virtual void * __thiscall Window::qt_metacast(char const *)
([EMAIL PROTECTED]@@[EMAIL PROTECTED])
1window.obj : error LNK2001: unresolved external symbol public:
virtual int __thiscall Window::qt_metacall(enum
QMetaObject::Call,int,void * *)
([EMAIL PROTECTED]@@[EMAIL PROTECTED]@@[EMAIL PROTECTED])
1slidersgroup.obj : error LNK2001: unresolved external symbol
public: virtual struct QMetaObject const * __thiscall
SlidersGroup::metaObject(void)const
([EMAIL PROTECTED]@@UBEPBUQMetaObject@@XZ)
1slidersgroup.obj : error LNK2001: unresolved external symbol
public: virtual void * __thiscall SlidersGroup::qt_metacast(char
const *) ([EMAIL PROTECTED]@@[EMAIL PROTECTED])
1slidersgroup.obj : error LNK2001: unresolved external symbol
public: virtual int __thiscall SlidersGroup::qt_metacall(enum
QMetaObject::Call,int,void * *)
([EMAIL PROTECTED]@@[EMAIL PROTECTED]@@[EMAIL PROTECTED])
1Release\qtproject.exe : fatal error LNK1120: 7 unresolved externals
1Build log was saved at file://z:\temp2\qtproject.dir\Release\BuildLog.htm
1qtproject - 8 error(s), 0 warning(s)
== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ==
The BuildLog.htm says
Build Log Build started: Project: qtproject, Configuration: Release|Win32
Command Lines Creating temporary file
z:\temp2\qtproject.dir\Release\RSP0136204020.rsp with contents
[
/OUT:Release\qtproject.exe /VERSION:0.0 /INCREMENTAL:NO
/LIBPATH:c:\vtkBin\bin\Release /LIBPATH:c:\vtkBin\bin
/LIBPATH:qtproject_srcs\Release /LIBPATH:qtproject_srcs
/LIBPATH:optimized\Release /LIBPATH:optimized
/LIBPATH:c:\QT\lib\QtGui4.lib\Release
/LIBPATH:c:\QT\lib\QtGui4.lib /LIBPATH:debug\Release
/LIBPATH:debug /LIBPATH:c:\QT\lib\QtGuid4.lib\Release
/LIBPATH:c:\QT\lib\QtGuid4.lib /LIBPATH:Imm32\Release
/LIBPATH:Imm32 /LIBPATH:Winmm\Release /LIBPATH:Winmm
/LIBPATH:c:\QT\lib\QtCore4.lib\Release
/LIBPATH:c:\QT\lib\QtCore4.lib
/LIBPATH:c:\QT\lib\QtCored4.lib\Release
