On Wed, Feb 04, 2009 at 12:23:10AM -0200, Paulo César Pereira de Andrade wrote: > 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.
oh. my fault then. I assumed _X_INTERNAL was "internal to the server". > 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). it may be good to clean up the header files first. I know I mostly added functions where I thought they were appropriate, and looking back now there's a lot of _X_EXPORT's that shouldn't be there. The kernel uses a #ifdef __KERNEL__ to hide what's internal only from the header file. Maybe we should be looking at a similar solution. quite frankly, the EXPORT, HIDDEN, INTERNAL, etc. is confusing me. Cheers, Peter _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
