From: pjfarley AT banet DOT net (Peter J. Farley III) Newsgroups: comp.os.msdos.djgpp Subject: Re: Subtle bash/ls/environment bug? Date: Sun, 30 Aug 1998 06:02:52 GMT Message-ID: <35e8e758.51804564@news1.banet.net> References: <35e89dbf DOT 32961430 AT news1 DOT banet DOT net> NNTP-Posting-Host: 32.100.253.70 Organization: IBM.NET Lines: 32 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk pjfarley AT banet DOT net (Peter J. Farley III) wrote: >and gcc complains that it cannot find libintl.h, but the directory >"../intl" is included as one of gcc's arguments, ... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ FALSE. My apologies, this is patently untrue, as my own example in my original message clearly shows. When I wrote this, I was looking at a make display from the processing in the "intl" directory just above the error, but when in the "vfs" directory the *only* include for the "intl" directory is the absolute path "//h/mc-4.1.35/intl". Thus, my question becomes, why can't gcc find a file which provably exists in this directory? Does the behavior of the "ls" command give a clue why gcc can't see it? LFN is definitely set to "Y", that's not an issue. And I tried changing the to "libintl.h", and got the same results, ENOENT. I have found the place in configure where the absolute path is set, it uses `pwd`. I can easily change this to "..", but I don't know what else this would break (yet; I may well try it anyway). I suspect that it would break building in a directory different from the sources, based on the variable name used (builddir). I will develop a simple gcc test suite to see if I can demonstrate the problem independant of this project. Any ideas on how to solve this gratefully accepted. ---------------------------------------------------- Peter J. Farley III (pjfarley AT nospam DOT dorsai DOT org OR pjfarley AT nospam DOT banet DOT net)