Robert Jacques Wrote:
> On Tue, 22 Jun 2010 04:04:03 -0400, Clemens <eriatark...@gmail.com> wrote:
>
> > Clemens Wrote:
> >
> >> I have a stupid problem linking D with C. This is with D 1.062, haven't
> >> tried D2. So say I have two files:
> >>
> >> ------ cfmt.c --------
> >>
> >> #include <string.h>
> >>
> >> char* myfmt(double x)
> >> {
> >> static char buf[40];
> >> sprintf(buf, "%f", x);
> >> return buf;
> >> }
> >>
> >> ------- test.d --------
> >>
> >> extern(C) char* myfmt(double x);
> >>
> >> void main()
> >> {
> >> myfmt(42.3);
> >> }
> >>
> >> ---------------------------
> >>
> >> and I compile and link them as follows:
> >>
> >> > dmc -c cfmt.c
> >> > dmd test.d cfmt.obj
> >> > test.exe
> >>
> >> I get the runtime error "Floating point not loaded". No exception or
> >> anything, the executable just terminates with that message on the
> >> terminal. I found a short paragraph about that runtime error on
> >> http://www.digitalmars.com/ctg/runtime.html
> >> but it wasn't too helpful; a quick grep showed me that _fltused occurs
> >> in both cfmt.obj and test.obj.
> >>
> >> Anyone seen this before? What can I do? I'm pretty sure this used to
> >> work with an older version. The actual real-world use case is linking
> >> to Lua, which bombs out with the same message once you use the string
> >> concatenation operator with a numeric argument. I used the Lua binding
> >> from dsource which comes with a precompiled library, and just to be
> >> sure I then compiled my own version of Lua with dmc; to no avail.
> >>
> >> Clemens
> >
> > FWIW, I found a workaround to this: if I specify to link with snn.lib
> > explicitly on the command line, then everything seems to work. I'm a bit
> > surprised since I thought that snn.lib is pulled in automatically. Is
> > this a bug in DMD, in Optlink, or by some strange twist of fate expected
> > behavior?
> >
> > Clemens
>
> You always need to specify the libs you're linking too. This has always
> been the case. There is a pragma statement that tells the compiler to link
> a library, so you can specify the link in the code rather than the command
> line.
I do believe the case is different here since snn.lib is the Digital Mars C
runtime library. I quote from http://www.digitalmars.com/d/1.0/dmd-windows.html:
> The programs must be linked with the D runtime library phobos.lib, followed
> by the C runtime library snn.lib. This is done automatically as long as the
> directories for the libraries are on the LIB environment variable path.
I have no reason to doubt that the paths are set up correctly since linking a
D-only program works without problems.
Also note that this is a runtime error, not a compile- or link-time error.
