www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - datetime fails with undefined reference

reply Kai Meyer <kai fiber.net> writes:
I can't seem to use std.datetime at all. I get undefined reference on whether
I use a StopWatch, or if I just try to compile the unittest. All I have to do
is declare a StopWatch:

import std.stdio;
import std.datetime;

void main()
{
    StopWatch sw;
}


This fails to compile:
[kai worky ~]$ dmd datetime_test.d
/usr/lib/gcc/x86_64-redhat-linux/4.5.1/../../../../lib/libphobos2.a(datetime_35c_30e.o):
In function `_D3std8datetime7systimeFNeZS3std8datetime5Ticks':
std/datetime.d:(.text._D3std8datetime7systimeFNeZS3std8datetime5Ticks+0x1c):
undefined reference to `clock_gettime'
/usr/lib/gcc/x86_64-redhat-linux/4.5.1/../../../../lib/libphobos2.a(datetime_359_1fe.o):
In function `_D3std8datetime5Ticks12_staticCtor5OFNeZv':
std/datetime.d:(.text._D3std8datetime5Ticks12_staticCtor5OFNeZv+0x1b):
undefined reference to `clock_getres'
collect2: ld returned 1 exit status
--- errorlevel 1

Am I missing some libraries somewhere?

If I 'import core.sys.posix.time, core.sys.posix.sys.time;', parts of dattime
work, and others don't. A main with just:
    writef("%s %s\n", (is(typeof({auto fp = &clock_gettime; }))));

Prints "true true", but using them like this gives undefined again:
    timespec ts; writef("%d\n", clock_getres(CLOCK_REALTIME, &ts));


datetime_test.o: In function `_Dmain':
datetime_test.d:(.text._Dmain+0x34): undefined reference to `clock_getres'
collect2: ld returned 1 exit status
--- errorlevel 1


I'm running Fedora 14 x86_64, dmd-2.051-0.i386, glibc-2.13-1.i686.

Any ideas?
Feb 18 2011
next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Fri, 18 Feb 2011 16:38:19 +0000, Kai Meyer wrote:

 I can't seem to use std.datetime at all. I get undefined reference on
 whether I use a StopWatch, or if I just try to compile the unittest. All
 I have to do is declare a StopWatch:
 
 import std.stdio;
 import std.datetime;
 
 void main()
 {
     StopWatch sw;
 }
 
 
 This fails to compile:
 [kai worky ~]$ dmd datetime_test.d
 /usr/lib/gcc/x86_64-redhat-linux/4.5.1/../../../../lib/libphobos2.a

 In function `_D3std8datetime7systimeFNeZS3std8datetime5Ticks':
 std/datetime.d:(.text._D3std8datetime7systimeFNeZS3std8datetime5Ticks

 undefined reference to `clock_gettime'
 /usr/lib/gcc/x86_64-redhat-linux/4.5.1/../../../../lib/libphobos2.a

 In function `_D3std8datetime5Ticks12_staticCtor5OFNeZv':
 std/datetime.d:(.text._D3std8datetime5Ticks12_staticCtor5OFNeZv+0x1b):
 undefined reference to `clock_getres' collect2: ld returned 1 exit
 status
 --- errorlevel 1
 
 Am I missing some libraries somewhere?
 
 If I 'import core.sys.posix.time, core.sys.posix.sys.time;', parts of
 dattime work, and others don't. A main with just:
     writef("%s %s\n", (is(typeof({auto fp = &clock_gettime; }))));
 
 Prints "true true", but using them like this gives undefined again:
     timespec ts; writef("%d\n", clock_getres(CLOCK_REALTIME, &ts));
 
 
 datetime_test.o: In function `_Dmain':
 datetime_test.d:(.text._Dmain+0x34): undefined reference to
 `clock_getres' collect2: ld returned 1 exit status
 --- errorlevel 1
 
 
 I'm running Fedora 14 x86_64, dmd-2.051-0.i386, glibc-2.13-1.i686.
 
 Any ideas?

You have to link in librt. Pass the -L-lrt option to DMD and it should work. -Lars
Feb 18 2011
next sibling parent reply Kai Meyer <kai fiber.net> writes:
Great news! Worked like a champ. Is there documentation somewhere that I
missed? I
would love to be able to answer these questions on my own. I've been stumped on
this one for a week :(
Feb 18 2011
parent Kai Meyer <kai fiber.net> writes:
== Quote from Jonathan M Davis (jmdavisProg gmx.com)'s article
 On Friday, February 18, 2011 10:12:09 Kai Meyer wrote:
 Great news! Worked like a champ. Is there documentation somewhere that I
 missed? I would love to be able to answer these questions on my own. I've
 been stumped on this one for a week :(

dmd.conf, that would be the problem. Actually, I wouldn't have expected and old dmd.conf to work at all, since the directory structure for the lib folder(s) was changed due to the addition of 64-bit. So, I don't know what the deal with your setup is. Regardless, make sure that your current dmd.conf is either the most up-to-date on or at least based on it. Otherwise, you're going to be running into issues. - Jonathan M Davis

Ok, my dmd.conf that came with the download does not have it in there. The package doesn't claim ownership to /etc/dmd.conf. I removed the rpm package, deleted the old dmd.conf, and installed the rpm again, but the dmd.conf that was generated is exactly the same: [kai worky ~]$ cat /etc/dmd.conf [Environment] DFLAGS= -I/usr/include/d/dmd/phobos -I/usr/include/d/dmd/druntime/import -L-L/usr/lib Should I just simply add "-L-lrt" to the dmd.conf for now? Or just put it in my make file? Why does the rpm not claim ownership of the config file?: [kai worky ~]$ rpm -qf /etc/dmd.conf file /etc/dmd.conf is not owned by any package [kai worky ~]$ rpm -ql dmd | grep dmd.conf /usr/share/man/man5/dmd.conf.5.gz Thanks for the fast replies!
Feb 18 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, February 18, 2011 10:12:09 Kai Meyer wrote:
 Great news! Worked like a champ. Is there documentation somewhere that I
 missed? I would love to be able to answer these questions on my own. I've
 been stumped on this one for a week :(

That should be in the dmd.conf in dmd.2.052.zip. If you're using an old dmd.conf, that would be the problem. Actually, I wouldn't have expected and old dmd.conf to work at all, since the directory structure for the lib folder(s) was changed due to the addition of 64-bit. So, I don't know what the deal with your setup is. Regardless, make sure that your current dmd.conf is either the most up-to-date on or at least based on it. Otherwise, you're going to be running into issues. - Jonathan M Davis
Feb 18 2011
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Fri, 18 Feb 2011 10:23:41 -0800, Jonathan M Davis wrote:

 On Friday, February 18, 2011 10:12:09 Kai Meyer wrote:
 Great news! Worked like a champ. Is there documentation somewhere that
 I missed? I would love to be able to answer these questions on my own.
 I've been stumped on this one for a week :(

That should be in the dmd.conf in dmd.2.052.zip. If you're using an old dmd.conf, that would be the problem. Actually, I wouldn't have expected and old dmd.conf to work at all, since the directory structure for the lib folder(s) was changed due to the addition of 64-bit. So, I don't know what the deal with your setup is. Regardless, make sure that your current dmd.conf is either the most up-to-date on or at least based on it. Otherwise, you're going to be running into issues.

Well, he could be using a setup similar to me. I don't use dmd.conf at all. Instead I set the DFLAGS environment variable in the startup script of my shell. I think the new dependency should be noted in the changelog. -Lars
Feb 18 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

As noted in my earlier email on the other list, I too got this problem.
Fromn what I can tell 1.066 and 2.051 have dmd.conf files but there is
no such thing in the 1.067 and 2.052 distributions.  So the "out of the
box" configuration does seem to be "broken".

 That should be in the dmd.conf in dmd.2.052.zip. If you're using an old=

 dmd.conf, that would be the problem. Actually, I wouldn't have expected a=

 dmd.conf to work at all, since the directory structure for the lib folder=

 changed due to the addition of 64-bit. So, I don't know what the deal wit=

 setup is. Regardless, make sure that your current dmd.conf is either the =

 up-to-date on or at least based on it. Otherwise, you're going to be runn=

 into issues.

--=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Feb 18 2011
prev sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 2011-02-19 at 00:27 +0000, Russel Winder wrote:
 As noted in my earlier email on the other list, I too got this problem.
 Fromn what I can tell 1.066 and 2.051 have dmd.conf files but there is
 no such thing in the 1.067 and 2.052 distributions.  So the "out of the
 box" configuration does seem to be "broken".
=20
 That should be in the dmd.conf in dmd.2.052.zip. If you're using an old=


 dmd.conf, that would be the problem. Actually, I wouldn't have expected=


 dmd.conf to work at all, since the directory structure for the lib fold=


 changed due to the addition of 64-bit. So, I don't know what the deal w=


 setup is. Regardless, make sure that your current dmd.conf is either th=


 up-to-date on or at least based on it. Otherwise, you're going to be ru=


 into issues.


Sorry this is not correct, the locate database just hasn't been updated since I installeed. However the linux/bin/dmd.conf file is indentical in the 2.051 and 2.052 distributions. This means DMD is broken "out of the box". --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Feb 18 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, February 18, 2011 11:43:22 Lars T. Kyllingstad wrote:
 On Fri, 18 Feb 2011 10:23:41 -0800, Jonathan M Davis wrote:
 On Friday, February 18, 2011 10:12:09 Kai Meyer wrote:
 Great news! Worked like a champ. Is there documentation somewhere that
 I missed? I would love to be able to answer these questions on my own.
 I've been stumped on this one for a week :(

That should be in the dmd.conf in dmd.2.052.zip. If you're using an old dmd.conf, that would be the problem. Actually, I wouldn't have expected and old dmd.conf to work at all, since the directory structure for the lib folder(s) was changed due to the addition of 64-bit. So, I don't know what the deal with your setup is. Regardless, make sure that your current dmd.conf is either the most up-to-date on or at least based on it. Otherwise, you're going to be running into issues.

Well, he could be using a setup similar to me. I don't use dmd.conf at all. Instead I set the DFLAGS environment variable in the startup script of my shell. I think the new dependency should be noted in the changelog.

Probably, but I think that Andrei or Walter would have to be the one to do that. But dmd.conf has changed a fair bit with this release, and anyone who doesn't use dmd.conf (I have no idea why you wouldn't - it seems like you're just making life harder on yourself) is going to run into trouble. However, in general, I don't think that dmd.conf changes have made it into the changelog, so that's nothing new. Walter probably assumes that you're going to use the provided dmd.conf and doesn't think about it. - Jonathan M Davis
Feb 18 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, February 18, 2011 12:29:40 Kai Meyer wrote:
 == Quote from Jonathan M Davis (jmdavisProg gmx.com)'s article
 
 On Friday, February 18, 2011 10:12:09 Kai Meyer wrote:
 Great news! Worked like a champ. Is there documentation somewhere that
 I missed? I would love to be able to answer these questions on my own.
 I've been stumped on this one for a week :(

That should be in the dmd.conf in dmd.2.052.zip. If you're using an old dmd.conf, that would be the problem. Actually, I wouldn't have expected and old dmd.conf to work at all, since the directory structure for the lib folder(s) was changed due to the addition of 64-bit. So, I don't know what the deal with your setup is. Regardless, make sure that your current dmd.conf is either the most up-to-date on or at least based on it. Otherwise, you're going to be running into issues. - Jonathan M Davis

Ok, my dmd.conf that came with the download does not have it in there. The package doesn't claim ownership to /etc/dmd.conf. I removed the rpm package, deleted the old dmd.conf, and installed the rpm again, but the dmd.conf that was generated is exactly the same: [kai worky ~]$ cat /etc/dmd.conf [Environment] DFLAGS= -I/usr/include/d/dmd/phobos -I/usr/include/d/dmd/druntime/import -L-L/usr/lib Should I just simply add "-L-lrt" to the dmd.conf for now? Or just put it in my make file? Why does the rpm not claim ownership of the config file?: [kai worky ~]$ rpm -qf /etc/dmd.conf file /etc/dmd.conf is not owned by any package [kai worky ~]$ rpm -ql dmd | grep dmd.conf /usr/share/man/man5/dmd.conf.5.gz Thanks for the fast replies!

If you just use the zip file, you're fine. I don't know what the state of the rpm is. I just always use the zip file. It's nice and self contained. All you have to do is make sure that /path/to/dmd2/linux/bin is on your PATH. The current dmd.conf should look like this: ======= [Environment] DFLAGS=-I% P%/../../src/phobos -I% P%/../../src/druntime/import -L- L% P%/../lib32 -L-L% P%/../lib64 -L--no-warn-search-mismatch -L--export-dynamic -L-lrt ======= If the pieces get moved elsewhere (such as installing libphobos2.a in a /usr/lib or something similar), then the paths would have to be updated though. Also, according to the online docs: ==== dmd will look for the initialization file dmd.conf in the following sequence of directories: 1. current working directory 2. directory specified by the HOME environment variable 3. directory dmd resides in 4. /etc/ ====== So, maybe you need to just put the correct dmd.conf in one of the first three spots. Or you could just edit /etc/dmd.conf. I don't know what exactly the rpm does, so I don't know what it does with dmd.conf. But you have several options. Really, -L-lrt _should_ be in dmd.conf since core.time and std.datetime require it, but ultimately what matters is that it be in your DFLAGS so that dmd uses it when compiling. - Jonathan M Davis
Feb 18 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, February 18, 2011 16:27:23 Russel Winder wrote:
 As noted in my earlier email on the other list, I too got this problem.
 Fromn what I can tell 1.066 and 2.051 have dmd.conf files but there is
 no such thing in the 1.067 and 2.052 distributions.  So the "out of the
 box" configuration does seem to be "broken".

And as I said in my response to your other message, the proper dmd.conf file _is_ in the distributed zip file. So, unless you're dealing with the deb or rpm, and they're broken, and I don't know why you wouldn't be seeing a new dmd.conf with the 2.052 release. But I don't know what the state of the rpm or deb is. I just always use the zip file, which is very simple. - Jonathan M Davis
Feb 18 2011
parent Kai Meyer <kai fiber.net> writes:
== Quote from Jonathan M Davis (jmdavisProg gmx.com)'s article
 On Friday, February 18, 2011 16:27:23 Russel Winder wrote:
 As noted in my earlier email on the other list, I too got this problem.
 Fromn what I can tell 1.066 and 2.051 have dmd.conf files but there is
 no such thing in the 1.067 and 2.052 distributions.  So the "out of the
 box" configuration does seem to be "broken".

in the distributed zip file. So, unless you're dealing with the deb or rpm, and they're broken, and I don't know why you wouldn't be seeing a new dmd.conf with the 2.052 release. But I don't know what the state of the rpm or deb is. I just always use the zip file, which is very simple. - Jonathan M Davis

Ok, I can fix the dmd.conf. Who does manage the RPM packaging? And how can I get a hold of them?
Feb 21 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Jonathan,

On Fri, 2011-02-18 at 17:28 -0800, Jonathan M Davis wrote:
 On Friday, February 18, 2011 16:27:23 Russel Winder wrote:
 As noted in my earlier email on the other list, I too got this problem.
 Fromn what I can tell 1.066 and 2.051 have dmd.conf files but there is
 no such thing in the 1.067 and 2.052 distributions.  So the "out of the
 box" configuration does seem to be "broken".

And as I said in my response to your other message, the proper dmd.conf f=

 in the distributed zip file. So, unless you're dealing with the deb or rp=

 they're broken, and I don't know why you wouldn't be seeing a new dmd.con=

 the 2.052 release. But I don't know what the state of the rpm or deb is. =

 always use the zip file, which is very simple.

I was too tired last evening to think this through properly, my apologies. Hopefully I am now more with it. I made a single character typing error in my diff last evening that was critical to my statement that the two conf files were the same. Correcting that, the two are clearly not the same, and I do indeed have a conf file with lib32 and lib64 in the environment line, exactly as you assured me. My fault for doubting, apologies. Of course this now raises the issue that if I have the right configuration, why is the library necessary for correct linking of std.date and std.datetime not being found "out of the box". I can see the -L-lrt at the end of the line in the dmd.conf file. I can see: /usr/lib/librt.a /usr/lib/librt.so /usr/lib32/librt.a /usr/lib32/librt.so are present and correct on my machine. OK so it is blindingly obvious: I am using SCons, which builds its own dmd/gcc sequence of calls instead of just using dmd as a driver for hte whole compile and link. The crucial point is that it separates calling dmd from calling gcc. Thus the real question is then: should the SCons D tool be reading the dmd.conf, editing the first -L out since that is to get the option from the dmd to the gcc when dmd is the driver. Alternatively do I just replicate the knowledge in the dmd.conf file?=20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Feb 19 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 19 February 2011 04:39:21 Russel Winder wrote:
 Jonathan,
 
 On Fri, 2011-02-18 at 17:28 -0800, Jonathan M Davis wrote:
 On Friday, February 18, 2011 16:27:23 Russel Winder wrote:
 As noted in my earlier email on the other list, I too got this problem.
 Fromn what I can tell 1.066 and 2.051 have dmd.conf files but there is
 no such thing in the 1.067 and 2.052 distributions.  So the "out of the
 box" configuration does seem to be "broken".

And as I said in my response to your other message, the proper dmd.conf file _is_ in the distributed zip file. So, unless you're dealing with the deb or rpm, and they're broken, and I don't know why you wouldn't be seeing a new dmd.conf with the 2.052 release. But I don't know what the state of the rpm or deb is. I just always use the zip file, which is very simple.

I was too tired last evening to think this through properly, my apologies. Hopefully I am now more with it. I made a single character typing error in my diff last evening that was critical to my statement that the two conf files were the same. Correcting that, the two are clearly not the same, and I do indeed have a conf file with lib32 and lib64 in the environment line, exactly as you assured me. My fault for doubting, apologies. Of course this now raises the issue that if I have the right configuration, why is the library necessary for correct linking of std.date and std.datetime not being found "out of the box". I can see the -L-lrt at the end of the line in the dmd.conf file. I can see: /usr/lib/librt.a /usr/lib/librt.so /usr/lib32/librt.a /usr/lib32/librt.so are present and correct on my machine. OK so it is blindingly obvious: I am using SCons, which builds its own dmd/gcc sequence of calls instead of just using dmd as a driver for hte whole compile and link. The crucial point is that it separates calling dmd from calling gcc. Thus the real question is then: should the SCons D tool be reading the dmd.conf, editing the first -L out since that is to get the option from the dmd to the gcc when dmd is the driver. Alternatively do I just replicate the knowledge in the dmd.conf file?

I don't know anything about SCons. However, you _can_ use dmd to link if you want to (though that doesn't always work, since not all linker flags make it through safely; e.g., -L-static), so you shouldn't normally actually need to use gcc, even if you're doing incremental builds. Now, if you need to use gcc for whatever reason, then you're going to need to either duplicate the flags in dmd.conf or parse it out. If it's just for you, then duplicating it would make sense. However, since dmd.conf is intended to be able to be tweaked by whoever is using it (adjusting where the libraries, adding extra flags, whatever), if the SCons D tool is supposed to know what flags to use, and it's supposed to work on anyone's computer, then it's going to need to parse out dmd.conf. Otherwise, it won't be correct on the machine of anyone who doesn't use the default configuration. But as I said, I know nothing about SCons, so I don't know what the best way to handle it is. - Jonathan M Davis
Feb 19 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 2011-02-19 at 04:55 -0800, Jonathan M Davis wrote:
[ . . . ]
 I don't know anything about SCons. However, you _can_ use dmd to link if =

 want to (though that doesn't always work, since not all linker flags make=

 through safely; e.g., -L-static), so you shouldn't normally actually need=

 gcc, even if you're doing incremental builds.

I'll have a play with using DMD as the driver for all stages.
 Now, if you need to use gcc for whatever reason, then you're going to nee=

 either duplicate the flags in dmd.conf or parse it out. If it's just for =

 then duplicating it would make sense. However, since dmd.conf is intended=

 able to be tweaked by whoever is using it (adjusting where the libraries,=

 extra flags, whatever), if the SCons D tool is supposed to know what flag=

 and it's supposed to work on anyone's computer, then it's going to need t=

 out dmd.conf. Otherwise, it won't be correct on the machine of anyone who=

 doesn't use the default configuration.
=20
 But as I said, I know nothing about SCons, so I don't know what the best =

 handle it is.

Actually I think your summary works very well :-) I will look to replace all the hardwired replication of information with a simple parse of the configuration file. The hard question is: where is the configuration file? The problem I have here is that I have 64-bit Ubuntu, 64-bit Ubuntu, 64-bit Mac OS X and 32-bit Mac OS X but nothing else.which means I can only really develop 50% of the plugin. I really need a Windows person to work with to co-develop this. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Feb 19 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 2011-02-19 at 20:07 +0000, Russel Winder wrote:
[ . . . ]
 The problem I have here is that I have 64-bit Ubuntu, 64-bit Ubuntu,

s/Ubuntu/Debian/ --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Feb 19 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 19 February 2011 12:07:40 Russel Winder wrote:
 On Sat, 2011-02-19 at 04:55 -0800, Jonathan M Davis wrote:
 [ . . . ]
 
 I don't know anything about SCons. However, you _can_ use dmd to link if
 you want to (though that doesn't always work, since not all linker flags
 make it through safely; e.g., -L-static), so you shouldn't normally
 actually need to use gcc, even if you're doing incremental builds.

I'll have a play with using DMD as the driver for all stages.
 Now, if you need to use gcc for whatever reason, then you're going to
 need to either duplicate the flags in dmd.conf or parse it out. If it's
 just for you, then duplicating it would make sense. However, since
 dmd.conf is intended to be able to be tweaked by whoever is using it
 (adjusting where the libraries, adding extra flags, whatever), if the
 SCons D tool is supposed to know what flags to use, and it's supposed to
 work on anyone's computer, then it's going to need to parse out
 dmd.conf. Otherwise, it won't be correct on the machine of anyone who
 doesn't use the default configuration.
 
 But as I said, I know nothing about SCons, so I don't know what the best
 way to handle it is.

Actually I think your summary works very well :-) I will look to replace all the hardwired replication of information with a simple parse of the configuration file. The hard question is: where is the configuration file?

Well, the dmd page very explicitly lays out the various places that the dmd.conf file (or sc.ini file on Windows) will be looked for and in what order (since there could also be a dmd.conf in multiple places, and it needs to use the same one that dmd would).
 The problem I have here is that I have 64-bit Ubuntu, 64-bit Ubuntu,
 64-bit Mac OS X and 32-bit Mac OS X but nothing else.which means I can
 only really develop 50% of the plugin.  I really need a Windows person
 to work with to co-develop this.

I know the feeling. At least you have Mac OS X. Wine could help you fill in the gaps though. - Jonathan M Davis
Feb 19 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday 21 February 2011 08:40:38 Kai Meyer wrote:
 == Quote from Jonathan M Davis (jmdavisProg gmx.com)'s article
 
 On Friday, February 18, 2011 16:27:23 Russel Winder wrote:
 As noted in my earlier email on the other list, I too got this problem.
 Fromn what I can tell 1.066 and 2.051 have dmd.conf files but there is
 no such thing in the 1.067 and 2.052 distributions.  So the "out of the
 box" configuration does seem to be "broken".

And as I said in my response to your other message, the proper dmd.conf file _is_ in the distributed zip file. So, unless you're dealing with the deb or rpm, and they're broken, and I don't know why you wouldn't be seeing a new dmd.conf with the 2.052 release. But I don't know what the state of the rpm or deb is. I just always use the zip file, which is very simple. - Jonathan M Davis

Ok, I can fix the dmd.conf. Who does manage the RPM packaging? And how can I get a hold of them?

I'm not sure who deals with the RPM stuff (though looking at the download on the site, the rpm hasn't been updated 2.052 - it's still on 2.051). If it's broken, post on the "dmd 1.067 and 2.052 release" thread in D.announce, since that's where people are generally looking for info on the release. If you haven't registered with the announce list, then you can just start a thread on it in the main D list. That's the place that the most people will notice and where you're most likely to get the attention of whoever it is needs to know (which may be Walter, but I don't know). However, I _would_ point out that it's extremely easy to just the zip file. I've never bothered with the rpm, personally. So, while the rpm should definitely should be fixed, if all you're really looking to do is have a working dmd, using the zip is likely a good option. You just download it and unzip it to wherever you want it (e.g. your home folder) and then add the path to the linux/bin folder within it (e.g. ~/dmd2/linux/bin) to your PATH variable (presumably in your .bashrc), and it then it'll work just fine. It'll grab phobos from the right place and the dmd.conf will be correct. Every time that a new version is released, you just replace the dmd2 folder with the newly unzipped version, and it works. - Jonathan M Davis
Feb 21 2011