Very Computer

I'm trying to install fvwm onto my Linux 2.0.26 system, with all the
current versions of gcc, libc, binutils,etc. I've installed X
correctly and everything is set up. But when I do a 'make all' in the
fvwm directory to install it (btw, fvwm only comes as source, no
binaries), I get the following error frequently during the 'make all'
process:

/usr/i486-linux/bin/ld: cannot open -lXext: No such file or directory

finally, it just gives up and exits with the following message:

/usr/i486-linux/bin/ld: cannot open -lXext: No such file or directory
make[1]: *** [FvwmBanner] Error 1
make[1]: Leaving directory `/fvwm-1.24r/modules/FvwmBanner'
make: *** [all] Error 2

I don't know if this is just a fvwm compile/make problem, though. For
instance, taking the advice of some people on IRC in #linux, I
downloaded and tried to install AfterStep. To no avail; I got the very
same error:

/usr/i486-linux/bin/ld: cannot open -lXext: No such file or directory

If anyone can help, I'd be very appreciative. Thank you,

Go to the /usr/X11R6/lib and make a symbolic link for each one
of the libraries there, for example:

ln -s /usr/X11R6/lib/libXext.so.6.0 /usr/X11R6/lib/libXext.so
ln -s /usr/X11R6/lib/libXaw.so.6.0 /usr/X11R6/lib/libXaw.so

If the links are already there, maybe you need a link in /usr/lib,
do the following:

ln -s /usr/X11R6/lib /usr/lib/X11

Hope this helps, good luck.

Marc

Yeah, the point of linking to a .so (shared object) library version with a
link that has the major version number without the minor version number is
so that you can upgrade to library versions with newer minor version
numbers that are still compatible with old versions (bug fix upgrades)
without recompiling all of the software that calls functions from those
libraries.

I.e., I have in /lib libvga.so.1.2.8. I have a link to it

ln -s /lib/libvga.so.1.2.8 libvga.so.1

"1" is the major version and "2.8" is the minor version. Software compiled
to use that library will be compiled to look for libvga.so.1. If I upgrade
to version libvga.so.1.2.10, I just copy the new lib into /lib, rewrite
the link, and then delete the old version.

cp libvga.so.1.2.10 /lib       [this usually gets done by "make install"]
cd /lib

ln -sf libvga.so.1.2.10 libvga.so.1   [you don't need the dir prefix
                                       when making a link in the current
                                       dir to a file also in the current
                                       dir]

Now my link points to the new version, which has the same functions as the
old version, just faster and less buggy (in theory). Software compiled to
use this shared library still finds functions via "libvga.so.1" without
recompiling.

mkdir ./oldvga;mv libvga.so.1.2.8 ./oldvga  [just in case]

If no problems crop up in a few months, i.e. the backup of the old version
is no longer needed,

rm -r /lib/oldvga

If you compile libc and do a "make install", you'll notice that it makes a
backup (at least 4.6.x did) dir as a subdir of /lib (/lib/backup), and
make install puts a copy of your old versions of updated .so libs in there
before installing the new ones and making new links. You may find copies
in /tmp after compiling and installing libc as well, though these are
usually copies of the new ones that you just compiled.

This same process applies to .so libraries in /usr/lib, /usr/local/lib,
/usr/X11R6/lib, and so on. Software finds shared library functions via
the link name, which ends in the major version number of the library. It
is also useful to make a link to X11R6:

ln -s /usr/X11R6 /usr/X11

Then you can reference X11 dirs with a short name in environment variables
in /etc/profile or in ~/.bash_profile:

export PATH="$PATH:/usr/X11/bin"     [$VARNAME: means
                                       "append to old value"]
export MANPATH="$MANPATH:/usr/X11/man"

and if you upgrade to X11R7 at some point, all of your path specifications
for PATH and MANPATH in profile and in user shell .rc files don't have to
be changed from "X11R6" to "X11R7". It also is handier to type

ls /usr/X11/lib/X11/app-defaults

than it is to type

ls /usr/X11R6/lib/X11/app-defaults

(the second "/X11" is always there without release number)

Will got those errors while compiling/linking, not while
trying to run the program. ldconfig wouldn't help there, as
it creates links in the form:

/lib/libsome.so.1.5 -> /lib/libsome.so.1

When you specify "-lXext" in a link command, the linker looks
for a file called "libXext.so", the only way for this to
work is to create the link manually, as I suggested to Will.

Best regards, Toni.