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

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

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

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

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

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

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