On 15 October 2012 23:21, Gerry Weaver <ger...@compvia.com> wrote: > On Monday, 15 October 2012 at 20:45:39 UTC, Gerry Weaver wrote: >> >> 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 > > > Hi, > > Sorry, I neglected to mention something. I did a test with a zero length > file and compared the output to the problem case. The output was, in fact, > identical. Would it be difficult to do a simple test for zero length files > and output a message like "error: zero length/empty file <filename>"? The > output in this case is fairly misleading. > > Thanks, > -G >
It would be less misleading if we got rid of _tlsstart and _tlsend. This would slim the error message down to... --- /usr/lib/i386-linux-gnu/libphobos2.a(dmain2_459_1a5.o): In function `_D2rt6dmain24mainUiPPaZi7runMainMFZv': src/rt/dmain2.d:(.text._D2rt6dmain24mainUiPPaZi7runMainMFZv+0x10): undefined reference to `_Dmain' --- Which is less cryptic, and everyone can spot a "undefined reference to `_Dmain'" more easily. However _tls is engraved in the current design of TLS. On the move to shared libraries, I would hope that these be removed and replaced. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';