Re: [Tack-devel] ACK compiles on NetBSD-macppc, sort of...

[Perry E. M. <pe...@pi...>]

"Gregory T. (tim) Kelly" <gt...@di...> writes:
> Hi Perry,
> I definately appreciate your feedback and help.  
>
>    #if !defined(_STANDALONE) && !defined(_KERNEL)
>          #ifdef __GNUC__
>            #define __RENAME(x)     ___RENAME(x)
>         #else
>             #ifdef __lint__
>                #define __RENAME(x)     __symbolrename(x)
>              #else
>                 #error "No function renaming possible"
>            #endif /* __lint__ */
>        #endif /* __GNUC__ */
>      #else /* _STANDALONE || _KERNEL */
>         #define __RENAME(x)     no renaming in kernel or standalone environment
>     #endif

This isn't the interesting part of the code. Look, as I said, at the
ELF implementation of the macro (for example). You have to read the
code and understand how it works, where it is used and why it is used.

>
> At 10:57 PM -0400 7/19/06, Perry E. Metzger wrote:
>>Congratulations. You've hit NetBSD's symbol renaming stuff.
>>
>>Unfortunately, in order to handle API versioning, it is kind of
>>necessary for whatever compiler one uses under NetBSD to be able to
>>deal with symbol renaming in order to select the appropriate version
>>of the C library call in question -- no versioning support means you
>>have no hope at all of linking against our C library.
>
> Is this specific to NetBSD?

This specific set of macros are, but almost all modern OSes have some
form of symbol versioning. The specifics tend to be fairly OS
specific, but they almost all make use of GCC's extended assembler
syntax and/or the ability of the assembler to provide things like ELF
section directives.

> Is there a POSIX-like standard that could be applied to the
> solution, short of defining _STANDALONE?

I have no idea what _STANDALONE has to do with this. You're not
writing a boot loader.

> I would like to avoid implementing any *BSD specific code,

You have to look at how the renaming stuff is implemented.  It is not
a question of NetBSD specific code. You need to implement the sorts of
GCC extensions that the various BSDs and Linux use to do the symbol
renaming. You do not need to implement symbol renaming itself.

Bear in mind, without this sort of thing, you don't have any hope of
generating system calls on *any* modern platform. I think there are
similar hacks in Solaris but (I think) they use a different set of
compiler facilities. Windows does this sort of thing with a vengeance,
too.

> exclusion of the other BSDs (or additional work for them).  I'm also
> surmising that anything that breaks ACK (TACK?) on Linux isn't going
> to get into the tree.

You can't run on Linux without this sort of thing either.


Perry