maybe this is not the best thread to jump in for a lurker as myself, still it seems some points need some factological straightening: as unfortunate as it turns for the users of 'exotic' compilers ('exotic' as in doing things in a different to the established standards manner) the _declspec(dllexport) is a hack construct from the early dll days, when for one reason or another cc designers wanted to minimize the number of dll exports, and so tended to treat dynamic and static libraries differently WRT what gets exported and what not. OTH, what should be exported and what not is non-ambiguously specified by the core rules of the language (both c and c++) and it's a pitty some contemporary compilers still rely on such hacks as 'dllexport' to ensure the adequate speed of dynamic imports, instead of getting 'their os'es linker/loader preoperly optimized. so the fact that typically a plethora of symbols get exported by gcc has nothing to do with the merits/downs of the elf format - it's the way the c/c++ language was meant to behave. behold: every function declaration (i.e. prototype) in c/c++ not exhibiting the 'static' qualifier is meant to be accessible from outside the module it was defined in - and thus gets exported. whether coders are always careful about that is a different matter. every global variable declaration ditto. every non-private method/attribute of a class is meant to be exported, otherwise how would one subclass from that class? it's a different matter that c++ does not provide a way for making classes internal/private to a module, but that's neither compiler's nor elf's fault. still, in the case of c++ class- and namespace-mangling effectively ensure identifiers' uniqness across the modules. don't get me wrong - i clearly see Nathan's point and can imagine what he and the other ppc guys have to go through because of all that. i also believe that it wouldn't be such a heavy burden for the rest of the obos guys to use _exports in the future, but when it comes to code already written it becomes an everybody's PITA. so i guess it takes a volunteer job to ensure that the necessary dose of evil _exports gets properly introduced when new source gets checked in. come to think of it, an automated tool could be developed which would parse the headers for non-static function prototypes/global vars and non-private class members and produce _exported version of those headers. regards blu ps: giving up ppc builds until better times is not really a good idea - when those times arrive everybody will be amazed to see what great a part of the codebase has become endianness-dumb / x86-bound.