On 2 October 2010 23:19, Andreas Pakulat ap...@gmx.de wrote:
[...]
Thats because a link-interface for an executable doesn't make the
slightest sense. The link-interface in cmake for a library target foo,
defines which libraries should automatically get into the linker-call
when linking some
Resolved!
The solution was to set CMAKE_EXE_LINKER_FLAGS using -Wl,--as-needed.
CMakeLists.txt:
==
cmake_minimum_required (VERSION 2.6)
project(galinette)
set(GALINETTE_VERSION 1.1 CACHE STRING
Software version FORCE)
set(bindir
No sure what happened to this message. I checked the list archive, and
only half of the message appeared
http://www.cmake.org/pipermail/cmake/2010-October/039975.html
On 1 October 2010 16:40, Marcel Loose lo...@astron.nl wrote:
Hi Paul,
Probably one of the packages that you pull in --
On 2 October 2010 21:49, Marcel (ASTRON) lo...@astron.nl wrote:
Op zaterdag 02-10-2010 om 19:11 uur [tijdzone +0100], schreef Paul
McEnery:
No sure what happened to this message. I checked the list archive, and
only half of the message appeared
http://www.cmake.org/pipermail/cmake/2010
Hi.
I'm a cmake newbie, and have only been exposed to cmake in the form of
maintaining a Debian package. I'm working on packaging galinette
(http://galinette.sourceforge.net). I noticed that cmake appears to be
linking against libraries which are not actually required. Here is a
snippet of the
On 1 October 2010 16:40, Marcel Loose lo...@astron.nl wrote:
Hi Paul,
Probably one of the packages that you pull in -- dbus, dbug-glib,
libftdi, libglade, gtk+2, hal -- is introducing this dependency. Check
the different *_LIBRARIES variables and you'll probably find the fly in
your
