(0004414)
Brad King (manager)
2006-07-07 13:08

This is not wrong. When using static libraries things that link to DevILU will need to link to DevIL and everything to which it links also in order to resolve symbols needed by objects in DevILU. This is also necessary for some platforms with shared libraries also.

(0004419)
Christopher Lux (reporter)
2006-07-09 02:35

ok, i understand, BUT:
i do this with DevIL and DevILU as shared libraries under windows (MSVC80) and this is wrong. the static libs are linked against DevIL and they so are not needed to be linked against DevILU. so this behavior is wrong and forces DevILU to know to much (the link directories to the libs)... so i think this is a but...

(0004427)
Brad King (manager)
2006-07-11 11:24

DevILU should not need to know the link directories. When you create DevIL you can just link to external libraries by their full path (as produced in ZLIB_LIBRARY by FindZLIB.cmake for example), and internal libraries by target name. Everything will be pulled through correctly.

(0004428)
Christopher Lux (reporter)
2006-07-11 12:04

this is what i do, but when i try to build DevIL and then DevILU the linker complains because he can't find lcms trough to zlib.

again, these libraries are not needed to be linked against DevILU because they are allready linked against DevIL (shared both) which is linked to DevILU. in the case both were static libraries i understand that if i add a executable project this has to be linked against the other libs but if the external libs are linked against the internal shared lib DevIL the other shared lib DevILU which is dependent on DevIL does not need to be linked against the external dependencies of DevIL because the needed symbols are allready linked into the _shared_ lib DevIL.

please tell me where i am wrong?

(0004429)
Christopher Lux (reporter)
2006-07-11 12:07

i forgot:
i do not want to link the external libraries by their full path. i tell DevIL with LINK_DIRECTORIES where to find them and add the libs with TARGET_LINK_LIBRARIES...

(0004431)
Bill Hoffman (manager)
2006-07-11 12:12

This would simply break too many projects. The chaining of libraries is a useful feature, that many projects depend on. What is really needed is the concept of a private library. So, this is more of a feature request than a bug.

(0004434)
Christopher Lux (reporter)
2006-07-11 12:25

yeah, but as i described chaining is not necessary when the external dependencies are allready linked against a shared part of the project. i see this working correcty when the part the external dependencies are linked (tried to be linked) against is static...

since when is this 'feature' in CMake. i just recently updated to 2.4.2 and i can't remember this on earlier versions (i use it since 2.0.5).

(0004437)
Christopher Lux (reporter)
2006-07-11 12:30

oh and private library does not do it i think. because DevIL is the core library and DevILU and DevILUT are utility libraries depending on DevIL. so DevIL is not a private library, it is just a direct dependency of the others.

can't there be definitions of cases when to chain the dependencies through to other projects?

like: when target for external dependency is STATIC and target of successor is SHARED or EXECUTABLE -> do chaining

or if one part of the link chain is shared the following parts do not need to be linked against the chained dependencies.

(0004438)
Bill Hoffman (manager)
2006-07-11 12:32

CMake has been chaining libraries from 1.6 I think. It has been in there for a long time. Perhaps you are finding a different issue.

(0009446)
Brad King (manager)
2007-10-12 11:40

We have plans to create target properties for propagating link information. A target's "interface libraries" will be a property that says "when you link to me you also link to these". By default the interface libraries will be the same as the implementation libraries (libraries needed to link the target). A project can set the interface libraries property to override the backwards-compatible default.

The requested functionality will be available when that feature is complete.

(0010346)
Brad King (manager)
2008-01-30 17:44

I've just committed changes to CMake in CVS that add a "LINK_INTERFACE_LIBRARIES" property to targets. It is meaningful for SHARED libraries and executables with the ENABLE_EXPORTS property set. This property replaces the transitive link dependency list with an explicit list. You should now be able to do:

add_library(DevIL SHARED ...)
target_link_libraries(DevIL lcms libjpeg libmng ...)
set_property(TARGET DevIL PROPERTY LINK_INTERFACE_LIBRARIES "")

add_library(DevILU SHARED ...)
target_link_libraries(DevILU DevIL) # links only to DevIL

This feature will be included in CMake 2.6.

Issue History
Date Modified	Username	Field	Change
2007-10-12 11:16	Bill Hoffman	Status	new => assigned
2007-10-12 11:16	Bill Hoffman	Assigned To	Bill Hoffman => Brad King
2007-10-12 11:40	Brad King	Note Added: 0009446
2008-01-30 17:44	Brad King	Status	assigned => closed
2008-01-30 17:44	Brad King	Note Added: 0010346
2008-01-30 17:44	Brad King	Resolution	reopened => fixed

Notes
(0004414) Brad King (manager) 2006-07-07 13:08	This is not wrong. When using static libraries things that link to DevILU will need to link to DevIL and everything to which it links also in order to resolve symbols needed by objects in DevILU. This is also necessary for some platforms with shared libraries also.

(0004419) Christopher Lux (reporter) 2006-07-09 02:35	ok, i understand, BUT: i do this with DevIL and DevILU as shared libraries under windows (MSVC80) and this is wrong. the static libs are linked against DevIL and they so are not needed to be linked against DevILU. so this behavior is wrong and forces DevILU to know to much (the link directories to the libs)... so i think this is a but...

(0004427) Brad King (manager) 2006-07-11 11:24	DevILU should not need to know the link directories. When you create DevIL you can just link to external libraries by their full path (as produced in ZLIB_LIBRARY by FindZLIB.cmake for example), and internal libraries by target name. Everything will be pulled through correctly.

(0004428) Christopher Lux (reporter) 2006-07-11 12:04	this is what i do, but when i try to build DevIL and then DevILU the linker complains because he can't find lcms trough to zlib. again, these libraries are not needed to be linked against DevILU because they are allready linked against DevIL (shared both) which is linked to DevILU. in the case both were static libraries i understand that if i add a executable project this has to be linked against the other libs but if the external libs are linked against the internal shared lib DevIL the other shared lib DevILU which is dependent on DevIL does not need to be linked against the external dependencies of DevIL because the needed symbols are allready linked into the _shared_ lib DevIL. please tell me where i am wrong?

(0004429) Christopher Lux (reporter) 2006-07-11 12:07	i forgot: i do not want to link the external libraries by their full path. i tell DevIL with LINK_DIRECTORIES where to find them and add the libs with TARGET_LINK_LIBRARIES...

(0004431) Bill Hoffman (manager) 2006-07-11 12:12	This would simply break too many projects. The chaining of libraries is a useful feature, that many projects depend on. What is really needed is the concept of a private library. So, this is more of a feature request than a bug.

(0004434) Christopher Lux (reporter) 2006-07-11 12:25	yeah, but as i described chaining is not necessary when the external dependencies are allready linked against a shared part of the project. i see this working correcty when the part the external dependencies are linked (tried to be linked) against is static... since when is this 'feature' in CMake. i just recently updated to 2.4.2 and i can't remember this on earlier versions (i use it since 2.0.5).

(0004437) Christopher Lux (reporter) 2006-07-11 12:30	oh and private library does not do it i think. because DevIL is the core library and DevILU and DevILUT are utility libraries depending on DevIL. so DevIL is not a private library, it is just a direct dependency of the others. can't there be definitions of cases when to chain the dependencies through to other projects? like: when target for external dependency is STATIC and target of successor is SHARED or EXECUTABLE -> do chaining or if one part of the link chain is shared the following parts do not need to be linked against the chained dependencies.

(0004438) Bill Hoffman (manager) 2006-07-11 12:32	CMake has been chaining libraries from 1.6 I think. It has been in there for a long time. Perhaps you are finding a different issue.

(0009446) Brad King (manager) 2007-10-12 11:40	We have plans to create target properties for propagating link information. A target's "interface libraries" will be a property that says "when you link to me you also link to these". By default the interface libraries will be the same as the implementation libraries (libraries needed to link the target). A project can set the interface libraries property to override the backwards-compatible default. The requested functionality will be available when that feature is complete.

(0010346) Brad King (manager) 2008-01-30 17:44	I've just committed changes to CMake in CVS that add a "LINK_INTERFACE_LIBRARIES" property to targets. It is meaningful for SHARED libraries and executables with the ENABLE_EXPORTS property set. This property replaces the transitive link dependency list with an explicit list. You should now be able to do: add_library(DevIL SHARED ...) target_link_libraries(DevIL lcms libjpeg libmng ...) set_property(TARGET DevIL PROPERTY LINK_INTERFACE_LIBRARIES "") add_library(DevILU SHARED ...) target_link_libraries(DevILU DevIL) # links only to DevIL This feature will be included in CMake 2.6.

Relationships