D seems interesting, but...

[Gerry Weaver]

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