Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucbvax!bloom-beacon!eru!hagbard!sunic!news.funet.fi!hydra!poros!kankkune
From: kankkune@cs.Helsinki.FI (Risto Kankkunen)
Newsgroups: comp.windows.x
Subject: Small problem with mkfontdir when building X11R4.18
Message-ID: <8307@hydra.Helsinki.FI>
Date: 1 Nov 90 14:32:54 GMT
Sender: news@cs.Helsinki.FI
Organization: University of Helsinki, Department of Computer Science
Lines: 48


I have been building X11R4 (patched up to fix-18) for sun3 on SunOS 4.1.
Everything went well except for a little problem in making the font
directories. make World produced the following error message for each of
the font directories:

   ../../.././fonts/mkfontdir/mkfontdir .
   ld.so: libXmu.so.4: not found
   *** Error code 127
   make: Warning: Target `all' not remade because of errors
   Current working directory /home/hydra/kankkune/X.V11R4/R4/mit.sun3/\
   fonts/bdf/misc

I think mkfontdir doesn't find libXmu because it was compiled with a
relative library directory specification:

   gcc -DNOSTDHDRS -fstrength-reduce -fpcc-struct-return -o mkfontdir
   mkfontdir.o fontdir.o snf_util.o -O  -Bstatic -L../.././lib/Xmu -lXmu
   -Bdynamic

So, at run-time the relative path to libXmu from the font directory
isn't the same as from the source directory of mkfontdir.

Did I do something wrong, or is this a bug in the makefiles? I didn't
make any significant modifications to the configuration files, and I
left TOPDIR to . as the documentation said it should be a relative path.
It would make more sense to me, if the library specifications were
absolute...

Also, it seems a bit silly that these bogus relative (or absolute) paths
remain in the programs even after installing the programs and removing
the build tree. I could even imagine a situation, were these bogus paths
would be harmful. When a programs starts, the libraries are searched
first from the place specified in the executable, and only after that
from LD_LIBRARY_PATH and the default paths. If you happened to start
your programs in a wrong directory, they would find the wrong libraries
(for example Xlib for a different architecture), and there would be no
way to prevent this (e.g. with LD_LIBRARY_PATH). Wouldn't it make more
sense to use LD_LIBRARY_PATH when building the release?

I have compiled the font directories by hand, so this is not a big
problem. I just want to make sure I haven't goofed before I start
building the release for SPARC.

Risto
 Risto Kankkunen                   kankkune@cs.Helsinki.FI (Internet)
 Department of Computer Science    rkankkunen@finuh         (Bitnet)
 University of Helsinki, Finland   ..!mcvax!uhecs!kankkune   (UUCP)