"Paulo Matos" <[EMAIL PROTECTED]> writes: > Isn't this a normal > problem: an interface with some libraries using the interface. The core > creates and destroys the object of the libraries through the interface.
No, I don't believe this is a widely-used design pattern, at least not with static linking. > This seems a normal issue which turns out to be a nightmare > to solve. :-/ Firstly, your nightmare is entirely of your own doing. Secondly, it has trivial solutions. One I already mentioned: listing objects explicitly. Here is another: - rename your "registration" objects such that their names are unique, e.g. instead of "proxy p;" say proxy p_libbf; // in libbf.a proxy p_libot; // in libot.a // etc. - into your main.o add this: #ifdef PULL_LIBBF extern proxy p_libbf; proxy &p_libbf_ref = p_libbf; #endif // etc. - now you can control what is pulled into the static link: g++ -DPULL_LIBBF main.cc -c - link just the way you do now, and the object(s) that you need from libbf.a will be pulled in into the main exe, because p_libbf is now on the "needed" list. Cheers, -- In order to understand recursion you must first understand recursion. Remove /-nsp/ for email. _______________________________________________ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
