On Monday, 15 October 2012 at 20:19:22 UTC, Gerry Weaver wrote:
On Monday, 15 October 2012 at 19:38:24 UTC, H. S. Teoh wrote:
On Mon, Oct 15, 2012 at 08:46:21PM +0200, Gerry Weaver wrote:
[...]
It just occurred to me that I've seen this type of file issue
before. If memory serves, it was related to the attempt to
load a
64bit lib on a 32bit system. It was an odd problem, because it
didn't fail in the way one would expect. The process in that
case
was reading garbage from memory. I don't get how it could be
reading
nothing though. Anyway, I'm going to look into this
possibility. I
found some notes that I made during that time and it does
have a
similar feel to it. I'll let y'all know what I find.
[...]
Now, that does sound like it could be the source of the
problem. If dmd
was reading garbage from the file, if there just happens to
be, say, a
binary 0 at the beginning (or whatever it is that causes dmd
to think it
has reached EOF), then it would just stop and produce an empty
object
file. So the linker will fail to find the symbols that dmd
emits when it
encounters main().
T
Hi,
When running dmd, none of the read (and friends) syscalls
happen as far as the kernel is concerned. This would lend some
credibility to the lib theory. However, it's quite odd that
results are the same for each time dmd is executed. I would
expect a random result or even a segfault/abort on different
runs.
Thanks,
-G
Hi,
I think I have satisfied myself that this is probably a fluke. We
have captured enough in this thread that there will be a good
starting point should the issue ever come up again. It may sound
odd, but I'm actually glad it happened. It helped me realize an
issue with a system that would probably have manifested itself in
some other frustrating and embarrassing way later on ;-)
Thanks everyone,
-G