Re: Guidance please: static or extern __inline__

[Kean Johnston <jkj at sco dot com>]

> So, can I summarize your question as a way of trying to make "open"
> and alias for open32 or open63 and not having to get into the trap of
> different function address?  If yes, does glibc's weak_alias would
> work for you without creating new problems?
Yeah thats pretty much it, but I dont think weak aliasing
is the trick (if I understand what you mean by weak aliasing --
if you mean something other than #pragma weak then ignore the
next paragraph).

The problem with weak symbols is that they are only really
useful at link-edit time, and then only if you want to override
the symbol with one of your own. Considering that you offered
weak_alias as a solution, I am guessing that you are not talking
about simple weak symbols. I need this to be resolved at compile
time (so that we call the right version of open, stat, whatever)
without getting into the CPP namespace quagmire. But you said
"glibc's weak_alias" ... I think that puts me out of the running
considering this is a SCO platform :( This has to inteface
with our libc (this wont be the first or last time I have wished
I could use glibc).

I think for right now, I am going to go with the extern
inline and always_inline approach, and test the hell out
of the beast, with as much code as I can (testsuites and
stuff like php, apache, postgresql, Xorg, KDE, Xalan, Xerces).
If those all work I will consider my work done :) If it
doesn't work its trivial to adjust the fixincludes stuff
to use static inline, and I will do so before I submit my
patches.

Kean