[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'
> '_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
libraries:
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
inter-module
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
symbols
so given the early/crippled ld's it would not take forever to load a
dynamically-linked
image.
> 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
builds.
regards
blu
Other related posts:
