[Fink-devel] X11 compatibilty problems

[Martin Costabel]

(Sorry for the long post, but IMHO this is serious)

After fighting with some crashes becasue of undefined symbols and with xemacs compiling problems under Apple's new X11, I have come to a rather pessimistic conclusion about compatibility between different versions of X11. This concerns not only Apple's X11, and not only the conflicts between threaded and non-threaded versions, but also the imminent upgrade to xfree-4.3. The observation is that

- if you are lucky, binaries compiled under a different version of xfree86 will continue to work, but in general they will break,

- libraries with the same version numbers can be incompatible (even if they have the same install_name. The install_name problem is only one aspect of the whole mess),

- if you try to compile something that links to a dylib compiled under a different version of xfree86, it won't work, in general. I give an example below.

The conclusion is that changing the version of X11 is an upgrade not unlike the Jaguar gcc3 upgrade. In order to be sure that everything works, you will have to recompile every binary and library that links to anything in /usr/X11R6/lib. And you will have to remove everything first and start from scratch, or else it won't work.

I hope I am greatly exaggerating, but I am not so sure.

Here is the example from the xemacs configure script. The program is trivial:

/* File Xawtest.c */
char threeDClassRec();

int main() {
threeDClassRec()
; return 0; }
/***/

The situation: xaw3d and xaw3d-shlibs packages compiled under xfree86-4.2.1.1-4, then Fink's xfree86* removed and Apple's X11 stuff installed.

Compile the above file using the command line

gcc -o Xawtest Xawtest.c -g -O3 -L/sw/lib -L/usr/X11R6/lib -lXaw3d -lXt

There are 250 warnings about multiply-defined symbols, but there are also *errors* about multiply-defined symbols which make the compilation unsuccessful.

The warnings come from the libX*.dylibs that live in twolevel_namespace, and the errors come from those in flat_namespace, for example libXt.dylib.

Recompiling xaw3d solves this problem. I suspect that xaw3d is not the only one, and that by analogy this means that every single dylib that links to some libX*.dylib will have to be recompiled.

--
Martin






-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel