Kernel_Killer
April 11th, 2004, 03:48
When I go to install certain apps, at rare times I get an error about a missing file or directory. Seems to be a port problem, since a later cvsup will fix it, but anyways....
Here's the issue. In www/mozilla, www/firefox, www/epiphany, they all had an issue with two files located in /usr/X11R6/include/X11. I check the Makefile, and /usr/X11R6/include is what should be $X11BASE. At least that's what I can gather from some of the linked files (i.e. -I{$X11BASE}X11/Xos.h). So I look at the offending file, work/mozilla/config/mkdepend/def.h. Same thing. Also looking at incomplete paths. X11/Xos.h.
So I change them to the exact path. No problem. Now the files it was looking for can't find 3 other files in that path. So then I edit Xos.h to find the files that were pointed to X11/.
So down to the real question, what is going on here? Is it the port, or is it me? Is there a path missing?
nutznboltz
April 11th, 2004, 09:29
Here's the issue. In www/mozilla, www/firefox, www/epiphany, they all had an issue with two files located in /usr/X11R6/include/X11. I check the Makefile, and /usr/X11R6/include is what should be $X11BASE. At least that's what I can gather from some of the linked files (i.e. -I{$X11BASE}X11/Xos.h). So I look at the offending file, work/mozilla/config/mkdepend/def.h. Same thing. Also looking at incomplete paths. X11/Xos.h.
Are you saying that X11/Xos.h was reported as missing? It would help to know exactly what missing files you got errors about.
When a C compiler is given a -Idirname option (dash-eye not dash-ell) the dirname is added to the list of directories to search for includes in. In the C program if an include goes[code:1:faef92f532]#include <X11/foo.h>[/code:1:faef92f532] the complete list of directories in the path is searched for a directory called X11 with a file called foo.h in it. The alternative include syntax is to use double quotes instead of angle brackets[code:1:faef92f532]#include "mystuff.h"[/code:1:faef92f532] in which case the current directory is prepended to the path.
With GCC you can make it output the search path with -v[code:1:faef92f532]$ gcc -v foo.c
Using builtin specs.
gcc version 2.95.4 20020320 [FreeBSD]
/usr/libexec/cpp0 -lang-c -v -D__GNUC__=2 -D__GNUC_MINOR__=95 -Di386 -D__FreeBSD__=4 -D__FreeBSD_cc_version=460001 -Dunix -D__i386__ -D__FreeBSD__=4 -D__FreeBSD_cc_version=460001 -D__unix__ -D__i386 -D__unix -Acpu(i386) -Amachine(i386) -Asystem(unix) -Asystem(FreeBSD) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -D__ELF__ foo.c /tmp/ccIcop1c.i
GNU CPP version 2.95.4 20020320 [FreeBSD] (i386 FreeBSD/ELF)
#include "..." search starts here:
#include <...> search starts here:
/usr/include
/usr/include
End of search list.
The following default directories have been omitted from the search path:
/usr/include/g++
End of omitted list.[/code:1:faef92f532]
the g++ directory was omitted because only the C++ compiler looks at that automatically by default.
Kernel_Killer
April 11th, 2004, 13:19
Both the Xos.h and another file ( that I cannot remember right now) were reported missing. Both were sitting in /usr/X11R6/include/X11. As to why it could not find them is beyond me. There wasn't a variable that I could see that pointed to the include directory as well.