Peter Hutterer wrote: > On Wed, Feb 04, 2009 at 12:03:12AM +0100, Tomas Carnecky wrote: >> This function is defined in mi/mieq.c and used in xkb/ddxDevBtn.c, >> hence it needs a prototype. >> >> Signed-off-by: Tomas Carnecky <[email protected]> >> --- >> include/input.h | 8 ++++++++ >> 1 files changed, 8 insertions(+), 0 deletions(-) >> >> diff --git a/include/input.h b/include/input.h >> index 3b7a173..a91e7e9 100644 >> --- a/include/input.h >> +++ b/include/input.h >> @@ -474,6 +474,14 @@ extern _X_EXPORT int AllocMasterDevice(ClientPtr >> client, >> extern _X_EXPORT void DeepCopyDeviceClasses(DeviceIntPtr from, >> DeviceIntPtr to); >> >> +extern _X_EXPORT void CopyGetMasterEvent( >> + DeviceIntPtr mdev, >> + DeviceIntPtr sdev, >> + xEvent* original, >> + EventListPtr master, >> + int count >> +); >> + > > _X_INTERNAL is the better approach here. CGME should not be visible to > anyone > but the server itself.
IMO _X_INTERNAL should be used with extreme care, as it may cause erroneous behavior if not properly used, while _X_HIDDEN always does what one would expect, but feel free to tell me otherwise :-) (probably a _X_PROTECTED would be more appropriate); _X_INTERNAL is also just __hidden attribute for Sun CC. The problem is that a function with attribute internal cannot be called via a function pointer by another shared object. Also note that in the current way sdksyms.sh parses cpp output, it will take the address of that function, because the header is in the build tree, and the line starts with extern (currently one could cheat by just adding a space before "extern"). So, the proper solution should be to declare the symbol in a non sdk header, where it would not be required to use any _X_FOO attribute. I plan to convert the "cpp output parser" to generate a linker script, what should be significantly more reliable, but the first approach was to automatically generate what was once a series of hand written and outdated files (but referencing enough symbols to prevent the linker from finding "unreachable" symbols, that would only be "reachable" from external modules). > Cheers, > Peter Paulo _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
