Clemens wrote:
Robert Jacques Wrote:
On Tue, 22 Jun 2010 04:04:03 -0400, Clemens <eriatark...@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.