[openbeos] Re: PPC versions

  • From: "Martin Krastev" <blue@xxxxxxxxx>
  • To: <openbeos@xxxxxxxxxxxxx>
  • Date: Wed, 10 Apr 2002 17:25:51 +0300

maybe this is not the best thread to jump in for a lurker as myself, still it 
some points need some factological straightening:

as unfortunate as it turns for the users of 'exotic' compilers ('exotic' as in 
things in a different to the established standards manner) the 
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 
compilers still rely on such hacks as 'dllexport' to ensure the adequate speed 
dynamic imports, instead of getting 'their os'es linker/loader preoperly 

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.

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 
a way for making classes internal/private to a module, but that's neither 
nor elf's fault. still, in the case of c++ class- and namespace-mangling 
ensure identifiers' uniqness across the modules.

don't get me wrong - i clearly see Nathan's point and can imagine what he and 
other ppc guys have to go through because of all that. i also believe that it 
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 
introduced when new source gets checked in. come to think of it, an automated 
could be developed which would parse the headers for non-static function 
vars and non-private class members and produce _exported version of those 


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.

Other related posts: