While trying the compiler on linux, I was surprised to find out that setting default include path in /etc/dmd.conf does not seem to work. If I set the include path on the command line, it works.

jsykari:~/work/d_tests% dmd test2.d
Error: Error reading file 'object.d'
jsykari:~/work/d_tests% dmd -I/home/jsykari/dmd/src/phobos test2.d
gcc test2.o -o test2 -lphobos -lpthread -lm
jsykari:~/work/d_tests%

/etc/dmd.conf:
---

[Environment]

DFLAGS=-I/home/jsykari/dmd/src/phobos/

---

I found out using strace that dmd actually reads /etc/dmd.conf, but then fails to open object.d. Here are relevant snippets from its output, first of the failed attempt:

jsykari:~/work/d_tests% strace dmd test.d
[...]
open("/etc/dmd.conf", O_RDONLY)         = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=61, ...}) = 0
read(3, "\r\n[Environment]\r\n\r\nDFLAGS=-I/hom"..., 61) = 61
close(3)                                = 0
unlink("test.o")                        = 0
open("test.d", O_RDONLY)                = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=403, ...}) = 0
read(3, "import c.stdio;\n\nclass Visitor {"..., 403) = 403
close(3)                                = 0
stat64("object.d", 0xbffff9c0)          = -1 ENOENT (No such file or
directory)
open("object.d", O_RDONLY)              = -1 ENOENT (No such file or
directory)
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 4), ...}) = 0
[...]

Then the succeeded attempt:

jsykari:~/work/d_tests% strace dmd test.d -I/home/jsykari/dmd/src/phobos/
[...]
open("/etc/dmd.conf", O_RDONLY)         = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=61, ...}) = 0
read(3, "\r\n[Environment]\r\n\r\nDFLAGS=-I/hom"..., 61) = 61
close(3)                                = 0
unlink("test.o")                        = -1 ENOENT (No such file or
directory)
open("test.d", O_RDONLY)                = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=403, ...}) = 0
read(3, "import c.stdio;\n\nclass Visitor {"..., 403) = 403
close(3)                                = 0
stat64("object.d", 0xbffff9a0)          = -1 ENOENT (No such file or
directory)
stat64("/home/jsykari/dmd/src/phobos/object.d", {st_mode=S_IFREG|0644,
st_size=1751, ...}) = 0
open("/home/jsykari/dmd/src/phobos/object.d", O_RDONLY) = 3
[...]

-Antti

I have no idea why it is failing for you. It works on my linux box. Check out \dmd\src\dmd\inifile.c and see if you see something obviously wrong?

"Antti Sykäri" <jsykari@gamma.hut.fi> wrote in message news:slrnbkqh8j.s51.jsykari@pulu.hut.fi...
> While trying the compiler on linux, I was surprised to find out that setting default include path in /etc/dmd.conf does not seem to work. If I set the include path on the command line, it works.
>
> jsykari:~/work/d_tests% dmd test2.d
> Error: Error reading file 'object.d'
> jsykari:~/work/d_tests% dmd -I/home/jsykari/dmd/src/phobos test2.d
> gcc test2.o -o test2 -lphobos -lpthread -lm
> jsykari:~/work/d_tests%
>
> /etc/dmd.conf:
> ---
>
> [Environment]
>
> DFLAGS=-I/home/jsykari/dmd/src/phobos/
>
> ---
>
> I found out using strace that dmd actually reads /etc/dmd.conf, but then fails to open object.d. Here are relevant snippets from its output, first of the failed attempt:
>
> jsykari:~/work/d_tests% strace dmd test.d
> [...]
> open("/etc/dmd.conf", O_RDONLY)         = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=61, ...}) = 0
> read(3, "\r\n[Environment]\r\n\r\nDFLAGS=-I/hom"..., 61) = 61
> close(3)                                = 0
> unlink("test.o")                        = 0
> open("test.d", O_RDONLY)                = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=403, ...}) = 0
> read(3, "import c.stdio;\n\nclass Visitor {"..., 403) = 403
> close(3)                                = 0
> stat64("object.d", 0xbffff9c0)          = -1 ENOENT (No such file or
> directory)
> open("object.d", O_RDONLY)              = -1 ENOENT (No such file or
> directory)
> fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 4), ...}) = 0
> [...]
>
> Then the succeeded attempt:
>
> jsykari:~/work/d_tests% strace dmd test.d -I/home/jsykari/dmd/src/phobos/
> [...]
> open("/etc/dmd.conf", O_RDONLY)         = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=61, ...}) = 0
> read(3, "\r\n[Environment]\r\n\r\nDFLAGS=-I/hom"..., 61) = 61
> close(3)                                = 0
> unlink("test.o")                        = -1 ENOENT (No such file or
> directory)
> open("test.d", O_RDONLY)                = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=403, ...}) = 0
> read(3, "import c.stdio;\n\nclass Visitor {"..., 403) = 403
> close(3)                                = 0
> stat64("object.d", 0xbffff9a0)          = -1 ENOENT (No such file or
> directory)
> stat64("/home/jsykari/dmd/src/phobos/object.d", {st_mode=S_IFREG|0644,
> st_size=1751, ...}) = 0
> open("/home/jsykari/dmd/src/phobos/object.d", O_RDONLY) = 3
> [...]
>
> -Antti
>
>
>
>
>
>
>

I have been having the same problem ever since the linux version of dmd came out.

I went to look at inifile.c, but cannot find it anywhere in any of the dmd versions I've ever downloaded.

I've attached inifile.c.

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:bil0sp$umd$1@digitaldaemon.com...
> I have been having the same problem ever since the linux version of dmd came out.
>
> I went to look at inifile.c, but cannot find it anywhere in any of the dmd versions I've ever downloaded.
>

In article <bile7b$1l8e$1@digitaldaemon.com>, Walter wrote:
> I've attached inifile.c.

Thanks! That was certainly helpful.

I think I might have found the source of the bug. In inifile() calls
putenv() with an argument that is inside an OutBuffer and therefore gets
free'd later.  putenv() is defined so that it will not copy its argument
but rather takes its ownership:

From putenv(3) man page:

       The  libc4  and  libc5  and  glibc 2.1.2 versions conform to SUSv2: the
       pointer string given to putenv() is used.  In particular,  this  string
       becomes  part  of  the  environment;  changing it later will change the
       environment.  (Thus, it is an error is to call putenv() with  an  auto-
       matic  variable  as the argument, then return from the calling function
       while string  is  still  part  of  the  environment.)   However,  glibc
       2.0-2.1.1  differs: a copy of the string is used.  On the one hand this
       causes a memory leak, and on the other hand it violates SUSv2. This has
       been fixed in glibc2.1.2.

So if you run dmd on libc 2.0-2.1.1 (which I could imagine your Red Hat has in /lib) it works fine, but on a newer glibc fails silently and the environment entry probably gets garbled.

The fix is obvious: change putenv(pn) on line 209 to putenv(strdup(pn)).

The workaround, of course, is to set DFLAGS=whatever in your shell's environment and not use /etc/dmd.conf because it could mess with it.

-Antti

Ah, wonderful. I made the fix. Thanks!