But if you make your own Makefiles, and have better controll of linker process and flags, than it is not so hard to do. So the trick is to use two-pass compiling: first one that will create just 'import-libs', and the second one that will generate dll's itself.įor visual studio and any graphic-ide compiling, it is probably still something strange. this pragraph in some begginers guide to linkers (David Drysdale) explains it well for VS-linkers.Saying that refactoring is the only way is like forbidding 'friends' in classes. They happens in JAVA (compiler solving it by muilti-pass compiling). They are mentioned in many msdn articles as possible situations with ways to go arround them. So I need to point out that cyclic dependency are not so dangerous.
#Circular studio 1.2 .dll#
This question was first in my search for 'dll cyclic dependency', and even if it is 10 years old, it is a shame that most answers points to 'refactoring' which is a very very very stupid advice for large project and was not a question anyway.
#Circular studio 1.2 code#
Why not start moving code into DLLs only when you identify it as a self-contained module that fits into a layered design with no circularity? That way you can begin the process now but still attack it a piece at a time. But the restrictions in the normal method are there for a reason.Īs you want to transition from static libraries to DLLs, it sounds like you're assuming that you should make each static library into a DLL. Use LoadLibrary to open any DLL you like, and then use GetProcAddress to locate the functions you want to call. However, you can (with some extra work) get around this. This requires an import library to link against. Only explicitly exported things are exported, and all imports must be resolved at library link-time, by which point the identity of the DLL that will supply each imported function has been determined. Also by default everything in a shared library is exported. A library can find and call functions in any other library (or even the main binary that launched the process in the first place). The downside of this is that you don't know either. A shared library does not know where its function definition will come from until it's loaded into a process. The reason it works on Unix-like systems is because they perform actual linking resolution at load time. I know that circular dependencies are not a good thing to have, but that is not the discussion I want to have. So you can have two shared libraries that depend on each other and can be built independent of each other. I was thinking about solutions and tried out some things with gcc on linux and there it is possible to do what I suggest. We don't want to wait until we clean up all the circular dependencies. We want to move towards dll's for various reasons. The reason I am trying this is that I have a legacy system with circular dependencies, which is currently statically linked. If both dll's have the lib present, I can recompile new functionality into either of the two and the whole system still works. If foo changes, bar does not need to be recompiled, because I only depend on the signature of bar, not on the implementation of bar. I would like to know however whether visual studio offers a way to do this in a clean way. By playing with the 'References' and compiling a few times, I managed to get the dll's that I want. I have created two projects in visual studio, one for foo and one for bar. > should compile into foo.dll bar(int i) Is it possible to build this with visual studio? foo(int i) I would like each of these functions to reside in its own dll. I have a circular dependency between two functions.
0 kommentar(er)
