Re: [CMake] cyclic DLL dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13Mar, 2008, at 17:21, Andy Lego wrote: Hello Michael, You can also try co cleanup the API so you don't need the circular dependency. This way you can still keep the library separate, but at the same time reduce problems in the future. Andy True. Ultimately this would be the only true solution. But currently it is plain impossible as I have to remain compatible to legacy stuff. On Thu, Mar 13, 2008 at 9:18 AM, Michael Wild [EMAIL PROTECTED] wrote: On 13Mar, 2008, at 15:56, David Cole wrote: The real solution is to make them into one library. If you can't have one without the other, then why bother having two? You have to have both by definition because of the two-way dependency. Why not consolidate them into one? Or... force them to be static libs (ADD_LIBRARY(... STATIC ...)) and link them both everywhere they need to be linked... Thanks But this is not possible. As I said, the smaller of the libraries must be exchangeable. And multiple versions of a merged library is just a no-go. Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfaRN0ACgkQyAe0BK8NufNhNwCfcsT622wRPvA5RdjMb0Ci+yy1 OnwAn10RQkd+r2MuINJVz3Zlje61LI2+ =4qVL -END PGP SIGNATURE- ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] cyclic DLL dependencies
Hi all I'm converting a large code for *nix to cmake and in the process also would like to port it to Windows. Unfotunately, there are two two shared libraries with cyclic dependencies on each other. On *nix this is no problem, as it is legal that a shared library contains undefined symbols. Not so for DLLs. Under cygwin/MinGW I can tackle part of the problem with the .dll.a library which allows me to link a DLL which depends on the symbols in another DLL without explicitly linking against that second library, resulting in the behavior on POSIX systems where undefined symbols are resolved during loading. This, however does not work immediately in my case, as the dependencies are cyclic. So what I came up with, is first creating a fake library, which in addition to its normal source files contains the definitions for the code it depends on in the second library. From this I create the .dll.a file with the --out-impl option (as is default in win32 CMake), use that to link the second library and then I relink the first library, minus the additional definitions and plus the .dll.a from the second library. So far, so good. But how do I tell CMake? I first tried with a fake library target. This target has a distinct name, but the same OUTPUT_NAME as the real library. It is built from the files for the first library plus the ones it depends on from the second library. Then I have a target for the second library, depending on the fake library, which uses the .dll.a file produced. Lastly I have the real library target for the first library, depending on the second library and using its .dll.a. For me this worked so far. Only problem is, that one library is huge and the other very small, but it depends on large portions of the large one. So I could turn it as I would, I can't seem to avoid compiling large parts of the huge library twice! What would be ideal for me, is being able to reuse object files from one target in another target. However, I couldn't find anything on how to achieve this in the docs or using google. Does anyone of you have an idea how to solve the cyclic dependency problem in a more elegant way or how to recycle objects? Michael PS: Making the small library part of the large one is not an option, as the small one can be exchanged with other implementations before program start. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cyclic DLL dependencies
The real solution is to make them into one library. If you can't have one without the other, then why bother having two? You have to have both by definition because of the two-way dependency. Why not consolidate them into one? Or... force them to be static libs (ADD_LIBRARY(... STATIC ...)) and link them both everywhere they need to be linked... HTH, David On 3/13/08, Michael Wild [EMAIL PROTECTED] wrote: Hi all I'm converting a large code for *nix to cmake and in the process also would like to port it to Windows. Unfotunately, there are two two shared libraries with cyclic dependencies on each other. On *nix this is no problem, as it is legal that a shared library contains undefined symbols. Not so for DLLs. Under cygwin/MinGW I can tackle part of the problem with the .dll.a library which allows me to link a DLL which depends on the symbols in another DLL without explicitly linking against that second library, resulting in the behavior on POSIX systems where undefined symbols are resolved during loading. This, however does not work immediately in my case, as the dependencies are cyclic. So what I came up with, is first creating a fake library, which in addition to its normal source files contains the definitions for the code it depends on in the second library. From this I create the .dll.a file with the --out-impl option (as is default in win32 CMake), use that to link the second library and then I relink the first library, minus the additional definitions and plus the .dll.a from the second library. So far, so good. But how do I tell CMake? I first tried with a fake library target. This target has a distinct name, but the same OUTPUT_NAME as the real library. It is built from the files for the first library plus the ones it depends on from the second library. Then I have a target for the second library, depending on the fake library, which uses the .dll.a file produced. Lastly I have the real library target for the first library, depending on the second library and using its .dll.a. For me this worked so far. Only problem is, that one library is huge and the other very small, but it depends on large portions of the large one. So I could turn it as I would, I can't seem to avoid compiling large parts of the huge library twice! What would be ideal for me, is being able to reuse object files from one target in another target. However, I couldn't find anything on how to achieve this in the docs or using google. Does anyone of you have an idea how to solve the cyclic dependency problem in a more elegant way or how to recycle objects? Michael PS: Making the small library part of the large one is not an option, as the small one can be exchanged with other implementations before program start. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cyclic DLL dependencies
Michael Wild wrote: Does anyone of you have an idea how to solve the cyclic dependency problem in a more elegant way or how to recycle objects? Yep. Look here: http://msdn2.microsoft.com/en-us/library/kkt2hd12.aspx -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cyclic DLL dependencies
On 13Mar, 2008, at 15:56, David Cole wrote: The real solution is to make them into one library. If you can't have one without the other, then why bother having two? You have to have both by definition because of the two-way dependency. Why not consolidate them into one? Or... force them to be static libs (ADD_LIBRARY(... STATIC ...)) and link them both everywhere they need to be linked... Thanks But this is not possible. As I said, the smaller of the libraries must be exchangeable. And multiple versions of a merged library is just a no-go. Michael HTH, David On 3/13/08, Michael Wild [EMAIL PROTECTED] wrote: Hi all I'm converting a large code for *nix to cmake and in the process also would like to port it to Windows. Unfotunately, there are two two shared libraries with cyclic dependencies on each other. On *nix this is no problem, as it is legal that a shared library contains undefined symbols. Not so for DLLs. Under cygwin/MinGW I can tackle part of the problem with the .dll.a library which allows me to link a DLL which depends on the symbols in another DLL without explicitly linking against that second library, resulting in the behavior on POSIX systems where undefined symbols are resolved during loading. This, however does not work immediately in my case, as the dependencies are cyclic. So what I came up with, is first creating a fake library, which in addition to its normal source files contains the definitions for the code it depends on in the second library. From this I create the .dll.a file with the --out-impl option (as is default in win32 CMake), use that to link the second library and then I relink the first library, minus the additional definitions and plus the .dll.a from the second library. So far, so good. But how do I tell CMake? I first tried with a fake library target. This target has a distinct name, but the same OUTPUT_NAME as the real library. It is built from the files for the first library plus the ones it depends on from the second library. Then I have a target for the second library, depending on the fake library, which uses the .dll.a file produced. Lastly I have the real library target for the first library, depending on the second library and using its .dll.a. For me this worked so far. Only problem is, that one library is huge and the other very small, but it depends on large portions of the large one. So I could turn it as I would, I can't seem to avoid compiling large parts of the huge library twice! What would be ideal for me, is being able to reuse object files from one target in another target. However, I couldn't find anything on how to achieve this in the docs or using google. Does anyone of you have an idea how to solve the cyclic dependency problem in a more elegant way or how to recycle objects? Michael PS: Making the small library part of the large one is not an option, as the small one can be exchanged with other implementations before program start. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cyclic DLL dependencies
Hello Michael, You can also try co cleanup the API so you don't need the circular dependency. This way you can still keep the library separate, but at the same time reduce problems in the future. Andy On Thu, Mar 13, 2008 at 9:18 AM, Michael Wild [EMAIL PROTECTED] wrote: On 13Mar, 2008, at 15:56, David Cole wrote: The real solution is to make them into one library. If you can't have one without the other, then why bother having two? You have to have both by definition because of the two-way dependency. Why not consolidate them into one? Or... force them to be static libs (ADD_LIBRARY(... STATIC ...)) and link them both everywhere they need to be linked... Thanks But this is not possible. As I said, the smaller of the libraries must be exchangeable. And multiple versions of a merged library is just a no-go. Michael HTH, David On 3/13/08, Michael Wild [EMAIL PROTECTED] wrote: Hi all I'm converting a large code for *nix to cmake and in the process also would like to port it to Windows. Unfotunately, there are two two shared libraries with cyclic dependencies on each other. On *nix this is no problem, as it is legal that a shared library contains undefined symbols. Not so for DLLs. Under cygwin/MinGW I can tackle part of the problem with the .dll.a library which allows me to link a DLL which depends on the symbols in another DLL without explicitly linking against that second library, resulting in the behavior on POSIX systems where undefined symbols are resolved during loading. This, however does not work immediately in my case, as the dependencies are cyclic. So what I came up with, is first creating a fake library, which in addition to its normal source files contains the definitions for the code it depends on in the second library. From this I create the .dll.a file with the --out-impl option (as is default in win32 CMake), use that to link the second library and then I relink the first library, minus the additional definitions and plus the .dll.a from the second library. So far, so good. But how do I tell CMake? I first tried with a fake library target. This target has a distinct name, but the same OUTPUT_NAME as the real library. It is built from the files for the first library plus the ones it depends on from the second library. Then I have a target for the second library, depending on the fake library, which uses the .dll.a file produced. Lastly I have the real library target for the first library, depending on the second library and using its .dll.a. For me this worked so far. Only problem is, that one library is huge and the other very small, but it depends on large portions of the large one. So I could turn it as I would, I can't seem to avoid compiling large parts of the huge library twice! What would be ideal for me, is being able to reuse object files from one target in another target. However, I couldn't find anything on how to achieve this in the docs or using google. Does anyone of you have an idea how to solve the cyclic dependency problem in a more elegant way or how to recycle objects? Michael PS: Making the small library part of the large one is not an option, as the small one can be exchanged with other implementations before program start. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- http://legoandy.com -o- http://capitalmtb.org Support my 150 mile bike ride to fight MS: http://bikecan.nationalmssociety.org/site/TR?px=3921627pg=personalfr_id=9066 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
