Re: dir.h and compiling gcc 2.95.2 again

[Mike Corbeil <mcorbeil at netrevolution dot com>]

rmang@ibm.net wrote:

> It seems that I cannot recompile gcc with gcc2.95.2 and glibc2
> with my system. I am still getting these errors related to not beign
> able to detect dir.h and dirent.h. dir.h is included in the .c file, but I
> still get this error:
> ---
> /bin/sh ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../binutils/bfd -I. -D_GNU_SOURCE   -DTRAD_CORE   -I. -I../../../binutils/bfd -I../../../binutils/bfd/../include   -g -O2 -c ../../../binutils/bfd/trad-core
> .c
> gcc -DHAVE_CONFIG_H -I. -I../../../binutils/bfd -I. -
> D_GNU_SOURCE -DTRAD_CORE -I. -I../../../binutils/bfd -
> I../../../binutils/bfd/../include -g -O2 -c ../../../binutils/bfd/trad-core.c
> In file included from /usr/include/sys/dir.h:24,
>                  from ../../../binutils/bfd/trad-core.c:29:
> /usr/local/lib/gcc-lib/i686-pc-linux-gnulibc1/2.95.2/../../../../i686-pc-
> linux-gnulibc1/include/dirent.h:30: gnu/types.h: No such file or
> directory
> In file included from /usr/include/sys/dir.h:24,
>                  from ../../../binutils/bfd/trad-core.c:29:
> /usr/local/lib/gcc-lib/i686-pc-linux-gnulibc1/2.95.2/../../../../i686-pc-
> linux-gnulibc1/include/dirent.h:94: posix1_lim.h: No such file or
> directory
> /usr/local/lib/gcc-lib/i686-pc-linux-gnulibc1/2.95.2/../../../../i686-pc-
> linux-gnulibc1/include/dirent.h:104: gnu/types.h: No such file or
> directory
> make[2]: *** [trad-core.lo] Error 1
> make[2]: Leaving directory `/home/rlm/gcc-
> 2.95.2/objdir2/binutils/bfd'
> make[1]: *** [all-bfd] Error 2
> make[1]: Leaving directory `/home/rlm/gcc-2.95.2/objdir2/binutils'
> make: *** [all-binutils] Error 2
> ---
> Not sure why. All those files exist in /usr/include and
> /usr/inlcude/bits. Not sure why it is trying to reference them in gcc
> dir structure....Any ideas?
>
> Rob M.

I tend to agree that this seems odd, however this isn't the first time that I've seen error messages referring to directories using /../ the way you showed it.  Where I found this was in scripts and instead of using some
environment variable this /../ shit was hard coded.

This was on Linux and I can't say anything wrt MS OSs, but for Linux and Unix, I'ld look for this and find a way to define and use a unique environment variable, which users or administrators could define individually.

Hard coding, even if it worked most of the time, is nonetheless an undesirable idea, generally anyway.  We must always also keep in mind that people producing the latest software release could be relatively new to the
industry.

When you see messages including this /../ shit, then expect either this kind of hard coding of directory paths, or an environment variable defined with this, or both.  Do some invesitigation, which is an inherent part of the
job.

If such an environment variable doesn't exist, then hard coding is the most likely implementation, and this can lead to problems with varying configurations.  This would mean needing to focus on the configuration parameters
being used and verifying what these actually do, against authoritative documentation.  This could also mean either changing parameters or modifying the base system to allow the new application or system to install using all
defaults.

If all of this passes and you still have problems, then I'ld probably start looking for bugs in the application or tool, comparing the effects of the various options against existing documentation, because it can happen that
documentation isn't quite up to date or sufficiently comprehensive.  The other thing to do, in parallel, is to write a request for assistance in at least one fairly frequented location, like this newsgroup, other newsgroups,
and anywhere this kind of general glibc question could fit it.

Another thing is that when certain files are reported to not be found in some specific directory, try find from / for these files.  If the files exist in another location, then this may simply mean needing to modify or
create some environment variable, in Unix or Linux anyway.