On 11/24/2011 08:20 AM, Hendrik Sattler wrote:
BTW: linking plugins against an executable is really not good style.
Put the common part into a library and link the executable and the
plugin against that library.
Ignore the necessity or desire to load the plugin at run time for a
moment.
cmake-2.8.6 has the following documentation of the
LINK_INTERFACE_LIBRARIES property for targets:
LINK_INTERFACE_LIBRARIES
List public interface libraries for a shared library or executable.
By default linking to a shared library target transitively links to
targets with
On 11/23/2011 10:25 AM, Alan W. Irwin wrote:
cmake-2.8.6 has the following documentation of the
LINK_INTERFACE_LIBRARIES property for targets:
LINK_INTERFACE_LIBRARIES
List public interface libraries for a shared library or executable.
By default linking to a shared
On 11/23/2011 10:25 AM, Alan W. Irwin wrote:
In sum, from this experiment it looks like I will have to set
LINK_INTERFACE_LIBRARIES to empty for all PLplot library targets that
depend on other library targets (e.g., B, C, D, and E, above, but _not_
main or A) created by our build system to
On 11/23/2011 11:11 AM, Rolf Eike Beer wrote:
On 11/23/2011 10:25 AM, Alan W. Irwin wrote:
In sum, from this experiment it looks like I will have to set
LINK_INTERFACE_LIBRARIES to empty for all PLplot library targets that
depend on other library targets (e.g., B, C, D, and E, above, but
On 11/23/2011 10:25 AM, Alan W. Irwin wrote:
cmake-2.8.6 has the following documentation of the
LINK_INTERFACE_LIBRARIES property for targets:
LINK_INTERFACE_LIBRARIES
List public interface libraries for a shared library or executable.
By default linking to a shared
Am 23.11.2011 22:35, schrieb Michael Hertling:
Out of curiosity - I have not worked with RPM for ages: Are these
warnings and the related overlinking due to transitive dependencies
really an issue or just an inconvenience? Personally, I distinguish
between real overlinking, i.e. pulling in
