Re: D seems interesting, but...
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.
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
Am Tue, 16 Oct 2012 09:32:25 +0200 schrieb Jacob Carlborg d...@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
Re: D seems interesting, but...
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.
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
On Tue, 16 Oct 2012 01:47:16 -0500, Jacob Carlborg d...@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/
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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?
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
a...@lycus.org
http://lycus.org
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
On 15 October 2012 04:10, Gerry Weaver ger...@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';
Re: D seems interesting, but...
On Monday, 15 October 2012 at 07:12:03 UTC, Iain Buclaw wrote:
On 15 October 2012 04:10, Gerry Weaver ger...@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:
.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
Re: D seems interesting, but...
On Monday, 15 October 2012 at 07:12:03 UTC, Iain Buclaw wrote:
On 15 October 2012 04:10, Gerry Weaver ger...@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:
.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
Re: D seems interesting, but...
On Mon, 15 Oct 2012 08:36:22 +0200, Gerry Weaver ger...@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?
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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.
Re: D seems interesting, but...
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.
Re: D seems interesting, but...
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.
Re: D seems interesting, but...
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 compilerun 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
Re: D seems interesting, but...
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 compilerun 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.
Re: D seems interesting, but...
On Mon, 15 Oct 2012 07:43:54 +0100, Alex Rønne Petersen a...@lycus.org 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 cannot 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/
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
On Mon, 15 Oct 2012 13:08:42 +0100, bearophile bearophileh...@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/
Re: D seems interesting, but...
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).
Re: D seems interesting, but...
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() {}
Re: D seems interesting, but...
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.
Re: D seems interesting, but...
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
Re: D seems interesting, but...
On 15 October 2012 08:23, Gerry Weaver ger...@compvia.com wrote:
On Monday, 15 October 2012 at 07:12:03 UTC, Iain Buclaw wrote:
On 15 October 2012 04:10, Gerry Weaver ger...@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:
.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';
Re: D seems interesting, but...
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.
Re: D seems interesting, but...
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.
Re: D seems interesting, but...
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.
Re: D seems interesting, but...
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 compilerun 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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
On 10/15/2012 06:22 AM, Iain Buclaw wrote: On 15 October 2012 08:23, Gerry Weaverger...@compvia.com wrote: Disassembly of section .text: .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
Re: D seems interesting, but...
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.
Re: D seems interesting, but...
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 Weaverger...@compvia.com wrote: Disassembly of section .text: .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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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.
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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 -- Не дорог подарок, дорога любовь.
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
On 15 October 2012 23:21, Gerry Weaver ger...@compvia.com wrote: On Monday, 15 October 2012 at 20:45:39 UTC, Gerry Weaver wrote: On Monday, 15 October 2012 at 20:19:22 UTC, Gerry Weaver wrote: On Monday, 15 October 2012 at 19:38:24 UTC, H. S. Teoh wrote: On Mon, Oct 15, 2012 at 08:46:21PM +0200, Gerry Weaver wrote: [...] It just occurred to me that I've seen this type of file issue before. If memory serves, it was related to the attempt to load a 64bit lib on a 32bit system. It was an odd problem, because it didn't fail in the way one would expect. The process in that case was reading garbage from memory. I don't get how it could be reading nothing though. Anyway, I'm going to look into this possibility. I found some notes that I made during that time and it does have a similar feel to it. I'll let y'all know what I find. [...] Now, that does sound like it could be the source of the problem. If dmd was reading garbage from the file, if there just happens to be, say, a binary 0 at the beginning (or whatever it is that causes dmd to think it has reached EOF), then it would just stop and produce an empty object file. So the linker will fail to find the symbols that dmd emits when it encounters main(). T Hi, When running dmd, none of the read (and friends) syscalls happen as far as the kernel is concerned. This would lend some credibility to the lib theory. However, it's quite odd that results are the same for each time dmd is executed. I would expect a random result or even a segfault/abort on different runs. Thanks, -G Hi, I think I have satisfied myself that this is probably a fluke. We have captured enough in this thread that there will be a good starting point should the issue ever come up again. It may sound odd, but I'm actually glad it happened. It helped me realize an issue with a system that would probably have manifested itself in some other frustrating and embarrassing way later on ;-) Thanks everyone, -G Hi, Sorry, I neglected to mention something. I did a test with a zero length file and compared the output to the problem case. The output was, in fact, identical. Would it be difficult to do a simple test for zero length files and output a message like error: zero length/empty file filename? The output in this case is fairly misleading. Thanks, -G It would be less misleading if we got rid of _tlsstart and _tlsend. This would slim the error message down to... --- /usr/lib/i386-linux-gnu/libphobos2.a(dmain2_459_1a5.o): In function `_D2rt6dmain24mainUiPPaZi7runMainMFZv': src/rt/dmain2.d:(.text._D2rt6dmain24mainUiPPaZi7runMainMFZv+0x10): undefined reference to `_Dmain' --- Which is less cryptic, and everyone can spot a undefined reference to `_Dmain' more easily. However _tls is engraved in the current design of TLS. On the move to shared libraries, I would hope that these be removed and replaced. Regards -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: D seems interesting, but...
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
Re: D seems interesting, but...
On Mon, 15 Oct 2012 06:24:57 -0500, Paulo Pinto pj...@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 compilerun 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/
Re: D seems interesting, but...
On Sun, 14 Oct 2012 23:39:42 -0500, H. S. Teoh hst...@quickfur.ath.cx 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. From what I've seen, LDC and GDC both rename their versions of phobos so 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/
Re: D seems interesting, but...
On Mon, 15 Oct 2012 04:58:14 -0500, Don Clugston d...@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/
D seems interesting, but...
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
Re: D seems interesting, but...
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
a...@lycus.org
http://lycus.org
Re: D seems interesting, but...
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
a...@lycus.org
http://lycus.org
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
a...@lycus.org
http://lycus.org
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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.
Re: D seems interesting, but...
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.
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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.
Re: D seems interesting, but...
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-disc...@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-gl...@lists.debian.org Thanks, -G
