datetime fails with undefined reference

[Jonathan M Davis]

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