Mail Archives: djgpp/1998/08/29/21:45:34
From: | pjfarley AT banet DOT net (Peter J. Farley III)
|
Newsgroups: | comp.os.msdos.djgpp
|
Subject: | Subtle bash/ls/environment bug?
|
Date: | Sun, 30 Aug 1998 01:46:20 GMT
|
Message-ID: | <35e89dbf.32961430@news1.banet.net>
|
NNTP-Posting-Host: | 32.100.112.147
|
Organization: | IBM.NET
|
Lines: | 88
|
To: | djgpp AT delorie DOT com
|
DJ-Gateway: | from newsgroup comp.os.msdos.djgpp
|
Hi all,
I don't think it's bash, but since that's the shell I'm running I
included it as a possibility. Sorry if this is a longish post, but
the problem is easy to say (include file not found by gcc is really
there), but it's kind of hard to describe in detail.
I'm trying to port Midnight Commander (per the post by Eli a few days
ago), and started with the latest source, mc-4.1.35.tar.gz from the
gnome site <htttp://www.gnome.org/mc/>. I renamed the configure
script and ran autoconf to recreate it for DJGPP (e.g., test -f is
replaced by test -x). The configure script ran fine, so I went to
make next. The first directory make processes is the "intl"
directory, and that made just fine. Among other things, the file
"libintl.h" is created in this directory, copied from the file
"libgettext.h" delivered in the distribution.
Next, make goes to the "vfs" directory, and the first program it
compiles there (local.c) wants to include <libintl.h>. The inclusion
is indirect, starting with:
#include "../src/util.h" in local.c, then with
#include "i18n.h" in ../src/util.h, then with
#include <libintl.h> in ../src/i18n.h
and gcc complains that it cannot find libintl.h, but the directory
"../intl" is included as one of gcc's arguments, and libintl.h does in
fact exist in this directory.
I thought at first it might be the angle brackets, i.e. <libintl.h>,
causing the problem, but then I did a little test using the "ls"
command from the bash prompt, in the vfs directory. The results are
very strange, because a relative path (../intl/lib*) works, but the
absolute path version "//h/mc-4.1.35/intl/lib*" causes the "ls"
command to produce ENOENT errors. This is important, because there is
also the directory "//h/mc-4.1.35/intl" in the gcc commandline, and it
occurs BEFORE "../intl" (though why configure includes both, I haven't
figured out yet).
Please examine the following and tell me if I'm doing something wrong
here, or have I found a subtle bug? My environment files and settings
are listed afterwards. (I fixed some of the wrapped lines manually,
sorry if they show up strange in your newsreader.)
This is what gcc does:
bash.exe//h/mc-4.1.35/vfs$ gcc -c -I.. -I//h/mc-4.1.35/intl -I./../vfs
-I./.. -I./../slang -I.. -DBINDIR="h:/djgpp/bin/"
-DLIBDIR="h:/djgpp/lib/mc/" -DICONDIR="h:/djgpp/share/icons/mc/"
-DLOCALEDIR="h:/djgpp/share/locale/" -DHAVE_CONFIG_H -g local.c
In file included from ../src/util.h:205,
from local.c:12:
../src/i18n.h:9: libintl.h: No such file or directory (ENOENT)
This is an ls with a relative path:
bash.exe//h/mc-4.1.35/vfs$ ls -l ../intl/lib*
-rw-r--r-- 1 dosuser dos 5904 Mar 19 21:15
./intl/libgettext.h
-rw-r--r-- 1 dosuser dos 28676 Aug 29 20:16
./intl/libintl.a
-rw-r--r-- 1 dosuser dos 5904 Mar 19 21:15
./intl/libintl.h
And this is an ls with an absolute path, which inexplicably fails with
ENOENT's:
bash.exe//h/mc-4.1.35/vfs$ ls -l //h/mc-4.1.35/intl/lib*
h:/djgpp/BIN/ls: //h/mc-4.1.35/intl/libgettext.h: No such file or
directory (ENOENT)
h:/djgpp/BIN/ls: //h/mc-4.1.35/intl/libintl.a: No such file or
directory (ENOENT)
h:/djgpp/BIN/ls: //h/mc-4.1.35/intl/libintl.h: No such file or
directory (ENOENT)
My Environment:
Win95/DOS Box/v4.00.950a, DJGPP V2.01, LFN=Y
GNU bash, version 1.14.7(2) r3.1 w/multibyte extension
gcc 2.8.1
binutils 2.8.1 (e.g., GNU ld 2.8.1)
GNU Make version 3.76.1
ls (GNU fileutils) 3.16
(other versions on request -- generally, the latest in v2gnu)
TIA for any help or suggestions you can provide.
----------------------------------------------------
Peter J. Farley III (pjfarley AT nospam DOT dorsai DOT org OR
pjfarley AT nospam DOT banet DOT net)
- Raw text -