On Thu, 2007-09-20 at 13:50 +0100, José Fonseca wrote: > On 9/19/07, Gabor Gombas <[EMAIL PROTECTED]> wrote: > > On Wed, Sep 19, 2007 at 10:20:49AM +0000, José Fonseca wrote: > > > However, when loaded, references to __glXFreeContext *inside* > > > libglxgext.so are linked to the external __glXFreeContext in libGL.so: > > > > If you have multiple definitions for a symbol it is completely random > > which a given reference will resolve to. > > > > Now, the two underscores are a good hint that these are internal symbols > > and they should not be exported at all or if they have to, one of them > > must be renamed. > > > > > libtool's -export-dynamic flag is not being used. Using libtool's -module > > > flag doesn't change anything. > > > > Does this symbol have to be exported? If no, you should use libtool's > > --export-symbol feature to explicitely declare which symbols should be > > visible and which should not. In fact, it is always wise to use > > --export-symbol when creating shared libraries to prevent ABI breakage > > by accidentally exporting private symbols. > > > > If __glXFreeContext should be exported, then it should be decided which > > library owns this symbol, and the other must be modified not to export > > it. > > > > If it is the case that libGL.so exports __glXFreeContext but > > libglxgext.so wants to locally override it, and for some reason you > > absolutely cannot rename it, then you must use gcc's > > __visibility__((__protected__)) attribute when declaring __glXFreeContext > > in libglgxext.so, but that is not portable to non-ELF platforms and > > other compilers and also has run-time performance costs IIRC. > > I agree in principle with your suggestions. But I'm not entitled to > decide if __glX* symbols should or not be exported, [...]
Neither am I :), but AFAICT they aren't currently referenced outside of their respective modules, and they probably shouldn't be. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
