"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

=?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

"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

=?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

"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

"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.

"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

"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.

"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

"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

=?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

"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

 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

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

"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?

"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

"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

=?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 R�nne Petersen
alex lycus.org
http://lycus.org

"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/

"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

"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/

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.

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

"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

"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.

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

"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.

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

"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.

"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

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

"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

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.

debug mixin(`void main() { /*do something*/ }`);
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/

"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() {}

"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

"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.

"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

"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

"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.

"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

"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.

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.

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Mon, Oct 15, 2012 at 06:20:03AM +0200, Alex R�nne 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

=?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 R�nne 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 R�nne Petersen
alex lycus.org
http://lycus.org

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=

te:
 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=



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



d6Thread+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 referenc=



e  =

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



e  =

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



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



thread6Thread+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=



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



thread6Thread+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_finddataFPvZPS2rt4deh29FuncTab=



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



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



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



le+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 referenc=



e  =

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



e  =

 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 instal=

l
 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/

"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

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

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.

"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.

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

"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

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.

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';

"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

"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

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';

=?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

"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>

 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

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

"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

"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

"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

"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

-- 
Не дорог подарок, дорога любовь.

"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

"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

"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

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';

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

"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?

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

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.

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

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.

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

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/

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

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

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.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

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

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

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

"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).