Very Computer

Linking those libraries statically is usually a waste of memory. You
should not do so unless you intend to take your compiled binaries from
one machine to another one. As you did not tell "configure" to links
statically, I believe that this has happened accidentally. This is a
problem with some versions of the Linux "binutils". You need to
provide links from libXYZ.so.x.y to libXYZ.so in order for the linker
to find the dynamic library. If the linker does not find the dynamic
library it reverts to linking statically.

Quote:> libSM libICE libXext don't show up at all.

This might be the case, because possibly your copy of Motif already
includes these libraries or does not require them for some reason or
other (possibly, because you still have Motif 1.2?). Anyways, I would
not worry about this.

Quote:> Any clues?  All these libs that are missing are in /lib (libXm) or in
> /usr/X11/lib (everything else) and should have been found.

> I don't get link errors, and all of _missing_ libs (libSM,
> libICE, libXext) have the same numbers as Markus' .. they are all
> .so.6.0 .  Also libXmu and libXt are the same version.  

> The only differences between our libs:

> I have libXpm.so.4  (not libXpm.so.3 as you do -- I don't even know anyone
> who has libXpm.so.3!) and libXm.so.1.2.4 rather than libXm.so.2

There is an unfortunate problem with the version numbers of the libXpm
library. Earlier releases did not have any official version number, so
people started to invent their own numbers. Assigning the major number
"4" seems to have been quite popular among several Linux
distributions. That is, why many programs require libXpm.so.4. Even
Metrolink's Motif requires (IMHO errorneously) that this library is
present. As of recently, the maintainers of the libXpm library started
to officially assign version numbers. According to the docs, the major
version number is the version of the file format. Currently this is
"3". The minor version number is the number that has mistakenly been
used before (so that is where the "4" came from). And the patch level
is what is often represented as a letter when refering to different
libXpm releases.

Thus the libXpm V3.4h is *officially* refered to as libXpm.so.3.4.8. I
have no clue what future Linux distributions will do and whether they
will adopt the official numbering or stick to the incompatible
numbers, but I decided that I will go with the official numbers!

This difference in version numbers and the fact that different
versions of libXpm tend to be incompatible in very subtle ways means
that it might be advisable to link this one libray statically. Also,
as suggested in the documentation that comes with XEmacs you should
try to install a recent release of libXpm, because earliers versions
had serious bugs.

N.B.: As this discussion does not have much in common with the usual
topics on comp.emacs.xemacs I set a Followup-To: for
comp.os.linux.development.apps.

Markus