Re: "Symbol X has different size in shared object" bug reappears

Hrvoje> This bug I haven't seen for quite a while has apparently Hrvoje> reared it ugly head one more time. I note Hrvoje defaults the widget detection in his ./configure. Hrvoje> Using Athena native widgets. Hrvoje> Using Athena dialog boxes. Configure should always report explicitly which variety of Athena it thinks it is using here. I assume implicitly it thinks it's using flat. Hrvoje can probably fix his problem just by explicitly using "--with-athena=3d". I suppose that ld does _not_ use the dynamic linker to get the library that ld.so will use, but instead finds /usr/X11R6/lib/libXaw.so*? If so, when on dynamic linking ld.so finds /usr/X11R6/lib/Xaw3d/libXaw.so*, (see below for vanilla Debian configuration and why this happens) and Pow! This would account for Hrvoje's symptoms. This particular pattern could be detected by building a simple Xaw[3d?] application that subclasses an Athena widget (is there such a thing?), running it, and grepping its output for the dreaded `consider re-linking' message. I have no idea whether that would work on non-Debian and/or non-Linux systems that might be similarly afflicted, though; I suppose that message is generated by ld.so (actually ld-linux.so, which is part of glibc). Alternatively, you could wait until the _end_ of the build process, and if --with-widgets=athena was specified, you check for the message in the output of [tx]emacs itself. Either way, if found, the build dies and reports: We're sorry; either you forgot to specify your Athena clone widget set, or you have a hosed Athena clone widget installation. If the former, please reconfigure and specify the widget set explicitly with --with-athena=<tag>, then start the build process again. We regret the delay; it is currently impossible to automatically determine the appropriate widget set when multiple sets are installed. If the latter, please send hate mail to the distributor of your Athena widget clone package, then reconfigure XEmacs to use a different widget set (Motif), and rebuild. (I guess we should be a little more polite than that. :-) A third possibility would be to try to parse the output of `/sbin/ldconfig -p | fgrep -i xaw' to try to detect conflicts between what ld.so finds and what ld will use. Alternatively, parsing /etc/ld.so.conf. Seems awf'ly fragile. We could also consider requiring "--with-athena=<something>" when $with_widgets == athena. But I think that's overkill. DP> This is caused by using mismatched flat and 3D Athena headers DP> when building. If you use 3D Athena -- and especially if you DP> have overwritten libXaw.so with a 3D version, make sure that DP> the 3D (or whatever variant) headers are on your path. My vanilla Debian potato system (Hrvoje's is probably similar) with Xaw3d installed per norm has bash-2.03$ ls -ld /usr/X11R6/lib/ lrwxrwxrwx /usr/X11R6/lib/libXaw.so -> libXaw.so.6.1 lrwxrwxrwx /usr/X11R6/lib/libXaw.so.6 -> libXaw.so.6.1 -rw-r--r-- /usr/X11R6/lib/libXaw.so.6.1 -rw-r--r-- /usr/X11R6/lib/libXaw3d.a lrwxrwxrwx /usr/X11R6/lib/libXaw3d.so -> libXaw3d.so.6.1 lrwxrwxrwx /usr/X11R6/lib/libXaw3d.so.6 -> libXaw3d.so.6.1 -rw-r--r-- /usr/X11R6/lib/libXaw3d.so.6.1 -> No overwriting. bash-2.03$ ls -l /usr/X11R6/lib/Xaw3d/ lrwxrwxrwx libXaw.so.6 -> ../libXaw3d.so.6.1 -> Does not shadow the one in the parent directory for ld, but does for ld.so as configured (see ldconfig -p output below). bash-2.03$ ls -ld /usr/X11R6/include/X11/ drwxr-xr-x /usr/X11R6/include/X11/Xaw drwxr-xr-x /usr/X11R6/include/X11/Xaw3d -> No overwriting. bash-2.03$ /sbin/ldconfig -p | fgrep -i xaw libXaw3d.so.6 (libc6) => /usr/X11R6/lib/libXaw3d.so.6 libXaw3d.so (libc6) => /usr/X11R6/lib/libXaw3d.so *** libXaw.so.6 (libc6) => /usr/X11R6/lib/Xaw3d/libXaw.so.6 libXaw.so.6 (libc5) => /usr/lib/libc5-compat/libXaw.so.6 libXaw.so.6 (libc6) => /usr/X11R6/lib/libXaw.so.6 libXaw.so (libc6) => /usr/X11R6/lib/libXaw.so -> It's the *** line above that presumably causes problems. It's due to the presence of /usr/X11R6/lib/Xaw3d at the top of /etc/ld.so.conf. mb> Shouldn't configure be able to *guarantee* that we don't have mb> mismatched headers and libraries, at least if we run on the mb> same system we build on? Probably. But the antecedent is null. "Same system" is meaningless in Linux and Windows, they mutate like E. Coli. And Linux is precisely where this problem is cropping up. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 /* What's the big deal about the millennium? ............................. .... There are still 361 shopping days left until the millennial epoch! */