Floating point not loaded

[Clemens]

Don Wrote:

> Clemens wrote:
> > 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.
> 
> Sounds as though there might be two different versions of snn.lib? Maybe 
>    it's getting the wrong one.

Funnily enough, the snn.lib from the DMC zip and the one from the DMD zip do slightly differ, but the sizes are almost the same, so the difference probably isn't huge. Regardless, I now completely removed the LIB= key from my sc.ini so that I need to specify all libraries by hand, and as soon as I mention one of the snn.lib files on the command line, no matter the DMC or the DMD one, everything works flawlessly. If I don't mention it explicitly but have it on the LIB path, then the program links fine, but I get the runtime error. I'm at a loss as to what's wrong here.

Can anyone reproduce this bug? I tried it on Linux and it works there, this is strictly a Windows issue.