Replying myself... > I changed it to export all sdk symbols to not give people a reason > to compile the X Server with --disable-visibility :-) > > But there are plenty of symbols that shouldn't really be made > available to modules. While there are others that are so widely > used that now they must be made available. There are also other > symbols that were already exported, but not used by any module. > > Since several of them are in the sdk "by accident", I am considering > to create some private files, that aren't installed in the sdk. > Sample pseudo "actions" for os.h: > o copy os.h to osP.h > o change all files that include os.h to include osP.h > o change osP.h to include os.h > o edit os.h to only export what really should be available to > modules (i.e. external shared objects) > > The only special case should be symbols that would still be made > visible because they are required by modules built in the X Server > tree, but would not be made available publicly to "external" > modules, and there would not exist the requirement of having them > always available.
I don't want to break things, neither make it too difficult to merge branches, etc, so, 'after some meditation', I come with what I believe is the better approach to have it easily manageable, and with the smallest chances of having it rotting in a short time frame. What I plan to do is: o Only use _X_EXPORT in header files, for the symbols that must be made available. o C files should use only _X_INTERNAL for the cases where a symbol must really be made private, and the X Server may not be compiled with hidden symbols. This means a big "s/_X_EXPORT // `find . -name \*.c`" in the X Server tree (but of course checking one by one). o Remove hw/xfree86/loader/*sym.c, as it is not mean't for use with the "dlloader", and currently it was pretty much only useful to force the compiler to not inline functions (as it just created a vector with symbol addresses). The only requirement to have a symbol exported would be to add the _X_EXPORT in the header file, and have the C source with the definition include that header. This should have the least impact for developers, and be easy to maintain and keep up to date. I plan to do it tonight, so, if you have something agains't, say it before I push the changes, or ... Thanks, Paulo _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg