Floating point not loaded

[Clemens]

Robert Jacques Wrote:

> On Tue, 22 Jun 2010 04:04:03 -0400, Clemens <eriatarka84 at 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.