What brought this into my mind is this new feature in 2.5.0 "The new -static-libstdc++ option directs g++ to link the C++ library statically, even if the default would normally be to link it dynamically." What is need here is a half way. If code is solvable static link that part but if function is being include whole dynamic link. So getting the memory saving of dynamic and the speed advantages that static can offer. Of course usable with more libs than libstdc++.
I cannot parse what you are trying to say.
I don't understand what you are asking for either. Static libraries and dynamic libraries are usually two separate files (except under AIX) so it would be hard to decide to do one or another. Even if we figure that part out, what is the gain?
Currently for libstdc++ it must be either dynamic or static. This separation causes some problems. There need to be two halfway points. The static libs the dynamic both be there. Type one halfway is for secuirty reasons. Having access to the bytecode lto of like libstdc++ and others dynamic libs would allow deep scanning for code defects like finding allocations of memory that don't get freed and buffer overflows and others. To get this advantage lto needs know that the byte code assigned to dynamic libs is not to integrated since the dynamic libs already contain those functions. The second would build on type one. Optimizes would be allowed to look at the lto code of the dynamic lib if functions can be optimized out it can be done. If not those functions done by dynamic linking. This is halfway between static and dynamic linking. Pure dynamic compiler does not know what is inside the .so or .dll files other than the function interfaces. Doing this does raise the question if dynamic and static linking files should be two different things or should they be basically the same. Static be lto bytecode. Dynamic be precomplied + the same static lto bytecode. Allowing full static analyzation inside compiler would be a major gain to secuirty. lto closes down cross object flaws from being seen from the compiler. But it still leaves cross library flaws in dynamic that don't exist when static linking with lto. Reason static linking with lto all bytecode data can be seen even inside the libraries. Lets provide an option to close the flaw. Being able to staticly solve out with at .so lto bytecode in a lot of cases would give the same results as using the static .a lto bytecode file. Halfway could be used to remove duplication of lto bytecode to do either static or highly audited dynamic linking. 1 copy to do both.
So your half-way would be only useful for static analysis, but not for any optimization decision. Consider a function currently being void doIt() {} in the shared library. Now, if GCC sees the body it can deduce that calls to it are useless and it will DCE them. Next, the shared library implementation changes to void doIt() { printf("Hello"); } which is perfectly valid. Thus, GCC has miscompiled the program. So - it's not going to work in any way that will give extra information to GCC.