[openbeos] Re: PPC versions

  • From: "Martin Krastev" <blue@xxxxxxxxx>
  • To: <openbeos@xxxxxxxxxxxxx>
  • Date: Wed, 10 Apr 2002 19:56:02 +0300

Kaya Memisoglu <k.memisoglu@xxxxxxxx> wrote:

> I think there is another really important reason for the keyword 'export' 
> or whatever. The keyword 'static' makes a symbol local within one source file 
> / object
> file. Not within one dll. The other object files will know nothing about a 
> static function.
> And this effect might not be the one you are seeking for. On the other hand, 
> the keyword
> _EXPORT or whatever it is called will make a symbol public to the outside of 
> the whole dll.
> You see the difference? 'static' is meant for local symbols within one 
> *object* file, whereas
> '_EXPORT' is meant for global symbols of a *dll* file, which may consist out 
> of many object files.

yep, i surely see the difference, but

a) i also see the difference _export imposes on dynamic libraries vs. static 
a dll build of a given library would either export a different set of symbols 
or would not
allow a static library build at all. and that most deffinitely is an effect 
_not_ sought for,
as i want to be able to build dynamic or static _identical_ libraries on the 
expence of
a single cc setting change.

b) the very semantics of the c/c++ language encourages high level of 
visibility (AAMOF anything not explicitly 'hidden' is exported), and for good 
or for bad
the language does not distinguish between 'source/obj' modules, 'static 
library' modules
and 'dynamic library' modules. a good c/++ compiler should comply to the 
language specs.
even despite the drawback of c++ not having any means for making a class hidden 
within its
source file!

the whole dllexport thing was invented to narrow down the pool of exported 
so given the early/crippled ld's it would not take forever to load a 

> At least I suspect that the linker will handle the stuff this way. In my
> opinion '_EXPORT' might be a good thing (although i am currently not
> participating in working for OBOS). On the other hand, one could cope with 
> the exportation
> of all symbols in ELF by carefully using namespaces or declaration within
> classes in order to avoid name conflicts.

IMO, too, _export is a good thing -- in the context of obos, as it allows ppc 


Other related posts: