• Russel Winder (32/32) Feb 18 2011 I had thought std.date was deprecated, it actually seems to have been
• Lars T. Kyllingstad (11/35) Feb 18 2011 (time_10e_4d1.o):
• Jonathan M Davis (7/49) Feb 18 2011 Yeah. Make sure that your dmd.conf is up-to-date. There are a number of ...
• Russel Winder (18/23) Feb 18 2011 hanges=20
• Jonathan M Davis (9/21) Feb 18 2011 No, they're definitely _not_ the same - at least not in the zip file. Ma...
• Russel Winder (23/30) Feb 19 2011 be the=20

Russel Winder <russel russel.org.uk> writes:

I had thought std.date was deprecated, it actually seems to have been
decimated?  Actually it seems to be trying to use datetime anyway?


|> dmd -I. -O -release -inline -m64 -c -ofpi_d2_sequential.o pi_d2_sequenti=
al.d
std.date and std.dateparse have been scheduled for deprecation. Please use =
std.datetime instead.

|> gcc -o pi_d2_sequential pi_d2_sequential.o -L/home/users/russel/lib.Linu=
x.x86_64/DMD2/lib64 -lphobos2 -lpthread -lm
/home/users/russel/lib.Linux.x86_64/DMD2/lib64/libphobos2.a(datetime_434_1e=
c.o): In function `_D3std8datetime5Clock11currStdTimeFNdNeZl':
std/datetime.d:(.text._D3std8datetime5Clock11currStdTimeFNdNeZl+0x1d): unde=
fined reference to `clock_gettime'
/home/users/russel/lib.Linux.x86_64/DMD2/lib64/libphobos2.a(time_10e_4d1.o)=
: In function `_D4core4time12TickDuration12_staticCtor7OFNeZv':
src/core/time.d:(.text._D4core4time12TickDuration12_staticCtor7OFNeZv+0x1f)=
: undefined reference to `clock_getres'
/home/users/russel/lib.Linux.x86_64/DMD2/lib64/libphobos2.a(time_10e_4d1.o)=
: In function `_D4core4time12TickDuration14currSystemTickFNdNeZS4core4time1=
2TickDuration':
src/core/time.d:(.text._D4core4time12TickDuration14currSystemTickFNdNeZS4co=
re4time12TickDuration+0x1f): undefined reference to `clock_gettime'
collect2: ld returned 1 exit status


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

"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:

On Fri, 18 Feb 2011 15:26:20 +0000, Russel Winder wrote:

 I had thought std.date was deprecated, it actually seems to have been
 decimated?  Actually it seems to be trying to use datetime anyway?
 
 
 |> dmd -I. -O -release -inline -m64 -c -ofpi_d2_sequential.o
 pi_d2_sequential.d std.date and std.dateparse have been scheduled for
 deprecation. Please use std.datetime instead.
 
 |> gcc -o pi_d2_sequential pi_d2_sequential.o
 -L/home/users/russel/lib.Linux.x86_64/DMD2/lib64 -lphobos2 -lpthread -lm
 /home/users/russel/lib.Linux.x86_64/DMD2/lib64/libphobos2.a

(datetime_434_1ec.o):
 In function `_D3std8datetime5Clock11currStdTimeFNdNeZl':
 std/datetime.d:(.text._D3std8datetime5Clock11currStdTimeFNdNeZl+0x1d):
 undefined reference to `clock_gettime'
 /home/users/russel/lib.Linux.x86_64/DMD2/lib64/libphobos2.a

(time_10e_4d1.o):
 In function `_D4core4time12TickDuration12_staticCtor7OFNeZv':
 src/core/time.d:(.text._D4core4time12TickDuration12_staticCtor7OFNeZv

+0x1f):
 undefined reference to `clock_getres'
 /home/users/russel/lib.Linux.x86_64/DMD2/lib64/libphobos2.a

(time_10e_4d1.o):
 In function
 

`_D4core4time12TickDuration14currSystemTickFNdNeZS4core4time12TickDuration':
 src/core/time.d:

(.text._D4core4time12TickDuration14currSystemTickFNdNeZS4core4time12TickDuration
+0x1f):
 undefined reference to `clock_gettime' collect2: ld returned 1 exit
 status

You need to link in librt.  Pass the -L-lrt option to DMD (or -lrt to 
GCC), and you get rid of the "undefined reference" errors.

-Lars

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Friday, February 18, 2011 09:41:07 Lars T. Kyllingstad wrote:
 On Fri, 18 Feb 2011 15:26:20 +0000, Russel Winder wrote:
 I had thought std.date was deprecated, it actually seems to have been
 decimated?  Actually it seems to be trying to use datetime anyway?
 
 |> dmd -I. -O -release -inline -m64 -c -ofpi_d2_sequential.o
 
 pi_d2_sequential.d std.date and std.dateparse have been scheduled for
 deprecation. Please use std.datetime instead.
 
 |> gcc -o pi_d2_sequential pi_d2_sequential.o
 
 -L/home/users/russel/lib.Linux.x86_64/DMD2/lib64 -lphobos2 -lpthread -lm
 /home/users/russel/lib.Linux.x86_64/DMD2/lib64/libphobos2.a

 
 (datetime_434_1ec.o):
 In function `_D3std8datetime5Clock11currStdTimeFNdNeZl':
 std/datetime.d:(.text._D3std8datetime5Clock11currStdTimeFNdNeZl+0x1d):
 undefined reference to `clock_gettime'
 /home/users/russel/lib.Linux.x86_64/DMD2/lib64/libphobos2.a

 
 (time_10e_4d1.o):
 In function `_D4core4time12TickDuration12_staticCtor7OFNeZv':
 src/core/time.d:(.text._D4core4time12TickDuration12_staticCtor7OFNeZv

 
 +0x1f):
 undefined reference to `clock_getres'
 /home/users/russel/lib.Linux.x86_64/DMD2/lib64/libphobos2.a

 
 (time_10e_4d1.o):
 In function

 
 `_D4core4time12TickDuration14currSystemTickFNdNeZS4core4time12TickDuration':
 src/core/time.d:

 (.text._D4core4time12TickDuration14currSystemTickFNdNeZS4core4time12TickDur
 ation
 
 +0x1f):
 undefined reference to `clock_gettime' collect2: ld returned 1 exit
 status

 
 You need to link in librt.  Pass the -L-lrt option to DMD (or -lrt to
 GCC), and you get rid of the "undefined reference" errors.

Yeah. Make sure that your dmd.conf is up-to-date. There are a number of changes 
in it with the most recent release - not only the addition of librt, but the
lib 
directories were changed as well. So, everyone should either use the dmd.conf 
that comes in the release or make sure that the dmd.conf that they use is based 
on that dmd.conf. You're going to run into problems otherwise.

- Jonathan M Davis

Russel Winder <russel russel.org.uk> writes:

On Fri, 2011-02-18 at 10:31 -0800, Jonathan M Davis wrote:
[ . . . ]
 Yeah. Make sure that your dmd.conf is up-to-date. There are a number of c=

hanges=20
 in it with the most recent release - not only the addition of librt, but =

the lib=20
 directories were changed as well. So, everyone should either use the dmd.=

conf=20
 that comes in the release or make sure that the dmd.conf that they use is=

 based=20
 on that dmd.conf. You're going to run into problems otherwise.

linux/bin/dmd.conf is identical in the 2.051 and 2.052 distributions
which implies the distribution is broken?

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

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Friday, February 18, 2011 16:58:50 Russel Winder wrote:
 On Fri, 2011-02-18 at 10:31 -0800, Jonathan M Davis wrote:
 [ . . . ]
 
 Yeah. Make sure that your dmd.conf is up-to-date. There are a number of
 changes in it with the most recent release - not only the addition of
 librt, but the lib directories were changed as well. So, everyone should
 either use the dmd.conf that comes in the release or make sure that the
 dmd.conf that they use is based on that dmd.conf. You're going to run
 into problems otherwise.

 
 linux/bin/dmd.conf is identical in the 2.051 and 2.052 distributions
 which implies the distribution is broken?

No, they're definitely _not_ the same - at least not in the zip file. Maybe the 
deb or the rpm is messed up, but the zip file is fine. It _does_ look like
-L-lrt 
was added in dmd 2.051 (though I'm not sure if it was necessary for 2.051), but 
ther are other changes related to 64-bit which are in 2.052. The lib directory 
changed from lib to lib32 and lib64 and a linker flag was added to go with that 
(to stop gcc from complaining about library mismatches). You need a new
dmd.conf 
for the new release. The correct dmd.conf _is_ in the zip file.

- Jonathan M Davis

Russel Winder <russel russel.org.uk> writes:

On Fri, 2011-02-18 at 17:24 -0800, Jonathan M Davis wrote:
[ . . . ]
 No, they're definitely _not_ the same - at least not in the zip file. May=

be the=20
 deb or the rpm is messed up, but the zip file is fine. It _does_ look lik=

e -L-lrt=20
 was added in dmd 2.051 (though I'm not sure if it was necessary for 2.051=

), but=20
 ther are other changes related to 64-bit which are in 2.052. The lib dire=

ctory=20
 changed from lib to lib32 and lib64 and a linker flag was added to go wit=

h that=20
 (to stop gcc from complaining about library mismatches). You need a new d=

md.conf=20
 for the new release. The correct dmd.conf _is_ in the zip file.

Definitely.  My error, I typed a 2 instead of a 1 in the command line.
Correcting that shows the files to be correctly as they should be.  5.5
hours sleep also brought me to the realization that I was wandering down
the wrong path with my problem.  The fault was in the SCons D tool, not
to with DMD at all.

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