www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Floating point not loaded

reply Clemens <eriatarka84 gmail.com> writes:
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
Jun 19 2010
parent reply Clemens <eriatarka84 gmail.com> writes:
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
Jun 22 2010
parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 22 Jun 2010 04:04:03 -0400, Clemens <eriatarka84 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.
Jun 22 2010
parent reply Clemens <eriatarka84 gmail.com> writes:
Robert Jacques Wrote:


 On Tue, 22 Jun 2010 04:04:03 -0400, Clemens <eriatarka84 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.
Jun 22 2010
parent reply Don <nospam nospam.com> writes:
Clemens wrote:

 Robert Jacques Wrote:
 

 On Tue, 22 Jun 2010 04:04:03 -0400, Clemens <eriatarka84 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.
Jun 22 2010
parent Clemens <eriatarka84 gmail.com> writes:
Don Wrote:


 Clemens wrote:

 Robert Jacques Wrote:
 

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