On 12/8/06, Ethan Blanton <eblanton@...> wrote:
> Allan Clark spake unto us the following wisdom:
> > On 12/8/06, Ethan Blanton <eblanton@...> wrote:
> > > This is an artifact of the way C (and the standard Unix linker) works;
> > > in this case, what we *really* want is a function which is static in
> > > the scope of the prpl, not static in the scope of the compilation unit
> > > (oscar.o). However, we don't have that tool in our toolbox, so we
> > > simply make the function non-static and sort of don't refer to it
> > > outside of liboscar.so by convention.
> > Possible to enforce this with .map files in linux, right?
> I should have been more clear; *most* systems have a way to work
> around this, but there isn't a *standard* way that works across many
> Unix platforms (that I'm aware of, anyway). In addition, Windows has
> a mechanism for dealing with this in .dll files, and I'm sure OSX has
> something for .dylib files. However, rather than engineering a
> solution for each platform we support (and, indeed, we don't even know
> what they all are!), the convention method has worked pretty well for
> us. ;-)
Yup, I understand.
Thing is, if the XXX platform (Mac, Linux, Windows, another) flashes
warning lights, and it's common code, the XXX-check indirectly checks
the other non-XXX platforms... not so much need to do so, and (this is
a problem normally with international corporations) not everyone
always knows all the convention, has read 100% of the FAQ(s), and
thinks to ask, but everyone uses the same code. ...if an error creeps
in, the build finds it.