[CMake] cyclic DLL dependencies

Michael Wild themiwi at gmail.com
Thu Mar 13 12:18:28 EDT 2008


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 <themiwi at gmail.com> 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 at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
>



More information about the CMake mailing list