www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D seems interesting, but...

reply "Gerry Weaver" <gerryw compvia.com> writes:
Hello All,

I have been looking at D off and on for several years. Initially 
I worked through a very painful experience to get D compiling on 
Linux. After that experience, I concluded that I should wait for 
it to become more mature. Since then, I do a very simple test. I 
install the latest package and try to build "Hello World". I 
figure that if "Hello World" builds successfully, I will continue 
further. I have just downloaded the latest .deb package and 
installed it on Ubuntu 12.04 32bit. Once again it fails this 
incredibly simple test. I've read many discussions about how/why, 
has/hasn't, will/won't D hit the mainstream in programming 
languages. I think this situation may offer at least one data 
point. I'm struggling to think of any other language (and I use 
several) that won't build code out of the box. D seems to have a 
lot of potential, but this needs to be fixed. I am not asking for 
help on this. I honestly don't care what the solution is. I just 
wanted the D developers to know why at least one developer is not 
using the language. I sincerely hope that the situation will 
improve. I'm looking forward to programming in D.

Thanks for your time,
-G



Here is the code:

import std.stdio;


void main()
{
   writeln("Hello, world!");
}

Here is the command:

dmd hello.d

Here is the output:

/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'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_18f_1b8.o): In 
function `_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6
hread6Thread+0x1d): 
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6
hread6Thread+0x24): 
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_19f_6e4.o): In 
function `thread_attachThis':
src/core/thread.d:(.text.thread_attachThis+0xb7): undefined 
reference to `_tlsstart'
src/core/thread.d:(.text.thread_attachThis+0xbc): undefined 
reference to `_tlsend'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17d_1b8.o): In 
function 
`_D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6
hread6Thread+0x1d): 
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6
hread6Thread+0x27): 
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17e_1b8.o): In 
function 
`_D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6
hread6Thread+0x1d): 
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6
hread6Thread+0x27): 
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(deh2_43b_525.o): In function 
`_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x4): 
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0xc): 
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x13): 
undefined reference to `_deh_end'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x36): 
undefined reference to `_deh_end'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17a_713.o): In 
function `thread_entryPoint':
src/core/thread.d:(.text.thread_entryPoint+0x64): undefined 
reference to `_tlsend'
src/core/thread.d:(.text.thread_entryPoint+0x6a): undefined 
reference to `_tlsstart'
collect2: ld returned 1 exit status
--- errorlevel 1
Oct 14 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 15-10-2012 05:10, Gerry Weaver wrote:
 Hello All,

 I have been looking at D off and on for several years. Initially I
 worked through a very painful experience to get D compiling on Linux.
 After that experience, I concluded that I should wait for it to become
 more mature. Since then, I do a very simple test. I install the latest
 package and try to build "Hello World". I figure that if "Hello World"
 builds successfully, I will continue further. I have just downloaded the
 latest .deb package and installed it on Ubuntu 12.04 32bit. Once again
 it fails this incredibly simple test. I've read many discussions about
 how/why, has/hasn't, will/won't D hit the mainstream in programming
 languages. I think this situation may offer at least one data point. I'm
 struggling to think of any other language (and I use several) that won't
 build code out of the box. D seems to have a lot of potential, but this
 needs to be fixed. I am not asking for help on this. I honestly don't
 care what the solution is. I just wanted the D developers to know why at
 least one developer is not using the language. I sincerely hope that the
 situation will improve. I'm looking forward to programming in D.

 Thanks for your time,
 -G



 Here is the code:

 import std.stdio;


 void main()
 {
    writeln("Hello, world!");
 }

 Here is the command:

 dmd hello.d

 Here is the output:

 /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'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_18f_1b8.o): In function
 `_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x1d):
 undefined reference to `_tlsend'
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x24):
 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_19f_6e4.o): In function
 `thread_attachThis':
 src/core/thread.d:(.text.thread_attachThis+0xb7): undefined reference to
 `_tlsstart'
 src/core/thread.d:(.text.thread_attachThis+0xbc): undefined reference to
 `_tlsend'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17d_1b8.o): In function
 `_D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread':
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x1d):
 undefined reference to `_tlsend'
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x27):
 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17e_1b8.o): In function
 `_D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread':
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x1d):
 undefined reference to `_tlsend'
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x27):
 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(deh2_43b_525.o): In function
 `_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x4):
 undefined reference to `_deh_beg'
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0xc):
 undefined reference to `_deh_beg'
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x13):
 undefined reference to `_deh_end'
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x36):
 undefined reference to `_deh_end'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17a_713.o): In function
 `thread_entryPoint':
 src/core/thread.d:(.text.thread_entryPoint+0x64): undefined reference to
 `_tlsend'
 src/core/thread.d:(.text.thread_entryPoint+0x6a): undefined reference to
 `_tlsstart'
 collect2: ld returned 1 exit status
 --- errorlevel 1

I really don't know what to tell you, because: $ dmd -m32 test.d $ dmd -m64 test.d $ cat test.d import std.stdio; void main() { writeln("Hello, world!"); } It Works For Me (TM). What package (URL please) did you install? -- Alex Rønne Petersen alex lycus.org http://lycus.org
Oct 14 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 15-10-2012 06:31, Gerry Weaver wrote:
 On Monday, 15 October 2012 at 04:20:04 UTC, Alex Rønne Petersen wrote:
 On 15-10-2012 05:10, Gerry Weaver wrote:
 Hello All,

 I have been looking at D off and on for several years. Initially I
 worked through a very painful experience to get D compiling on Linux.
 After that experience, I concluded that I should wait for it to become
 more mature. Since then, I do a very simple test. I install the latest
 package and try to build "Hello World". I figure that if "Hello World"
 builds successfully, I will continue further. I have just downloaded the
 latest .deb package and installed it on Ubuntu 12.04 32bit. Once again
 it fails this incredibly simple test. I've read many discussions about
 how/why, has/hasn't, will/won't D hit the mainstream in programming
 languages. I think this situation may offer at least one data point. I'm
 struggling to think of any other language (and I use several) that won't
 build code out of the box. D seems to have a lot of potential, but this
 needs to be fixed. I am not asking for help on this. I honestly don't
 care what the solution is. I just wanted the D developers to know why at
 least one developer is not using the language. I sincerely hope that the
 situation will improve. I'm looking forward to programming in D.

 Thanks for your time,
 -G



 Here is the code:

 import std.stdio;


 void main()
 {
   writeln("Hello, world!");
 }

 Here is the command:

 dmd hello.d

 Here is the output:

 /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'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_18f_1b8.o): In function
 `_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x1d):

 undefined reference to `_tlsend'
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x24):

 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_19f_6e4.o): In function
 `thread_attachThis':
 src/core/thread.d:(.text.thread_attachThis+0xb7): undefined reference to
 `_tlsstart'
 src/core/thread.d:(.text.thread_attachThis+0xbc): undefined reference to
 `_tlsend'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17d_1b8.o): In function
 `_D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread':
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x1d):

 undefined reference to `_tlsend'
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x27):

 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17e_1b8.o): In function
 `_D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread':
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x1d):

 undefined reference to `_tlsend'
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x27):

 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(deh2_43b_525.o): In function
 `_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x4):

 undefined reference to `_deh_beg'
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0xc):

 undefined reference to `_deh_beg'
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x13):

 undefined reference to `_deh_end'
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x36):

 undefined reference to `_deh_end'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17a_713.o): In function
 `thread_entryPoint':
 src/core/thread.d:(.text.thread_entryPoint+0x64): undefined reference to
 `_tlsend'
 src/core/thread.d:(.text.thread_entryPoint+0x6a): undefined reference to
 `_tlsstart'
 collect2: ld returned 1 exit status
 --- errorlevel 1

I really don't know what to tell you, because: $ dmd -m32 test.d $ dmd -m64 test.d $ cat test.d import std.stdio; void main() { writeln("Hello, world!"); } It Works For Me (TM). What package (URL please) did you install?

Hi, I downloaded the package from dlang.org. The package was dmd_2.060-0_i386.deb. The install went fine. I have to admit that I was surprised there were issues this time around. Thanks, -G

Would you happen to have an i386 Ubuntu system I could SSH into and have a look or something? I'm on amd64 over here which works OK with the amd64 package on dlang.org. I suspect we generally have a relatively low 32-bit Linux user base these days... -- Alex Rønne Petersen alex lycus.org http://lycus.org
Oct 14 2012
next sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 10/14/2012 11:09 PM, Gerry Weaver wrote:

 I was wondering why D doesn't just install everthing in one directory
 (ie; /opt/dlang)

The .zip version works that way. (At least it used to.) Just unzip in any directory: http://dlang.org/download.html
 and look at an environment variable (ie; DLANG_ROOT) to
 source everything.

You don't even need to do that. The binary detects where it is started from and finds the modules and libraries relative to its path. Ali -- D Programming Language Tutorial: http://ddili.org/ders/d.en/index.html
Oct 14 2012
prev sibling next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
On 15-10-2012 08:40, H. S. Teoh wrote:
 On Sun, Oct 14, 2012 at 11:32:30PM -0700, H. S. Teoh wrote:
 [...]
 In any case, I haven't been able to reproduce the problem you're seeing.
 I tried installing the package multiple times, upgrading the system
 libraries, etc., and everything still works for me, so I'm not sure what
 else to say. Seems like there must be some specific combination of
 libraries, system or otherwise, that makes dmd not work. Without being
 able to examine your environment, it's really hard to tell.

Funny, as soon as I said that, I manage to reproduce the same error messages (though I can't say if it's exactly the problem you're seeing) by compiling a file that doesn't define main(). In this case, I had a hello.d with main() renamed to Main(): import std.stdio; void Main() { writeln("haha"); } Running `dmd hello.d` produced a whole bunch of errors almost exactly the same as what you're seeing. Of course, I'm not sure this is exactly the problem you have, as your code does have a correctly-spelled main() (from what I can tell). But this may help find where the problem is.

Yep, those errors are always a sign that a proper main function is missing. I have no idea why you would get it otherwise, though.
 On that note, here's an enhancement request for dmd: if a program is
 missing main() for whatever reason, we really should have a more
 user-friendly error message than the reams of encrypted Klingon from the
 linker that almost nobody understands.

https://github.com/D-Programming-Language/dmd/pull/1178
 T

-- Alex Rnne Petersen alex lycus.org http://lycus.org
Oct 14 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/14/2012 11:43 PM, Alex Rønne Petersen wrote:
 Yep, those errors are always a sign that a proper main function is missing. I
 have no idea why you would get it otherwise, though.

What happens is when the compiler sees main(), it triggers the compiler to emit a bunch of extra declarations into the object file. The missing symbols Gerry is seeing are just those declarations.
Oct 15 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-15 08:40, H. S. Teoh wrote:

 On that note, here's an enhancement request for dmd: if a program is
 missing main() for whatever reason, we really should have a more
 user-friendly error message than the reams of encrypted Klingon from the
 linker that almost nobody understands.

How should DMD detect if you're building a (dynamic) library? Sure it can see that you're not using -lib or -shared but what about separate complication? -- /Jacob Carlborg
Oct 15 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/15/12 7:24 AM, Paulo Pinto wrote:
 On Monday, 15 October 2012 at 11:20:26 UTC, bearophile wrote:
 Jacob Carlborg:

 How should DMD detect if you're building a (dynamic) library? Sure it
 can see that you're not using -lib or -shared but what about separate
 complication?

What about the need to use a compiler switch if you are performing a separate compilation? A related enhancement request that I'm asking for since years is: the compiler could define a compile-time constant (like is_main_module or something) as true if the module contains the main, and false otherwise. This allows to have a main() in each module. This is handy to have, it allows to compile&run modules both as normal modules to import, or to compile and run them as stand alone programs, like when you want a module to show a demo of its capabilities, or just run its unittests. Bye, bearophile

Yes, this is a nice thing Java, .NET and Python have.

Wonder if a simple convention would suffice, e.g. every module that wanna defines a moduleMain(string[] args) and then you have one module main.d that has: void main(string[] args) { import wuddever; moduleMain(args); } Andrei
Oct 15 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/15/12 1:37 PM, foobar wrote:
 On Monday, 15 October 2012 at 15:22:38 UTC, Andrei Alexandrescu wrote:
 <snip>
 Yes, this is a nice thing Java, .NET and Python have.

Wonder if a simple convention would suffice, e.g. every module that wanna defines a moduleMain(string[] args) and then you have one module main.d that has: void main(string[] args) { import wuddever; moduleMain(args); } Andrei

Great idea! But why add another (redundant) level of indirection? It should go in the C main in druntime together with a mechanism to call the correct D main, by e.g. reading the module name from the command line.

Well there's a tension here: good language design generally aims at providing few general features applicable to many use cases. Encoding particular use cases in the language is warranted by either disproportionate frequency in use or disproportionate difficulty in implementing them within the language. I don't think this particular feature scores very highly in either category. Andrei
Oct 15 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/15/12 4:12 PM, bearophile wrote:
 Andrei Alexandrescu:

 Well there's a tension here: good language design generally aims at
 providing few general features applicable to many use cases. Encoding
 particular use cases in the language is warranted by either
 disproportionate frequency in use or disproportionate difficulty in
 implementing them within the language. I don't think this particular
 feature scores very highly in either category.

It's a feature that I use about in every Python module/package I've written, and it's about as equally used in code you see in Python repositories. So it's a common need in Python. I'm asking for it for more than three years or so.

I don't think that compares apples to apples, as the entire feature combination present into either language must be taken into account.
 And regarding the implementation my "hack" means having a single
 compile-time constant (plus a switch to be used when you want partial
 compilation?). Better designs are possible, but it's a matter of how
 much you want to work for it.

I think for someone coming from Python, something akin to if __name__ == "__main__": main() makes good sense. In my opinion that's not a design we should copy. Andrei
Oct 15 2012
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/14/2012 10:14 PM, Gerry Weaver wrote:
 I checked it out. There is only a dmd.conf. I've included it below.

Try the following: locate dmd.conf locate dmd locate libphobos2.a locate object.di and see if there are any extras of these floating around.
Oct 15 2012
prev sibling next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
On 15-10-2012 06:39, H. S. Teoh wrote:
 On Mon, Oct 15, 2012 at 06:20:03AM +0200, Alex Rnne Petersen wrote:
 On 15-10-2012 05:10, Gerry Weaver wrote:

 dmd hello.d

 Here is the output:

 /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'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_18f_1b8.o): In function
 `_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x1d):
 undefined reference to `_tlsend'
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x24):
 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_19f_6e4.o): In function
 `thread_attachThis':
 src/core/thread.d:(.text.thread_attachThis+0xb7): undefined reference to
 `_tlsstart'
 src/core/thread.d:(.text.thread_attachThis+0xbc): undefined reference to
 `_tlsend'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17d_1b8.o): In function
 `_D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread':
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x1d):
 undefined reference to `_tlsend'
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x27):
 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17e_1b8.o): In function
 `_D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread':
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x1d):
 undefined reference to `_tlsend'
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x27):
 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(deh2_43b_525.o): In function
 `_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x4):
 undefined reference to `_deh_beg'
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0xc):
 undefined reference to `_deh_beg'
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x13):
 undefined reference to `_deh_end'
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x36):
 undefined reference to `_deh_end'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17a_713.o): In function
 `thread_entryPoint':
 src/core/thread.d:(.text.thread_entryPoint+0x64): undefined reference to
 `_tlsend'
 src/core/thread.d:(.text.thread_entryPoint+0x6a): undefined reference to
 `_tlsstart'
 collect2: ld returned 1 exit status
 --- errorlevel 1


This looks like what happens if you try to use the latest dmd release with an old version of Phobos, perhaps installed along with gdc. Whoever's doing the .deb packaging really should add a versioned Depends: field to debian/control so that it will require installation of the correct version of Phobos, or, at the very least, refuse to install if such is not available.

The thing about the DMD packages for Debian/Ubuntu is that they install DMD, Phobos/druntime, all D headers, and tools like rdmd and dman in one package.
 [...]
 I really don't know what to tell you, because:

 $ dmd -m32 test.d
 $ dmd -m64 test.d
 $ cat test.d
 import std.stdio;

 void main()
 {
      writeln("Hello, world!");
 }

 It Works For Me (TM).

 What package (URL please) did you install?

Yeah, if it's an outdated package, then it's kinda moot. (Though we really should remove outdated packages where we can, they can kinda become a fly in the soup sometimes.) T

-- Alex Rnne Petersen alex lycus.org http://lycus.org
Oct 14 2012
prev sibling parent Don Clugston <dac nospam.com> writes:
On 15/10/12 06:42, Jonathan M Davis wrote:
 On Sunday, October 14, 2012 21:39:42 H. S. Teoh wrote:
 This looks like what happens if you try to use the latest dmd release
 with an old version of Phobos, perhaps installed along with gdc.

 Whoever's doing the .deb packaging really should add a versioned
 Depends: field to debian/control so that it will require installation of
 the correct version of Phobos, or, at the very least, refuse to install
 if such is not available.

At this point, it's a bad idea to use any version of druntime or Phobos which doesn't match exactly with the version of dmd that you're using. It's not as bad as it used to be, but there are still plenty of cases where a language change (be it a bug fix or added feature or whatever) makes it so that older versions of Phobos won't compile, or the latest Phobos ends up needing the latest dmd. I wouldn't advise anyone to use versions of them that don't all match. - Jonathan M Davis

I think we should have a version number in druntime which is checked by the compiler, and bumped every time an incompatible change is made. That way we could reduce the number of messages from frustrated and bewildered users.
Oct 15 2012
prev sibling next sibling parent "Gerry Weaver" <gerryw compvia.com> writes:
On Monday, 15 October 2012 at 04:20:04 UTC, Alex Rønne Petersen 
wrote:
 On 15-10-2012 05:10, Gerry Weaver wrote:
 Hello All,

 I have been looking at D off and on for several years. 
 Initially I
 worked through a very painful experience to get D compiling on 
 Linux.
 After that experience, I concluded that I should wait for it 
 to become
 more mature. Since then, I do a very simple test. I install 
 the latest
 package and try to build "Hello World". I figure that if 
 "Hello World"
 builds successfully, I will continue further. I have just 
 downloaded the
 latest .deb package and installed it on Ubuntu 12.04 32bit. 
 Once again
 it fails this incredibly simple test. I've read many 
 discussions about
 how/why, has/hasn't, will/won't D hit the mainstream in 
 programming
 languages. I think this situation may offer at least one data 
 point. I'm
 struggling to think of any other language (and I use several) 
 that won't
 build code out of the box. D seems to have a lot of potential, 
 but this
 needs to be fixed. I am not asking for help on this. I 
 honestly don't
 care what the solution is. I just wanted the D developers to 
 know why at
 least one developer is not using the language. I sincerely 
 hope that the
 situation will improve. I'm looking forward to programming in 
 D.

 Thanks for your time,
 -G



 Here is the code:

 import std.stdio;


 void main()
 {
   writeln("Hello, world!");
 }

 Here is the command:

 dmd hello.d

 Here is the output:

 /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'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_18f_1b8.o): In 
 function
 `_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x1d):
 undefined reference to `_tlsend'
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x24):
 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_19f_6e4.o): In 
 function
 `thread_attachThis':
 src/core/thread.d:(.text.thread_attachThis+0xb7): undefined 
 reference to
 `_tlsstart'
 src/core/thread.d:(.text.thread_attachThis+0xbc): undefined 
 reference to
 `_tlsend'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17d_1b8.o): In 
 function
 `_D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread':
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x1d):
 undefined reference to `_tlsend'
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x27):
 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17e_1b8.o): In 
 function
 `_D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread':
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x1d):
 undefined reference to `_tlsend'
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x27):
 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(deh2_43b_525.o): In 
 function
 `_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x4):
 undefined reference to `_deh_beg'
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0xc):
 undefined reference to `_deh_beg'
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x13):
 undefined reference to `_deh_end'
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x36):
 undefined reference to `_deh_end'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17a_713.o): In 
 function
 `thread_entryPoint':
 src/core/thread.d:(.text.thread_entryPoint+0x64): undefined 
 reference to
 `_tlsend'
 src/core/thread.d:(.text.thread_entryPoint+0x6a): undefined 
 reference to
 `_tlsstart'
 collect2: ld returned 1 exit status
 --- errorlevel 1

I really don't know what to tell you, because: $ dmd -m32 test.d $ dmd -m64 test.d $ cat test.d import std.stdio; void main() { writeln("Hello, world!"); } It Works For Me (TM). What package (URL please) did you install?

Hi, I downloaded the package from dlang.org. The package was dmd_2.060-0_i386.deb. The install went fine. I have to admit that I was surprised there were issues this time around. Thanks, -G
Oct 14 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Oct 15, 2012 at 06:20:03AM +0200, Alex Rnne Petersen wrote:
 On 15-10-2012 05:10, Gerry Weaver wrote:

dmd hello.d

Here is the output:

/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'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_18f_1b8.o): In function
`_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x24):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_19f_6e4.o): In function
`thread_attachThis':
src/core/thread.d:(.text.thread_attachThis+0xb7): undefined reference to
`_tlsstart'
src/core/thread.d:(.text.thread_attachThis+0xbc): undefined reference to
`_tlsend'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17d_1b8.o): In function
`_D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x27):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17e_1b8.o): In function
`_D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x27):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(deh2_43b_525.o): In function
`_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x4):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0xc):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x13):
undefined reference to `_deh_end'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x36):
undefined reference to `_deh_end'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17a_713.o): In function
`thread_entryPoint':
src/core/thread.d:(.text.thread_entryPoint+0x64): undefined reference to
`_tlsend'
src/core/thread.d:(.text.thread_entryPoint+0x6a): undefined reference to
`_tlsstart'
collect2: ld returned 1 exit status
--- errorlevel 1


This looks like what happens if you try to use the latest dmd release with an old version of Phobos, perhaps installed along with gdc. Whoever's doing the .deb packaging really should add a versioned Depends: field to debian/control so that it will require installation of the correct version of Phobos, or, at the very least, refuse to install if such is not available. [...]
 I really don't know what to tell you, because:
 
 $ dmd -m32 test.d
 $ dmd -m64 test.d
 $ cat test.d
 import std.stdio;
 
 void main()
 {
     writeln("Hello, world!");
 }
 
 It Works For Me (TM).
 
 What package (URL please) did you install?

Yeah, if it's an outdated package, then it's kinda moot. (Though we really should remove outdated packages where we can, they can kinda become a fly in the soup sometimes.) T -- Tell me and I forget. Teach me and I remember. Involve me and I understand. -- Benjamin Franklin
Oct 14 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, October 14, 2012 21:39:42 H. S. Teoh wrote:
 This looks like what happens if you try to use the latest dmd release
 with an old version of Phobos, perhaps installed along with gdc.
 
 Whoever's doing the .deb packaging really should add a versioned
 Depends: field to debian/control so that it will require installation of
 the correct version of Phobos, or, at the very least, refuse to install
 if such is not available.

At this point, it's a bad idea to use any version of druntime or Phobos which doesn't match exactly with the version of dmd that you're using. It's not as bad as it used to be, but there are still plenty of cases where a language change (be it a bug fix or added feature or whatever) makes it so that older versions of Phobos won't compile, or the latest Phobos ends up needing the latest dmd. I wouldn't advise anyone to use versions of them that don't all match. - Jonathan M Davis
Oct 14 2012
prev sibling next sibling parent "Gerry Weaver" <gerryw compvia.com> writes:
On Monday, 15 October 2012 at 04:34:10 UTC, Alex Rønne Petersen 
wrote:
 On 15-10-2012 06:31, Gerry Weaver wrote:
 On Monday, 15 October 2012 at 04:20:04 UTC, Alex Rønne 
 Petersen wrote:
 On 15-10-2012 05:10, Gerry Weaver wrote:
 Hello All,

 I have been looking at D off and on for several years. 
 Initially I
 worked through a very painful experience to get D compiling 
 on Linux.
 After that experience, I concluded that I should wait for it 
 to become
 more mature. Since then, I do a very simple test. I install 
 the latest
 package and try to build "Hello World". I figure that if 
 "Hello World"
 builds successfully, I will continue further. I have just 
 downloaded the
 latest .deb package and installed it on Ubuntu 12.04 32bit. 
 Once again
 it fails this incredibly simple test. I've read many 
 discussions about
 how/why, has/hasn't, will/won't D hit the mainstream in 
 programming
 languages. I think this situation may offer at least one 
 data point. I'm
 struggling to think of any other language (and I use 
 several) that won't
 build code out of the box. D seems to have a lot of 
 potential, but this
 needs to be fixed. I am not asking for help on this. I 
 honestly don't
 care what the solution is. I just wanted the D developers to 
 know why at
 least one developer is not using the language. I sincerely 
 hope that the
 situation will improve. I'm looking forward to programming 
 in D.

 Thanks for your time,
 -G



 Here is the code:

 import std.stdio;


 void main()
 {
  writeln("Hello, world!");
 }

 Here is the command:

 dmd hello.d

 Here is the output:

 /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'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_18f_1b8.o): In 
 function
 `_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x1d):

 undefined reference to `_tlsend'
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x24):

 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_19f_6e4.o): In 
 function
 `thread_attachThis':
 src/core/thread.d:(.text.thread_attachThis+0xb7): undefined 
 reference to
 `_tlsstart'
 src/core/thread.d:(.text.thread_attachThis+0xbc): undefined 
 reference to
 `_tlsend'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17d_1b8.o): In 
 function
 `_D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread':
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x1d):

 undefined reference to `_tlsend'
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x27):

 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17e_1b8.o): In 
 function
 `_D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread':
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x1d):

 undefined reference to `_tlsend'
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x27):

 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(deh2_43b_525.o): In 
 function
 `_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x4):

 undefined reference to `_deh_beg'
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0xc):

 undefined reference to `_deh_beg'
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x13):

 undefined reference to `_deh_end'
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x36):

 undefined reference to `_deh_end'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17a_713.o): In 
 function
 `thread_entryPoint':
 src/core/thread.d:(.text.thread_entryPoint+0x64): undefined 
 reference to
 `_tlsend'
 src/core/thread.d:(.text.thread_entryPoint+0x6a): undefined 
 reference to
 `_tlsstart'
 collect2: ld returned 1 exit status
 --- errorlevel 1

I really don't know what to tell you, because: $ dmd -m32 test.d $ dmd -m64 test.d $ cat test.d import std.stdio; void main() { writeln("Hello, world!"); } It Works For Me (TM). What package (URL please) did you install?

Hi, I downloaded the package from dlang.org. The package was dmd_2.060-0_i386.deb. The install went fine. I have to admit that I was surprised there were issues this time around. Thanks, -G

Would you happen to have an i386 Ubuntu system I could SSH into and have a look or something? I'm on amd64 over here which works OK with the amd64 package on dlang.org. I suspect we generally have a relatively low 32-bit Linux user base these days...

Hi, Unfortunately, I don't. This is a special dev system I setup for a customer project. They have several 32bit only apps that force the 32bit requirement. Actually, I would be using D on 64bit anyway. I just happened to be working on this particular system when I decided to check out the latest D package. I will try the 64bit package. In the mean time, I would be more than happy to gather any information that would help. Thanks, -G
Oct 14 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Oct 15, 2012 at 06:45:16AM +0200, Gerry Weaver wrote:
[...]
 Unfortunately, I don't. This is a special dev system I setup for a
 customer project. They have several 32bit only apps that force the
 32bit requirement. Actually, I would be using D on 64bit anyway. I
 just happened to be working on this particular system when I decided
 to check out the latest D package. I will try the 64bit package. In
 the mean time, I would be more than happy to gather any information
 that would help.

Hmm. I just tested it on a 32-bit Debian system, using the package from the exact URL you gave, and I didn't see any problems. So I'm wondering if somehow dmd is picking up the wrong version of Phobos somehow, maybe a stale copy somewhere? Maybe a stale /etc/dmd.conf that pointed to the wrong version of the library? (Debian/Ubuntu packages generally do not overwrite modified configuration files upon installation -- so if there is an old dmd.conf there that has been modified in the past, it will have stayed unchanged when you installed the new dmd. Check if there's a file called /etc/dmd.conf.dpkg-new; if there is, rename it to /etc/dmd.conf and see if that fixes the problem.) T -- The richest man is not he who has the most, but he who needs the least.
Oct 14 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Oct 14, 2012 at 09:42:56PM -0700, Jonathan M Davis wrote:
 On Sunday, October 14, 2012 21:39:42 H. S. Teoh wrote:
 This looks like what happens if you try to use the latest dmd
 release with an old version of Phobos, perhaps installed along with
 gdc.
 
 Whoever's doing the .deb packaging really should add a versioned
 Depends: field to debian/control so that it will require
 installation of the correct version of Phobos, or, at the very
 least, refuse to install if such is not available.

At this point, it's a bad idea to use any version of druntime or Phobos which doesn't match exactly with the version of dmd that you're using. It's not as bad as it used to be, but there are still plenty of cases where a language change (be it a bug fix or added feature or whatever) makes it so that older versions of Phobos won't compile, or the latest Phobos ends up needing the latest dmd. I wouldn't advise anyone to use versions of them that don't all match.

Hmm, I just checked the URL he gave, and the package there includes the entire suite: dmd, druntime, phobos, all in one. The only potential problem I can think of is that /etc/dmd.conf had been modified in the past and the Debian/Ubuntu packaging system doesn't overwrite modified conffiles upon upgrade, so dmd may be picking up the wrong version of druntime/Phobos because of that. Another potential problem I can think of, is that the package is missing a Depends: on one of the system libraries, maybe pthread-related, judging from the error messages? Specifically, one needs to depend on the -dev version of the library, as non-dev versions of Debian/Ubuntu library packages may only contain .so files, not the other stuff (headers, .a's, etc.) that may be necessary to link to the library. One way to root out this problem is to create a bare-bones chroot environment (cf. dbootstrap) that has the absolute minimum packages installed, and see if the package installs and runs correctly there. Quite often, dependencies are missed because the library depended on is commonly installed on most systems, but isn't part of the base system, so on rare occasions the library will be missing and the package will install correctly but fail to work. T -- Don't modify spaghetti code unless you can eat the consequences.
Oct 14 2012
prev sibling next sibling parent "Gerry Weaver" <gerryw compvia.com> writes:
On Monday, 15 October 2012 at 05:05:17 UTC, H. S. Teoh wrote:
 On Mon, Oct 15, 2012 at 06:45:16AM +0200, Gerry Weaver wrote:
 [...]
 Unfortunately, I don't. This is a special dev system I setup 
 for a
 customer project. They have several 32bit only apps that force 
 the
 32bit requirement. Actually, I would be using D on 64bit 
 anyway. I
 just happened to be working on this particular system when I 
 decided
 to check out the latest D package. I will try the 64bit 
 package. In
 the mean time, I would be more than happy to gather any 
 information
 that would help.

Hmm. I just tested it on a 32-bit Debian system, using the package from the exact URL you gave, and I didn't see any problems. So I'm wondering if somehow dmd is picking up the wrong version of Phobos somehow, maybe a stale copy somewhere? Maybe a stale /etc/dmd.conf that pointed to the wrong version of the library? (Debian/Ubuntu packages generally do not overwrite modified configuration files upon installation -- so if there is an old dmd.conf there that has been modified in the past, it will have stayed unchanged when you installed the new dmd. Check if there's a file called /etc/dmd.conf.dpkg-new; if there is, rename it to /etc/dmd.conf and see if that fixes the problem.) T

Hi, I checked it out. There is only a dmd.conf. I've included it below. ; ; dmd.conf file for dmd ; ; dmd will look for dmd.conf in the following sequence of directories: ; - current working directory ; - directory specified by the HOME environment variable ; - directory dmd resides in ; - /etc directory ; ; Names enclosed by %% are searched for in the existing environment and inserted ; ; The special name % P% is replaced with the path to this file ; [Environment] DFLAGS=-I/usr/include/dmd/phobos -I/usr/include/dmd/druntime/import -L-L/usr/lib /i386-linux-gnu -L-L/usr/lib/x86_64-linux-gnu -L--no-warn-search-mismatch -L--ex port-dynamic Thanks, -G
Oct 14 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Oct 15, 2012 at 07:14:42AM +0200, Gerry Weaver wrote:
[...]
 Hi,
 
 I checked it out. There is only a dmd.conf. I've included it below.

Strange, I have exactly the same copy of dmd.conf, and I didn't see a problem. I copy-n-pasted your code into the same filename, etc.. What version of libc6 do you have? (dpkg -p libc6) Maybe dmd is incompatible with older versions of libc6? T -- If creativity is stifled by rigid discipline, then it is not true creativity.
Oct 14 2012
prev sibling next sibling parent "Gerry Weaver" <gerryw compvia.com> writes:
On Monday, 15 October 2012 at 05:27:14 UTC, H. S. Teoh wrote:
 On Mon, Oct 15, 2012 at 07:14:42AM +0200, Gerry Weaver wrote:
 [...]
 Hi,
 
 I checked it out. There is only a dmd.conf. I've included it 
 below.

Strange, I have exactly the same copy of dmd.conf, and I didn't see a problem. I copy-n-pasted your code into the same filename, etc.. What version of libc6 do you have? (dpkg -p libc6) Maybe dmd is incompatible with older versions of libc6? T

Hi, Here's what I've got. Package: libc6 Multi-Arch: same Priority: required Section: libs Installed-Size: 9125 Maintainer: Ubuntu Developers <ubuntu-devel-discuss lists.ubuntu.com> Architecture: i386 Source: eglibc Version: 2.15-0ubuntu10.2 Replaces: belocs-locales-bin, libc6-i386 Provides: glibc-2.13-1, libc6-i686 Depends: libc-bin (= 2.15-0ubuntu10.2), libgcc1, tzdata Suggests: glibc-doc, debconf | debconf-2.0, locales Breaks: libhwloc0, liblouis0 (<< 2.3.0-2), liblouisxml1 (<< 2.4.0-2), nscd (<< 2.15) Conflicts: belocs-locales-bin, libc6-i686, prelink (<< 0.0.20090925), tzdata (<< 2007k-1), tzdata-etch Filename: pool/main/e/eglibc/libc6_2.15-0ubuntu10_i386.deb Size: 3934936 MD5sum: 941333dcbfcc262636b89e6e387ebe18 Description: Embedded GNU C Library: Shared libraries Contains the standard libraries that are used by nearly all programs on the system. This package includes shared versions of the standard C library and the standard math library, as well as many others. Homepage: http://www.eglibc.org Original-Maintainer: GNU Libc Maintainers <debian-glibc lists.debian.org> Thanks, -G
Oct 14 2012
prev sibling next sibling parent "Gerry Weaver" <gerryw compvia.com> writes:
On Monday, 15 October 2012 at 05:27:14 UTC, H. S. Teoh wrote:
 On Mon, Oct 15, 2012 at 07:14:42AM +0200, Gerry Weaver wrote:
 [...]
 Hi,
 
 I checked it out. There is only a dmd.conf. I've included it 
 below.

Strange, I have exactly the same copy of dmd.conf, and I didn't see a problem. I copy-n-pasted your code into the same filename, etc.. What version of libc6 do you have? (dpkg -p libc6) Maybe dmd is incompatible with older versions of libc6? T

Hi, I was wondering why D doesn't just install everthing in one directory (ie; /opt/dlang) and look at an environment variable (ie; DLANG_ROOT) to source everything. It seems like it would make things a lot simpler. Then the package could be located anywhere and multiple versions could be used safely. Quite a few other languages have used this approach successfully. Anyway, just a thought. Thanks, -G
Oct 14 2012
prev sibling next sibling parent "Gerry Weaver" <gerryw compvia.com> writes:
On Monday, 15 October 2012 at 05:27:14 UTC, H. S. Teoh wrote:
 On Mon, Oct 15, 2012 at 07:14:42AM +0200, Gerry Weaver wrote:
 [...]
 Hi,
 
 I checked it out. There is only a dmd.conf. I've included it 
 below.

Strange, I have exactly the same copy of dmd.conf, and I didn't see a problem. I copy-n-pasted your code into the same filename, etc.. What version of libc6 do you have? (dpkg -p libc6) Maybe dmd is incompatible with older versions of libc6? T

Hi, I was wondering why D doesn't just install everthing in one directory (ie; /opt/dlang) and look at an environment variable (ie; DLANG_ROOT) to source everything. It seems like it would make things a lot simpler. Then the package could be located anywhere and multiple versions could be used safely. Quite a few other languages have used this approach successfully. Anyway, just a thought. Thanks, -G
Oct 14 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Oct 15, 2012 at 08:09:54AM +0200, Gerry Weaver wrote:
 On Monday, 15 October 2012 at 05:27:14 UTC, H. S. Teoh wrote:
On Mon, Oct 15, 2012 at 07:14:42AM +0200, Gerry Weaver wrote:
[...]
Hi,

I checked it out. There is only a dmd.conf. I've included it below.

Strange, I have exactly the same copy of dmd.conf, and I didn't see a problem. I copy-n-pasted your code into the same filename, etc.. What version of libc6 do you have? (dpkg -p libc6) Maybe dmd is incompatible with older versions of libc6?


Hmm, apparently you have a *newer* version of libc6 than I do. Apparently Debian doesn't have 2.15 yet, so I don't have an easy way to test this further.
 Hi,
 
 I was wondering why D doesn't just install everthing in one directory
 (ie; /opt/dlang) and look at an environment variable (ie; DLANG_ROOT)
 to source everything. It seems like it would make things a lot
 simpler. Then the package could be located anywhere and multiple
 versions could be used safely. Quite a few other languages have used
 this approach successfully. Anyway, just a thought.

I believe the .deb package is simply following Debian/Ubuntu conventions by putting things in /usr/bin, /usr/lib, /usr/include, etc.. IIRC, /opt is intended for manually-installed software (at least, that's what the docs say). One improvement that *could* be made, though, is to put things in /usr/include/d/${version}/*, so that specific versions of dmd can find the right versions of stuff. This was discussed recently, but I don't remember if a decision was reached. In any case, I haven't been able to reproduce the problem you're seeing. I tried installing the package multiple times, upgrading the system libraries, etc., and everything still works for me, so I'm not sure what else to say. Seems like there must be some specific combination of libraries, system or otherwise, that makes dmd not work. Without being able to examine your environment, it's really hard to tell. T -- Without geometry, life would be pointless. -- VS
Oct 14 2012
prev sibling next sibling parent "Gerry Weaver" <gerryw compvia.com> writes:
On Monday, 15 October 2012 at 06:20:52 UTC, Ali Çehreli wrote:
 On 10/14/2012 11:09 PM, Gerry Weaver wrote:

 I was wondering why D doesn't just install everthing in one

 (ie; /opt/dlang)

The .zip version works that way. (At least it used to.) Just unzip in any directory: http://dlang.org/download.html
 and look at an environment variable (ie; DLANG_ROOT) to
 source everything.

You don't even need to do that. The binary detects where it is started from and finds the modules and libraries relative to its path. Ali

Hi, I removed the dmd package and downloaded the .zip. I checked for any files that were left behind when the package was removed and they are gone. I then ran dmd from the zip package, but I get the same result. It would seem that dmd does not work on this particular distribution. Thanks, -G Thanks, -G
Oct 14 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Oct 14, 2012 at 11:32:30PM -0700, H. S. Teoh wrote:
[...]
 In any case, I haven't been able to reproduce the problem you're seeing.
 I tried installing the package multiple times, upgrading the system
 libraries, etc., and everything still works for me, so I'm not sure what
 else to say. Seems like there must be some specific combination of
 libraries, system or otherwise, that makes dmd not work. Without being
 able to examine your environment, it's really hard to tell.

Funny, as soon as I said that, I manage to reproduce the same error messages (though I can't say if it's exactly the problem you're seeing) by compiling a file that doesn't define main(). In this case, I had a hello.d with main() renamed to Main(): import std.stdio; void Main() { writeln("haha"); } Running `dmd hello.d` produced a whole bunch of errors almost exactly the same as what you're seeing. Of course, I'm not sure this is exactly the problem you have, as your code does have a correctly-spelled main() (from what I can tell). But this may help find where the problem is. On that note, here's an enhancement request for dmd: if a program is missing main() for whatever reason, we really should have a more user-friendly error message than the reams of encrypted Klingon from the linker that almost nobody understands. T -- Only boring people get bored. -- JM
Oct 14 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, October 14, 2012 23:40:41 H. S. Teoh wrote:
 Funny, as soon as I said that, I manage to reproduce the same error
 messages (though I can't say if it's exactly the problem you're seeing)
 by compiling a file that doesn't define main(). In this case, I had a
 hello.d with main() renamed to Main():

Yes. The error message that he's getting is essentially the one that you get when you don't define main, which is weird, because he _is_ defining main. But I don't know if it's exactly the same or not. A detailed comparison of the error messages that he's seeing and those that you get from not defining main on a machine that works would be required to see whether it's exactly the same message or not. I'm surprised that you didn't recognize the errors immediately. I guess that you haven't missed main very often (I'm used to it primarily from forgetting main when throwing together quick test scripts). But I'm totally stumped as to why he'd be getting them, since he does appear to be declaring main correctly. - Jonathan M Davis
Oct 14 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 15/10/2012 09:08, Gerry Weaver a écrit :
 On Monday, 15 October 2012 at 06:47:06 UTC, Jonathan M Davis wrote:
 On Sunday, October 14, 2012 23:40:41 H. S. Teoh wrote:
 Funny, as soon as I said that, I manage to reproduce the same error
 messages (though I can't say if it's exactly the problem you're seeing)
 by compiling a file that doesn't define main(). In this case, I had a
 hello.d with main() renamed to Main():

Yes. The error message that he's getting is essentially the one that you get when you don't define main, which is weird, because he _is_ defining main. But I don't know if it's exactly the same or not. A detailed comparison of the error messages that he's seeing and those that you get from not defining main on a machine that works would be required to see whether it's exactly the same message or not. I'm surprised that you didn't recognize the errors immediately. I guess that you haven't missed main very often (I'm used to it primarily from forgetting main when throwing together quick test scripts). But I'm totally stumped as to why he'd be getting them, since he does appear to be declaring main correctly. - Jonathan M Davis

Hi, I decided to install the same distribution in a vm. This time instead of installing the .deb package, I went with the zip. Everything seems to be working! I can compile a non-trivial example just fine. I guess I'll definitely be using the zip from now on. Anyway, I also tried the zip version on Mac and Windoze. They both built the same code successfully. This is great! I can finally try out all of those great language features I've been reading about. Thanks to everyone for pushing me down the rabbit hole far enough this time to get some payback ;-) It's on now! Thanks, -G

I would definitively encourage you to try the .deb on a clean install. I'm pretty sure your old install is confused by old half installed D stuffs.
Oct 15 2012
prev sibling next sibling parent "Gerry Weaver" <gerryw compvia.com> writes:
On Monday, 15 October 2012 at 06:47:06 UTC, Jonathan M Davis 
wrote:
 On Sunday, October 14, 2012 23:40:41 H. S. Teoh wrote:
 Funny, as soon as I said that, I manage to reproduce the same 
 error
 messages (though I can't say if it's exactly the problem 
 you're seeing)
 by compiling a file that doesn't define main(). In this case, 
 I had a
 hello.d with main() renamed to Main():

Yes. The error message that he's getting is essentially the one that you get when you don't define main, which is weird, because he _is_ defining main. But I don't know if it's exactly the same or not. A detailed comparison of the error messages that he's seeing and those that you get from not defining main on a machine that works would be required to see whether it's exactly the same message or not. I'm surprised that you didn't recognize the errors immediately. I guess that you haven't missed main very often (I'm used to it primarily from forgetting main when throwing together quick test scripts). But I'm totally stumped as to why he'd be getting them, since he does appear to be declaring main correctly. - Jonathan M Davis

Hi, I decided to install the same distribution in a vm. This time instead of installing the .deb package, I went with the zip. Everything seems to be working! I can compile a non-trivial example just fine. I guess I'll definitely be using the zip from now on. Anyway, I also tried the zip version on Mac and Windoze. They both built the same code successfully. This is great! I can finally try out all of those great language features I've been reading about. Thanks to everyone for pushing me down the rabbit hole far enough this time to get some payback ;-) It's on now! Thanks, -G
Oct 15 2012
prev sibling next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 15 October 2012 04:10, Gerry Weaver <gerryw compvia.com> wrote:
 Hello All,

 I have been looking at D off and on for several years. Initially I worked
 through a very painful experience to get D compiling on Linux. After that
 experience, I concluded that I should wait for it to become more mature.
 Since then, I do a very simple test. I install the latest package and try to
 build "Hello World". I figure that if "Hello World" builds successfully, I
 will continue further. I have just downloaded the latest .deb package and
 installed it on Ubuntu 12.04 32bit. Once again it fails this incredibly
 simple test. I've read many discussions about how/why, has/hasn't,
 will/won't D hit the mainstream in programming languages. I think this
 situation may offer at least one data point. I'm struggling to think of any
 other language (and I use several) that won't build code out of the box. D
 seems to have a lot of potential, but this needs to be fixed. I am not
 asking for help on this. I honestly don't care what the solution is. I just
 wanted the D developers to know why at least one developer is not using the
 language. I sincerely hope that the situation will improve. I'm looking
 forward to programming in D.

 Thanks for your time,
 -G



 Here is the code:

 import std.stdio;


 void main()
 {
   writeln("Hello, world!");
 }

 Here is the command:

 dmd hello.d

 Here is the output:

 /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'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_18f_1b8.o): In function
 `_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x1d):
 undefined reference to `_tlsend'
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x24):
 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_19f_6e4.o): In function
 `thread_attachThis':
 src/core/thread.d:(.text.thread_attachThis+0xb7): undefined reference to
 `_tlsstart'
 src/core/thread.d:(.text.thread_attachThis+0xbc): undefined reference to
 `_tlsend'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17d_1b8.o): In function
 `_D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread':
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x1d):
 undefined reference to `_tlsend'
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x27):
 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17e_1b8.o): In function
 `_D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread':
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x1d):
 undefined reference to `_tlsend'
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x27):
 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(deh2_43b_525.o): In function
 `_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x4):
 undefined reference to `_deh_beg'
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0xc):
 undefined reference to `_deh_beg'
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x13):
 undefined reference to `_deh_end'
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x36):
 undefined reference to `_deh_end'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17a_713.o): In function
 `thread_entryPoint':
 src/core/thread.d:(.text.thread_entryPoint+0x64): undefined reference to
 `_tlsend'
 src/core/thread.d:(.text.thread_entryPoint+0x6a): undefined reference to
 `_tlsstart'
 collect2: ld returned 1 exit status
 --- errorlevel 1

Try and paste the output of the following: dmd -c hello.d objdump -d hello.o Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 15 2012
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 10/15/2012 06:22 AM, Iain Buclaw wrote:
 On 15 October 2012 08:23, Gerry Weaver<gerryw compvia.com>  wrote:

 Disassembly of section .text:

 00000000<.text>:
     0:   b8 10 00 00 00          mov    $0x10,%eax
     5:   b9 00 00 00 00          mov    $0x0,%ecx
     a:   8b 11                   mov    (%ecx),%edx
     c:   89 10                   mov    %edx,(%eax)
     e:   89 01                   mov    %eax,(%ecx)
    10:   c3                      ret


 Thanks,
 -G

That looks to me as if hello.d is an empty file.

That is the most plausible reason so far: The OP has an empty file in the current directory but the hello.d that is being edited in Emacs is elsewhere. :) Ali
Oct 15 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-10-16 00:39, Iain Buclaw wrote:

 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.

The corresponding variables have already been removed from the Mac OS X specific code and replaced with proper API calls. -- /Jacob Carlborg
Oct 15 2012
prev sibling next sibling parent "Gerry Weaver" <gerryw compvia.com> writes:
On Monday, 15 October 2012 at 07:12:03 UTC, Iain Buclaw wrote:
 On 15 October 2012 04:10, Gerry Weaver <gerryw compvia.com> 
 wrote:
 Hello All,

 I have been looking at D off and on for several years. 
 Initially I worked
 through a very painful experience to get D compiling on Linux. 
 After that
 experience, I concluded that I should wait for it to become 
 more mature.
 Since then, I do a very simple test. I install the latest 
 package and try to
 build "Hello World". I figure that if "Hello World" builds 
 successfully, I
 will continue further. I have just downloaded the latest .deb 
 package and
 installed it on Ubuntu 12.04 32bit. Once again it fails this 
 incredibly
 simple test. I've read many discussions about how/why, 
 has/hasn't,
 will/won't D hit the mainstream in programming languages. I 
 think this
 situation may offer at least one data point. I'm struggling to 
 think of any
 other language (and I use several) that won't build code out 
 of the box. D
 seems to have a lot of potential, but this needs to be fixed. 
 I am not
 asking for help on this. I honestly don't care what the 
 solution is. I just
 wanted the D developers to know why at least one developer is 
 not using the
 language. I sincerely hope that the situation will improve. 
 I'm looking
 forward to programming in D.

 Thanks for your time,
 -G



 Here is the code:

 import std.stdio;


 void main()
 {
   writeln("Hello, world!");
 }

 Here is the command:

 dmd hello.d

 Here is the output:

 /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'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_18f_1b8.o): In 
 function
 `_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x1d):
 undefined reference to `_tlsend'
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x24):
 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_19f_6e4.o): In 
 function
 `thread_attachThis':
 src/core/thread.d:(.text.thread_attachThis+0xb7): undefined 
 reference to
 `_tlsstart'
 src/core/thread.d:(.text.thread_attachThis+0xbc): undefined 
 reference to
 `_tlsend'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17d_1b8.o): In 
 function
 `_D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread':
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x1d):
 undefined reference to `_tlsend'
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x27):
 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17e_1b8.o): In 
 function
 `_D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread':
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x1d):
 undefined reference to `_tlsend'
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x27):
 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(deh2_43b_525.o): In 
 function
 `_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x4):
 undefined reference to `_deh_beg'
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0xc):
 undefined reference to `_deh_beg'
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x13):
 undefined reference to `_deh_end'
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x36):
 undefined reference to `_deh_end'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17a_713.o): In 
 function
 `thread_entryPoint':
 src/core/thread.d:(.text.thread_entryPoint+0x64): undefined 
 reference to
 `_tlsend'
 src/core/thread.d:(.text.thread_entryPoint+0x6a): undefined 
 reference to
 `_tlsstart'
 collect2: ld returned 1 exit status
 --- errorlevel 1

Try and paste the output of the following: dmd -c hello.d objdump -d hello.o Regards

Hi, Here you go. hello.o: file format elf32-i386 Disassembly of section .text: 00000000 <.text>: 0: b8 10 00 00 00 mov $0x10,%eax 5: b9 00 00 00 00 mov $0x0,%ecx a: 8b 11 mov (%ecx),%edx c: 89 10 mov %edx,(%eax) e: 89 01 mov %eax,(%ecx) 10: c3 ret Thanks, -G
Oct 15 2012
prev sibling next sibling parent "Gerry Weaver" <gerryw compvia.com> writes:
On Monday, 15 October 2012 at 07:12:03 UTC, Iain Buclaw wrote:
 On 15 October 2012 04:10, Gerry Weaver <gerryw compvia.com> 
 wrote:
 Hello All,

 I have been looking at D off and on for several years. 
 Initially I worked
 through a very painful experience to get D compiling on Linux. 
 After that
 experience, I concluded that I should wait for it to become 
 more mature.
 Since then, I do a very simple test. I install the latest 
 package and try to
 build "Hello World". I figure that if "Hello World" builds 
 successfully, I
 will continue further. I have just downloaded the latest .deb 
 package and
 installed it on Ubuntu 12.04 32bit. Once again it fails this 
 incredibly
 simple test. I've read many discussions about how/why, 
 has/hasn't,
 will/won't D hit the mainstream in programming languages. I 
 think this
 situation may offer at least one data point. I'm struggling to 
 think of any
 other language (and I use several) that won't build code out 
 of the box. D
 seems to have a lot of potential, but this needs to be fixed. 
 I am not
 asking for help on this. I honestly don't care what the 
 solution is. I just
 wanted the D developers to know why at least one developer is 
 not using the
 language. I sincerely hope that the situation will improve. 
 I'm looking
 forward to programming in D.

 Thanks for your time,
 -G



 Here is the code:

 import std.stdio;


 void main()
 {
   writeln("Hello, world!");
 }

 Here is the command:

 dmd hello.d

 Here is the output:

 /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'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_18f_1b8.o): In 
 function
 `_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x1d):
 undefined reference to `_tlsend'
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x24):
 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_19f_6e4.o): In 
 function
 `thread_attachThis':
 src/core/thread.d:(.text.thread_attachThis+0xb7): undefined 
 reference to
 `_tlsstart'
 src/core/thread.d:(.text.thread_attachThis+0xbc): undefined 
 reference to
 `_tlsend'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17d_1b8.o): In 
 function
 `_D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread':
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x1d):
 undefined reference to `_tlsend'
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x27):
 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17e_1b8.o): In 
 function
 `_D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread':
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x1d):
 undefined reference to `_tlsend'
 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x27):
 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(deh2_43b_525.o): In 
 function
 `_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x4):
 undefined reference to `_deh_beg'
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0xc):
 undefined reference to `_deh_beg'
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x13):
 undefined reference to `_deh_end'
 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x36):
 undefined reference to `_deh_end'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17a_713.o): In 
 function
 `thread_entryPoint':
 src/core/thread.d:(.text.thread_entryPoint+0x64): undefined 
 reference to
 `_tlsend'
 src/core/thread.d:(.text.thread_entryPoint+0x6a): undefined 
 reference to
 `_tlsstart'
 collect2: ld returned 1 exit status
 --- errorlevel 1

Try and paste the output of the following: dmd -c hello.d objdump -d hello.o Regards

Hi, Here you go. hello.o: file format elf32-i386 Disassembly of section .text: 00000000 <.text>: 0: b8 10 00 00 00 mov $0x10,%eax 5: b9 00 00 00 00 mov $0x0,%ecx a: 8b 11 mov (%ecx),%edx c: 89 10 mov %edx,(%eax) e: 89 01 mov %eax,(%ecx) 10: c3 ret Thanks, -G
Oct 15 2012
prev sibling next sibling parent "Aziz K." <aziz.koeksal gmail.com> writes:
On Mon, 15 Oct 2012 08:36:22 +0200, Gerry Weaver <gerryw compvia.com>  
wrote:

 Hi,

 I removed the dmd package and downloaded the .zip. I checked for any  
 files that were left behind when the package was removed and they are  
 gone. I then ran dmd from the zip package, but I get the same result. It  
 would seem that dmd does not work on this particular distribution.

Maybe you still have an old dmd.conf at $HOME or somewhere else? It could be that it overrides the dmd.conf in the zip/deb file. What do you get when you run $ locate dmd.conf?
Oct 15 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-15 05:10, Gerry Weaver wrote:
 Hello All,

 I have been looking at D off and on for several years. Initially I
 worked through a very painful experience to get D compiling on Linux.
 After that experience, I concluded that I should wait for it to become
 more mature. Since then, I do a very simple test. I install the latest
 package and try to build "Hello World". I figure that if "Hello World"
 builds successfully, I will continue further. I have just downloaded the
 latest .deb package and installed it on Ubuntu 12.04 32bit. Once again
 it fails this incredibly simple test. I've read many discussions about
 how/why, has/hasn't, will/won't D hit the mainstream in programming
 languages. I think this situation may offer at least one data point. I'm
 struggling to think of any other language (and I use several) that won't
 build code out of the box. D seems to have a lot of potential, but this
 needs to be fixed. I am not asking for help on this. I honestly don't
 care what the solution is. I just wanted the D developers to know why at
 least one developer is not using the language. I sincerely hope that the
 situation will improve. I'm looking forward to programming in D.

Just use DVM, it's also cross-platform: https://bitbucket.org/doob/dvm -- /Jacob Carlborg
Oct 15 2012
parent reply Don Clugston <dac nospam.com> writes:
On 15/10/12 11:14, Jacob Carlborg wrote:
 Just use DVM, it's also cross-platform:

 https://bitbucket.org/doob/dvm

I tried that on both Windows and Ubuntu, and couldn't get it to work on either of them. I posted a couple of bug reports eight months ago, and they still haven't been fixed. Not recommended for anyone who is having problems with their installation.
Oct 15 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-15 11:58, Don Clugston wrote:

 I tried that on both Windows and Ubuntu, and couldn't get it to work on
 either of them. I posted a couple of bug reports eight months ago, and
 they still haven't been fixed. Not recommended for anyone who is having
 problems with their installation.

I know it's not a perfect tool and it contains bugs but most things do work. I don't know which issues have been reported by you, but it seems there's a problem with the "-l" flag. Running "dvm install 2.060" usually works. Could you please point out which issues have been reported by you. I have very limited time to work with D, as I understand most people here has, and I'm currently working on other projects than DVM since basically does what I intended it to do when I started the project. It seems most D installers are broken in one way or another. But the success rate with DVM seems to be quite high anyway. -- /Jacob Carlborg
Oct 15 2012
parent reply Don Clugston <dac nospam.com> writes:
On 15/10/12 13:39, Jacob Carlborg wrote:
 On 2012-10-15 11:58, Don Clugston wrote:

 I tried that on both Windows and Ubuntu, and couldn't get it to work on
 either of them. I posted a couple of bug reports eight months ago, and
 they still haven't been fixed. Not recommended for anyone who is having
 problems with their installation.

I know it's not a perfect tool and it contains bugs but most things do work. I don't know which issues have been reported by you, but it seems there's a problem with the "-l" flag. Running "dvm install 2.060" usually works. Could you please point out which issues have been reported by you.

I don't remember, it's a long time ago. But this was one of them: https://github.com/jacob-carlborg/dvm/issues/11 Basically it was case of: download, find a bug, find another bug, think "this has already cost me more time than it could ever save me", quit now.
 I have very limited time to work with D, as I understand most people
 here has, and I'm currently working on other projects than DVM since
 basically does what I intended it to do when I started the project.

 It seems most D installers are broken in one way or another. But the
 success rate with DVM seems to be quite high anyway.

Oct 22 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-10-22 17:33, Don Clugston wrote:

 I don't remember, it's a long time ago. But this was one of them:
 https://github.com/jacob-carlborg/dvm/issues/11

 Basically it was case of: download, find a bug, find another bug,
 think "this has already cost me more time than it could ever save me",
 quit now.

I'll see if I can create a bug fix release. -- /Jacob Carlborg
Oct 22 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-16 01:54, 1100110 wrote:

 Doesn't work on Arch 64bit either.  I tried to fix it at one point and
 gave it up...

Please report the issue so it's not forgotten. You don't need to have fix or a pull request, just information how I should reproduce it. https://bitbucket.org/doob/dvm -- /Jacob Carlborg
Oct 15 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-16 09:04, 1100110 wrote:

 OK. Install dvm using directions on bitbucket.

 dvm install -l
 (no output)
 dvm list
 No installed D compilers

 Thats it.  No errors, I'll make a issue in a bit.

The -l flag seems to be horrible broken. Can you try "dvm install 2.060". -- /Jacob Carlborg
Oct 16 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-10-19 09:05, Marco Leise wrote:

 Ok now that everyone is bashing I can jump in, too. I tried a
 few commands and they all failed with bugs already listed in
 the bug tracker. no kidding. :D

 --- "dvm list": An unknown error occurred:
 tango.core.Exception.VfsException: FileFolder.open :: path does not exist:
/home/marco/.dvm/compilers

 --- "dvm -l install":
 zsh: segmentation fault  ./dvm-0.4.0-linux-64 -l install

 --- "dvm install dmd-2.060":
 Fetching: http://ftp.digitalmars.com/dmd.dmd-2.060.zip
 An unknown error occurred:
 tango.core.Exception.IOException: The resource with URL
"http://ftp.digitalmars.com/dmd.dmd-2.060.zip" could not be found.

 --- "dvm install 2.060":
 Fetching: http://ftp.digitalmars.com/dmd.2.060.zip
 [========================================>] 26846/26191 KB

 Installing: dmd-2.060
 An unknown error occurred:
 tango.core.Exception.IOException: /home/marco/.dvm/bin/dmd-2.060 :: No such
file or directory

 At this point I stopped, because I was too scared.

Thanks for reporting this. -- /Jacob Carlborg
Oct 20 2012
prev sibling next sibling parent "jerro" <a a.com> writes:
On Monday, 15 October 2012 at 05:27:14 UTC, H. S. Teoh wrote:
 On Mon, Oct 15, 2012 at 07:14:42AM +0200, Gerry Weaver wrote:
 [...]
 Hi,
 
 I checked it out. There is only a dmd.conf. I've included it 
 below.

Strange, I have exactly the same copy of dmd.conf, and I didn't see a problem. I copy-n-pasted your code into the same filename, etc.. What version of libc6 do you have? (dpkg -p libc6) Maybe dmd is incompatible with older versions of libc6? T

I tried to install DMD 2.060 in 32 bit Ubuntu 12.04 (live cd in virtual box). I had to do apt-get install -f after installing the deb to get the dependencies, but after that, it worked. So I don't think this is due to libc6 version.
Oct 15 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jacob Carlborg:

 How should DMD detect if you're building a (dynamic) library? 
 Sure it can see that you're not using -lib or -shared but what 
 about separate complication?

What about the need to use a compiler switch if you are performing a separate compilation? A related enhancement request that I'm asking for since years is: the compiler could define a compile-time constant (like is_main_module or something) as true if the module contains the main, and false otherwise. This allows to have a main() in each module. This is handy to have, it allows to compile&run modules both as normal modules to import, or to compile and run them as stand alone programs, like when you want a module to show a demo of its capabilities, or just run its unittests. Bye, bearophile
Oct 15 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 15 October 2012 at 11:20:26 UTC, bearophile wrote:
 Jacob Carlborg:

 How should DMD detect if you're building a (dynamic) library? 
 Sure it can see that you're not using -lib or -shared but what 
 about separate complication?

What about the need to use a compiler switch if you are performing a separate compilation? A related enhancement request that I'm asking for since years is: the compiler could define a compile-time constant (like is_main_module or something) as true if the module contains the main, and false otherwise. This allows to have a main() in each module. This is handy to have, it allows to compile&run modules both as normal modules to import, or to compile and run them as stand alone programs, like when you want a module to show a demo of its capabilities, or just run its unittests. Bye, bearophile

Yes, this is a nice thing Java, .NET and Python have.
Oct 15 2012
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Mon, 15 Oct 2012 07:43:54 +0100, Alex R=F8nne Petersen <alex lycus.or=
g>  =

wrote:
 Yep, those errors are always a sign that a proper main function is  =

 missing. I have no idea why you would get it otherwise, though.

So.. is it possible to save the source file in such a way that dmd canno= t = "see" main? i.e. not ASCII, UTF-8/16/32 or with a weird BOM, or no BOM or.. R -- = Using Opera's revolutionary email client: http://www.opera.com/mail/
Oct 15 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Regan Heath:

 So.. is it possible to save the source file in such a way that 
 dmd cannot "see" main?

This is a dirty solution (a hack). I don't like that. Bye, bearophile
Oct 15 2012
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Mon, 15 Oct 2012 13:08:42 +0100, bearophile <bearophileHUGS lycos.com>  
wrote:

 Regan Heath:

 So.. is it possible to save the source file in such a way that dmd  
 cannot "see" main?

This is a dirty solution (a hack). I don't like that.

Err.. I was suggesting this might be the OP's problem (I hadn't read the entire thread to know the actual problem was a bad package). I wondered if perhaps he had accidentally created an invalid D source file. I suspect the compiler complains when it encounters bad source files.. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Oct 15 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 15 October 2012 at 11:20:26 UTC, bearophile wrote:
 This allows to have a main() in each module.

You could just version it: version(foo_main) void main() {}
Oct 15 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 15 October 2012 at 03:10:59 UTC, Gerry Weaver wrote:
  I install the latest package and try to build "Hello World".

I've always used the .zip and found it to be the easiest way (and btw, don't follow the terrible installation instructions, just unzip it and use right out of the box). $ wget blah/dmd.version.zip $ unzip dmd.version.zip $ dmd2/src/linux32/bin/dmd hello.d You can of course also add that to your $PATH or use a wrapper script or whatever so you can refer to it easier. That has consistently worked for me for many years. You can install it in /opt or in your own $HOME (my preference, so I don't even have to bother with root).
Oct 15 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:

 You could just version it:

 version(foo_main)
 void main() {}

That's not good enough. What I as talking about is: when the D compilers know a module is the main module, it defines a _standard_ version boolean flag, named like "is_main_module" as true. And it gives a compiler error if it can't find a main. Otherwise "is_main_module" is false. It's meant to be used as: module modulea; int foo() { return 0; } static if (is_main_module) { unittest {} void main() { // demo code import std.stdio; writeln(foo()); } } module moduleb; import modulea; int bar() { return 1; } static if (is_main_module) { unittest {} void main() { // demo code import std.stdio; writeln(foo()); writeln(bar()); } } When you compile modulea, defines its is_main_module as true, it runs its unittests (if you have used -unittest), and its main, that is a demo for the A module. If you compile the moduleb (with rdmd or something), it knows moduleb has to contain the main, it defines is_main_module=true in moduleb and defines is_main_module=false for modulea. So it compiles the main of moduleb and ignores the main of modulea. So it runs the demo code for moduleb only. Using a non-standard user-defined version as you suggest misses all this, and it's not good enough. Standardization and automation is important here. Bye, bearophile
Oct 15 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 15 October 2012 08:23, Gerry Weaver <gerryw compvia.com> wrote:
 On Monday, 15 October 2012 at 07:12:03 UTC, Iain Buclaw wrote:
 On 15 October 2012 04:10, Gerry Weaver <gerryw compvia.com> wrote:
 Hello All,

 I have been looking at D off and on for several years. Initially I worked
 through a very painful experience to get D compiling on Linux. After that
 experience, I concluded that I should wait for it to become more mature.
 Since then, I do a very simple test. I install the latest package and try
 to
 build "Hello World". I figure that if "Hello World" builds successfully,
 I
 will continue further. I have just downloaded the latest .deb package and
 installed it on Ubuntu 12.04 32bit. Once again it fails this incredibly
 simple test. I've read many discussions about how/why, has/hasn't,
 will/won't D hit the mainstream in programming languages. I think this
 situation may offer at least one data point. I'm struggling to think of
 any
 other language (and I use several) that won't build code out of the box.
 D
 seems to have a lot of potential, but this needs to be fixed. I am not
 asking for help on this. I honestly don't care what the solution is. I
 just
 wanted the D developers to know why at least one developer is not using
 the
 language. I sincerely hope that the situation will improve. I'm looking
 forward to programming in D.

 Thanks for your time,
 -G



 Here is the code:

 import std.stdio;


 void main()
 {
   writeln("Hello, world!");
 }

 Here is the command:

 dmd hello.d

 Here is the output:

 /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'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_18f_1b8.o): In function
 `_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':

 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x1d):
 undefined reference to `_tlsend'

 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x24):
 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_19f_6e4.o): In function
 `thread_attachThis':
 src/core/thread.d:(.text.thread_attachThis+0xb7): undefined reference to
 `_tlsstart'
 src/core/thread.d:(.text.thread_attachThis+0xbc): undefined reference to
 `_tlsend'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17d_1b8.o): In function
 `_D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread':

 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x1d):
 undefined reference to `_tlsend'

 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x27):
 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17e_1b8.o): In function
 `_D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread':

 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x1d):
 undefined reference to `_tlsend'

 src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x27):
 undefined reference to `_tlsstart'
 /usr/lib/i386-linux-gnu/libphobos2.a(deh2_43b_525.o): In function
 `_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':

 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x4):
 undefined reference to `_deh_beg'

 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0xc):
 undefined reference to `_deh_beg'

 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x13):
 undefined reference to `_deh_end'

 src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x36):
 undefined reference to `_deh_end'
 /usr/lib/i386-linux-gnu/libphobos2.a(thread_17a_713.o): In function
 `thread_entryPoint':
 src/core/thread.d:(.text.thread_entryPoint+0x64): undefined reference to
 `_tlsend'
 src/core/thread.d:(.text.thread_entryPoint+0x6a): undefined reference to
 `_tlsstart'
 collect2: ld returned 1 exit status
 --- errorlevel 1

Try and paste the output of the following: dmd -c hello.d objdump -d hello.o Regards

Hi, Here you go. hello.o: file format elf32-i386 Disassembly of section .text: 00000000 <.text>: 0: b8 10 00 00 00 mov $0x10,%eax 5: b9 00 00 00 00 mov $0x0,%ecx a: 8b 11 mov (%ecx),%edx c: 89 10 mov %edx,(%eax) e: 89 01 mov %eax,(%ecx) 10: c3 ret Thanks, -G

That looks to me as if hello.d is an empty file. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 15 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Monday, 15 October 2012 at 13:11:29 UTC, bearophile wrote:
 Adam D. Ruppe:

 You could just version it:

 version(foo_main)
 void main() {}

That's not good enough. What I as talking about is: when the D compilers know a module is the main module, it defines a _standard_ version boolean flag, named like "is_main_module" as true. And it gives a compiler error if it can't find a main. Otherwise "is_main_module" is false. It's meant to be used as: module modulea; int foo() { return 0; } static if (is_main_module) { unittest {} void main() { // demo code import std.stdio; writeln(foo()); } } module moduleb; import modulea; int bar() { return 1; } static if (is_main_module) { unittest {} void main() { // demo code import std.stdio; writeln(foo()); writeln(bar()); } } When you compile modulea, defines its is_main_module as true, it runs its unittests (if you have used -unittest), and its main, that is a demo for the A module. If you compile the moduleb (with rdmd or something), it knows moduleb has to contain the main, it defines is_main_module=true in moduleb and defines is_main_module=false for modulea. So it compiles the main of moduleb and ignores the main of modulea. So it runs the demo code for moduleb only. Using a non-standard user-defined version as you suggest misses all this, and it's not good enough. Standardization and automation is important here. Bye, bearophile

I'm sorry to say but that *is* a _horrible_ _hack_. It looks almost as awful as it does in python with the underscores. Java has the correct DRY solution - each class can define a static main method but the compiler only uses the one specified by a compiler switch. The above basically asks the programmer to endlessly repeat the same trivial implementation boilerplate that should be written just once _in_ the compiler.
Oct 15 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
foobar:

 I'm sorry to say but that *is* a _horrible_ _hack_. It looks 
 almost as awful as it does in python with the underscores.

 Java has the correct DRY solution - each class can define a 
 static main method but the compiler only uses the one specified 
 by a compiler switch.
 The above basically asks the programmer to endlessly repeat the 
 same trivial implementation boilerplate that should be written 
 just once _in_ the compiler.

What I have suggested is the simplest (requires less stuff to be implemented) way to solve the problem, adding just a single compile time constant. But I agree there are better ways to solve the same problem. I am asking for a specific way to solve this problem, but since some years I'd like some "good enough" way to solve it. Bye, bearophile
Oct 15 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
 I am asking for a specific way to solve this problem,

Sorry, I am not asking for a specific way to solve this problem, but... Bye, bearophile
Oct 15 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Monday, 15 October 2012 at 15:22:38 UTC, Andrei Alexandrescu 
wrote:
<snip>
 Yes, this is a nice thing Java, .NET and Python have.

Wonder if a simple convention would suffice, e.g. every module that wanna defines a moduleMain(string[] args) and then you have one module main.d that has: void main(string[] args) { import wuddever; moduleMain(args); } Andrei

Great idea! But why add another (redundant) level of indirection? It should go in the C main in druntime together with a mechanism to call the correct D main, by e.g. reading the module name from the command line.
Oct 15 2012
prev sibling next sibling parent "Gerry Weaver" <gerryw compvia.com> writes:
On Monday, 15 October 2012 at 17:36:10 UTC, Ali Çehreli wrote:
 On 10/15/2012 06:22 AM, Iain Buclaw wrote:
 On 15 October 2012 08:23, Gerry Weaver<gerryw compvia.com>

 Disassembly of section .text:

 00000000<.text>:
     0:   b8 10 00 00 00          mov    $0x10,%eax
     5:   b9 00 00 00 00          mov    $0x0,%ecx
     a:   8b 11                   mov    (%ecx),%edx
     c:   89 10                   mov    %edx,(%eax)
     e:   89 01                   mov    %eax,(%ecx)
    10:   c3                      ret


 Thanks,
 -G

That looks to me as if hello.d is an empty file.

That is the most plausible reason so far: The OP has an empty file in the current directory but the hello.d that is being edited in Emacs is elsewhere. :) Ali

Hi, I have been looking into this. I'm afraid it isn't that simple. I just created the file with vi in the same directory I was trying to compile it in. I can cat it etc., so I know the text is there. I have even reproduced the issue on a different partition etc.. I'm starting to think that some other package that is installed on this particular system may be the source of the problem. I can't reproduce the issue on another install of the same OS, version, etc.. I went ahead and installed the .deb package on the new system and it still works. Thanks, -G
Oct 15 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Oct 15, 2012 at 07:51:59PM +0200, Gerry Weaver wrote:
 On Monday, 15 October 2012 at 17:36:10 UTC, Ali ehreli wrote:

That is the most plausible reason so far: The OP has an empty file in
the current directory but the hello.d that is being edited in Emacs
is elsewhere. :)

Ali

Hi, I have been looking into this. I'm afraid it isn't that simple. I just created the file with vi in the same directory I was trying to compile it in. I can cat it etc., so I know the text is there. I have even reproduced the issue on a different partition etc.. I'm starting to think that some other package that is installed on this particular system may be the source of the problem. I can't reproduce the issue on another install of the same OS, version, etc.. I went ahead and installed the .deb package on the new system and it still works.

Yeah, it seems to be a very system-specific problem. I'd like to get to bottom of it if I could, as it piques my curiosity (plus it would be nice to prevent somebody else from running into the same problem in the future), but then I don't really want to waste your time hunting down an obscure problem if you already have a working dmd by some other means. T -- The computer is only a tool. Unfortunately, so is the user. -- Armaphine, K5
Oct 15 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Monday, 15 October 2012 at 17:53:15 UTC, Andrei Alexandrescu 
wrote:
 On 10/15/12 1:37 PM, foobar wrote:
 On Monday, 15 October 2012 at 15:22:38 UTC, Andrei 
 Alexandrescu wrote:
 <snip>
 Yes, this is a nice thing Java, .NET and Python have.

Wonder if a simple convention would suffice, e.g. every module that wanna defines a moduleMain(string[] args) and then you have one module main.d that has: void main(string[] args) { import wuddever; moduleMain(args); } Andrei

Great idea! But why add another (redundant) level of indirection? It should go in the C main in druntime together with a mechanism to call the correct D main, by e.g. reading the module name from the command line.

Well there's a tension here: good language design generally aims at providing few general features applicable to many use cases. Encoding particular use cases in the language is warranted by either disproportionate frequency in use or disproportionate difficulty in implementing them within the language. I don't think this particular feature scores very highly in either category. Andrei

Well, it isn't so much in the language per se as it's (mostly?) in druntime. We _already_ have code in druntime that calls the user supplied main function. All I'm suggesting is a very minor enhancement to that mechanism which does add useful convenience. Seems to me the usefulness of this greatly outweighs the implementation cost.
Oct 15 2012
prev sibling next sibling parent "Gerry Weaver" <gerryw compvia.com> writes:
On Monday, 15 October 2012 at 18:03:10 UTC, H. S. Teoh wrote:
 On Mon, Oct 15, 2012 at 07:51:59PM +0200, Gerry Weaver wrote:
 On Monday, 15 October 2012 at 17:36:10 UTC, Ali Çehreli wrote:

That is the most plausible reason so far: The OP has an empty 
file in
the current directory but the hello.d that is being edited in 
Emacs
is elsewhere. :)

Ali

Hi, I have been looking into this. I'm afraid it isn't that simple. I just created the file with vi in the same directory I was trying to compile it in. I can cat it etc., so I know the text is there. I have even reproduced the issue on a different partition etc.. I'm starting to think that some other package that is installed on this particular system may be the source of the problem. I can't reproduce the issue on another install of the same OS, version, etc.. I went ahead and installed the .deb package on the new system and it still works.

Yeah, it seems to be a very system-specific problem. I'd like to get to bottom of it if I could, as it piques my curiosity (plus it would be nice to prevent somebody else from running into the same problem in the future), but then I don't really want to waste your time hunting down an obscure problem if you already have a working dmd by some other means. T

Hi, 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. Thanks, -G
Oct 15 2012
prev sibling next sibling parent "Gerry Weaver" <gerryw compvia.com> writes:
On Monday, 15 October 2012 at 18:46:22 UTC, Gerry Weaver wrote:
 On Monday, 15 October 2012 at 18:03:10 UTC, H. S. Teoh wrote:
 On Mon, Oct 15, 2012 at 07:51:59PM +0200, Gerry Weaver wrote:
 On Monday, 15 October 2012 at 17:36:10 UTC, Ali Çehreli 
 wrote:

That is the most plausible reason so far: The OP has an 
empty file in
the current directory but the hello.d that is being edited 
in Emacs
is elsewhere. :)

Ali

Hi, I have been looking into this. I'm afraid it isn't that simple. I just created the file with vi in the same directory I was trying to compile it in. I can cat it etc., so I know the text is there. I have even reproduced the issue on a different partition etc.. I'm starting to think that some other package that is installed on this particular system may be the source of the problem. I can't reproduce the issue on another install of the same OS, version, etc.. I went ahead and installed the .deb package on the new system and it still works.

Yeah, it seems to be a very system-specific problem. I'd like to get to bottom of it if I could, as it piques my curiosity (plus it would be nice to prevent somebody else from running into the same problem in the future), but then I don't really want to waste your time hunting down an obscure problem if you already have a working dmd by some other means. T

Hi, 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. Thanks, -G

Hmm.. It doesn't seem likely that these problems are related. The issue I remembered involved a series of program errors that started with the improper handling of a dlopen. It is almost impossible that dmd could be reproducing this situation. Thanks, -G
Oct 15 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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 -- Не дорог подарок, дорога любовь.
Oct 15 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 Well there's a tension here: good language design generally 
 aims at providing few general features applicable to many use 
 cases. Encoding particular use cases in the language is 
 warranted by either disproportionate frequency in use or 
 disproportionate difficulty in implementing them within the 
 language. I don't think this particular feature scores very 
 highly in either category.

It's a feature that I use about in every Python module/package I've written, and it's about as equally used in code you see in Python repositories. So it's a common need in Python. I'm asking for it for more than three years or so. And regarding the implementation my "hack" means having a single compile-time constant (plus a switch to be used when you want partial compilation?). Better designs are possible, but it's a matter of how much you want to work for it. Bye, bearophile
Oct 15 2012
prev sibling next sibling parent "Gerry Weaver" <gerryw compvia.com> writes:
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
Oct 15 2012
prev sibling next sibling parent "Gerry Weaver" <gerryw compvia.com> writes:
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
Oct 15 2012
prev sibling next sibling parent "Gerry Weaver" <gerryw compvia.com> writes:
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
Oct 15 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 15 October 2012 23:21, Gerry Weaver <gerryw 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';
Oct 15 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 I don't think that compares apples to apples, as the entire 
 feature combination present into either language must be taken 
 into account.

I agree that features must take in account the specific ecology of the other features of a language. And I agree the problem I am discussing about refers to the idea of "main module" that is currently ill defined in D (but I think it should be defined). But the point is, I am desiring to solve this problem since years in D, so far I have written tons of lines of D1/D2 code, and I have not found a good solution.
 I think for someone coming from Python, something akin to

 if __name__ == "__main__":
     main()

 makes good sense. In my opinion that's not a design we should 
 copy.

I have suggested that solution just because I know it, and because it's probably easy to implement (once the idea of main module is defined). But I agree there are surely better designs to solve this problem. But some solution is desired, that Python-style solution is better than the current D situation :-) Currently I usually solve that problem wrapping the main in "static if (modulename_main)" and I compile with that version. Bye, bearophile
Oct 15 2012
prev sibling next sibling parent 1100110 <0b1100110 gmail.com> writes:
On Mon, 15 Oct 2012 06:24:57 -0500, Paulo Pinto <pjmlp progtools.org>  
wrote:

 On Monday, 15 October 2012 at 11:20:26 UTC, bearophile wrote:
 Jacob Carlborg:

 How should DMD detect if you're building a (dynamic) library? Sure it  
 can see that you're not using -lib or -shared but what about separate  
 complication?

What about the need to use a compiler switch if you are performing a separate compilation? A related enhancement request that I'm asking for since years is: the compiler could define a compile-time constant (like is_main_module or something) as true if the module contains the main, and false otherwise. This allows to have a main() in each module. This is handy to have, it allows to compile&run modules both as normal modules to import, or to compile and run them as stand alone programs, like when you want a module to show a demo of its capabilities, or just run its unittests. Bye, bearophile

Yes, this is a nice thing Java, .NET and Python have.

works but is kinda hacky, and line numbering on error messages might be one or two off. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Oct 15 2012
prev sibling next sibling parent 1100110 <0b1100110 gmail.com> writes:
On Sun, 14 Oct 2012 23:39:42 -0500, H. S. Teoh <hsteoh quickfur.ath.cx> =
 =

wrote:

 On Mon, Oct 15, 2012 at 06:20:03AM +0200, Alex R=C3=B8nne Petersen wro=

 On 15-10-2012 05:10, Gerry Weaver wrote:

dmd hello.d

Here is the output:

/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'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_18f_1b8.o): In function
`_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6threa=



undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6threa=



undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_19f_6e4.o): In function
`thread_attachThis':
src/core/thread.d:(.text.thread_attachThis+0xb7): undefined referenc=



 to
`_tlsstart'
src/core/thread.d:(.text.thread_attachThis+0xbc): undefined referenc=



 to
`_tlsend'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17d_1b8.o): In function
`_D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6=



undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6=



undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17e_1b8.o): In function
`_D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6=



undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6=



undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(deh2_43b_525.o): In function
`_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTab=



undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTab=



undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTab=



undefined reference to `_deh_end'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTab=



undefined reference to `_deh_end'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17a_713.o): In function
`thread_entryPoint':
src/core/thread.d:(.text.thread_entryPoint+0x64): undefined referenc=



 to
`_tlsend'
src/core/thread.d:(.text.thread_entryPoint+0x6a): undefined referenc=



 to
`_tlsstart'
collect2: ld returned 1 exit status
--- errorlevel 1


This looks like what happens if you try to use the latest dmd release with an old version of Phobos, perhaps installed along with gdc. Whoever's doing the .deb packaging really should add a versioned Depends: field to debian/control so that it will require installation =

 the correct version of Phobos, or, at the very least, refuse to instal=

 if such is not available.

From what I've seen, LDC and GDC both rename their versions of phobos s= o = that they won't interfere. I've had all three installed side-by-side at one point in time... -- = Using Opera's revolutionary email client: http://www.opera.com/mail/
Oct 15 2012
prev sibling next sibling parent 1100110 <0b1100110 gmail.com> writes:
On Mon, 15 Oct 2012 04:58:14 -0500, Don Clugston <dac nospam.com> wrote:

 On 15/10/12 11:14, Jacob Carlborg wrote:
 Just use DVM, it's also cross-platform:

 https://bitbucket.org/doob/dvm

I tried that on both Windows and Ubuntu, and couldn't get it to work on either of them. I posted a couple of bug reports eight months ago, and they still haven't been fixed. Not recommended for anyone who is having problems with their installation.

Doesn't work on Arch 64bit either. I tried to fix it at one point and gave it up... -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Oct 15 2012
prev sibling next sibling parent 1100110 <0b1100110 gmail.com> writes:
On Tue, 16 Oct 2012 01:47:16 -0500, Jacob Carlborg <doob me.com> wrote:

 On 2012-10-16 01:54, 1100110 wrote:

 Doesn't work on Arch 64bit either.  I tried to fix it at one point and
 gave it up...

Please report the issue so it's not forgotten. You don't need to have fix or a pull request, just information how I should reproduce it. https://bitbucket.org/doob/dvm

dvm install -l (no output) dvm list No installed D compilers Thats it. No errors, I'll make a issue in a bit. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Oct 16 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Monday, 15 October 2012 at 23:54:54 UTC, 1100110 wrote:
 From what I've seen, LDC and GDC both rename their versions of 
 phobos so that they won't interfere.

This is correct. David
Oct 16 2012
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Monday, 15 October 2012 at 20:19:22 UTC, Gerry Weaver wrote:
 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.

Shouldn't the application be terminated when a library fails to load?
Oct 16 2012
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Tue, 16 Oct 2012 09:32:25 +0200
schrieb Jacob Carlborg <doob me.com>:

 On 2012-10-16 09:04, 1100110 wrote:
 
 OK. Install dvm using directions on bitbucket.

 dvm install -l
 (no output)
 dvm list
 No installed D compilers

 Thats it.  No errors, I'll make a issue in a bit.

The -l flag seems to be horrible broken. Can you try "dvm install 2.060".

Ok now that everyone is bashing I can jump in, too. I tried a few commands and they all failed with bugs already listed in the bug tracker. no kidding. :D --- "dvm list": An unknown error occurred: tango.core.Exception.VfsException: FileFolder.open :: path does not exist: /home/marco/.dvm/compilers --- "dvm -l install": zsh: segmentation fault ./dvm-0.4.0-linux-64 -l install --- "dvm install dmd-2.060": Fetching: http://ftp.digitalmars.com/dmd.dmd-2.060.zip An unknown error occurred: tango.core.Exception.IOException: The resource with URL "http://ftp.digitalmars.com/dmd.dmd-2.060.zip" could not be found. --- "dvm install 2.060": Fetching: http://ftp.digitalmars.com/dmd.2.060.zip [========================================>] 26846/26191 KB Installing: dmd-2.060 An unknown error occurred: tango.core.Exception.IOException: /home/marco/.dvm/bin/dmd-2.060 :: No such file or directory At this point I stopped, because I was too scared. -- Marco
Oct 19 2012
prev sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Monday, 15 October 2012 at 14:29:42 UTC, foobar wrote:

 Java has the correct DRY solution - each class can define a 
 static main method but the compiler only uses the one specified 
 by a compiler switch.
 The above basically asks the programmer to endlessly repeat the 
 same trivial implementation boilerplate that should be written 
 just once _in_ the compiler.

I remember this. I remember scratching my head and asking why, but then realizing that likely 99% of the time it's never called, so I started using it to build and do unittests (without Junit). Curiously. I'm suddenly reminded of a test suite I made for a company for Visual Basic. It was years ago and a nice little test suite; I really wish I had a copy.
Oct 19 2012