On Tue, Aug 02, 2005 at 10:59:01AM +0100, michael meeks wrote: > Hi H.J., > > > Why can't you you do it with ELF using a linker map? Libstdc++.so is > > built with a linker map. Any C++ shared library should use one if the > > startup time is a big concern. Of coursee, if gcc can generate a list > > of symbols suitable for linker map, which needs to be exported, it will > > be very helpful. I don't think it will be too hard to implement. > > So - the thing about linker maps (cf. the ldump4 tool) is that they > tend to be hard to maintain, not portable across platforms, a source of > grief and problems etc. ;-) [ we have several strata of old, now defunct > link maps lying around from previous investments of effort that > subsequently became useless ].
Maitaining a C++ linker map isn't easy. I think gcc should help out here. > > As I recall, I saw a suggestion (from you I think), for a new > visibility attribute 'export' or somesuch, that would resolve names > internally to the library, while still exporting the symbols. I sugggested the "export" visibility to export a symbol from an executable, even if it wasn't used by any DSOs. > > That would suit our needs beautifully - if, when used to annotate a > class, it would allow the various typeinfo / vague-linkage pieces > through as 'default'. Is it a realistic suggestion ? / if so, am happy > to knock up a patch. > > [ and of course, this is only 1/2 the problem - the other half isn't > much helped by visibility markup as previously discussed ;-] > Why not? If you know a symbol in DSO won't be overridden by others, you can resolve it locally via a linker map. H.J.
