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


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


You have to link in librt.  Pass the -L-lrt option to DMD and it should 
work.

-Lars
Feb 18 2011
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
next sibling parent reply 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
next sibling parent reply "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
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 parent reply 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 :(


 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!
Feb 18 2011
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 Russel Winder <russel russel.org.uk> writes:
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=


=20

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


nd old=20

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


(s) was=20

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


h your=20

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


most=20

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


ing=20

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




=20

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




 and old=20

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




er(s) was=20

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




ith your=20

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




e most=20

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




nning=20

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


 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?
Feb 21 2011
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
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
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".


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


ile _is_=20

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


m, and=20

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


f with=20

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


I just=20

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

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


 it=20

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


 to use=20

 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=


d to=20

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


you,=20

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


 to be=20

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


 adding=20

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


s to use,=20

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


o parse=20

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


=20

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


way to=20

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