I'm not sure that this is an actual bug, but here goes anyway. I was compiling wv (Word Viewer), which means doing a ./configure, which reported that parts of the graphics libraries were missing. So I looked back at the output of .configure, and noticed that some things which were present were not being detected. Upon investigation, it turned out that the small programs created by ./configure were not compiling properly, because the linker wasn't finding libX11.a. Using gcc -v, I see that "collect2" is being called with lots of arguments, and the directories which ARE looked through are: /lib /usr/lib/gcc-lib/i386-redhat-linux/2.96 /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../ /lib /usr/lib /usr/local/lib and /usr/i386-redhat-linux/lib The directory /usr/X11R6/lib is not included in those automatically searched through, so I'd assume that compiling any X program might be problematic. Manually compiling with -L/usr/X11R6/lib worked. My first question is where gcc/egcs obtains the default list of directories which it passes on to collect2. Are these set at compile time, or do they come from a file? From what I can see, it seems that adding -L/usr/X11R6/lib to /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs is a workaround to get the desired result, but I'm not sure if this is the best way to do it. The $64,000 question I guess is whether gcc/egcs *should* automatically include an X11 directory. Perhaps include -L/usr/X11, and have /usr/X11 as a symlink to the current version... Interestingly the /etc/ld.so.conf already contains the /usr/X11R6 directory. The machine in question was clean installed with RH7 (intel), and the same thing happened with both gcc and egcs. I've recently upgraded gcc/cpp etc to 2.96-69, but no change with this particular problem. cheers, /\ndy
No version of gcc ever automatically looked into /usr/X11R6/lib. It is the sole responsibility of the configure script to add that to LDFLAGS or other variables.
Ok. Thanks for the prompt reply. I assume that adding an X11 library directory to the default -L list would probably cause some subtle problems for someone somewhere, and although I'd reckon that on balance that it would be an overall good thing, it would be a judgement call. At the end of the day though, that call isn't mine to make; it's yours, and so fair enough with what you decided. As to my other question, I assume that the default list of library and include directories is set at compile time, and the only config file which is consulted which can override them is the "specs" file, and from what I can see, the "specs" file usually doesn't have any extras in it, though it can be modified to by the end-user (or end-system admin) do so. Yes? cheers, /\ndy