Re: [Printing-architecture] Required prefixes for symbols in new OP specs

[Norm Jacobs <Norm.Jacobs@Sun.COM>]

Michael Sweet wrote:
> McDonald, Ira wrote:
>   
>> Hi Olaf,
>>
>> What prefix (if any) are you currently using for PCM
>> functions, variables, and constants?
>>
>> There was a strong concensus at the OP Steering Committee
>> meeting this Monday that we should NOT use 'fsg' as the
>> beginning of the prefix for any specs that are not yet 
>> formally approved.
>>
>> Relative to Michael Sweet's comment about #define to 
>> make consistent prefix (e.g., in existing JTAPI C headers),
>> that may or may not fix problems of linkers - dynamic
>> linking in Linux appears rather limited relative to some
>> other platforms - my impression.
>>     
>
> This isn't an issue - you define the new prefix to point to
> the old name, e.g.:
>
>      #define opjt_foo fsgjt_foo
>
> The compiler and linker use the old names, as before.  The
> developer can use the new names and be none the wiser.
>   
FWIW, this will work for applications linking with libraries exporting 
the old interface, but will not solve the problem for loadable modules 
that are dlopen()'d and dlsym()'d.  In those cases, the shim method you 
mention below will work or using weak symbol associations in the 
loadable module will work.  the weak symbols have the advantage of not 
introducing any additional calling overhead.

This can be done with

#pragma weak   new_symbol_name = old_symbol_name

Of course if we don't migrate to new names, none of this matters.

          -Norm

> Another method is to provide shim functions for all of the
> old names, calling the new names.  That has a performance
> impact, however, so I recommend using #define instead.
>
> Enumerations and other constants can be done the same way...
>