Floating point not loaded

[Don]

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.