kankkune@cs.Helsinki.FI (Risto Kankkunen) (11/01/90)
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)
kankkune@cs.Helsinki.FI (Risto Kankkunen) (11/03/90)
I was having some problems to build the font directories. Casper Dik and Vick Khera pointed to me that this was due to a known bug in the mkfontdir's Imakefile. I had completely forgotten that the -B switch doesn't mean the same thing in gcc and cc. I would have thought that this bug had been corrected in one of the 18 fixes... However, the second point is still valid. Is it a good practice to compile the programs so that they get these bogus library paths in their executable? I think you could build the release by specifying the paths only in LD_LIBRARY_PATH. After all, now that I am testing the release (and haven't yet installed it), that is the only way to get those programs started (I don't want to cd to the programs home directories all the time). Risto Kankkunen kankkune@cs.Helsinki.FI (Internet) Department of Computer Science rkankkunen@finuh (Bitnet) University of Helsinki, Finland ..!mcvax!uhecs!kankkune (UUCP)
moss@brl.mil (Gary S. Moss (VLD/VMB) <moss>) (11/03/90)
In article <8307@hydra.Helsinki.FI>, kankkune@cs.Helsinki.FI (Risto Kankkunen) writes: |> |> 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 The problem is that "-Bstatic" is not understood by "gcc", "-static" is the analogous option. Unfortunately, "gcc" takes a "-B" option with arbitrary arguments and doesn't seem to complain about ones it doesn't know about. It would be nice if this were fixed in the MIT config/<whatever> files. We probably need a CcStaticLoadingFlag variable or something. -Gary