Well, I solved the linker error by specifying imports in the
.def file. The pathetic thing was that the def file was invalid
just because I had a newline, or at least it worked without it.
So my final .def file looks like this:
EXETYPE NT
SUBSYSTEM WINDOWS
IMPORTS
_Direct3DCreate9@4 = d3d9.Direc
On 2011-06-14 18:30, Trass3r wrote:
Am 14.06.2011, 02:43 Uhr, schrieb Loopback :
Thanks for all the answers! Seems like rdmd did the trick.
I don't see why this isn't built in to dmd though
No one does ;)
Haha well it would be nice if at least one soul knew and could explain..
I've also st
Am 14.06.2011, 02:43 Uhr, schrieb Loopback :
Thanks for all the answers! Seems like rdmd did the trick.
I don't see why this isn't built in to dmd though
No one does ;)
I've also stumbled upon an additional error with the win32 DirectX
bindings, but this seems D related actually. When I comp
Trass3r Wrote:
> > Shouldn't the linker/compiler be able to solve this on its own then?
>
> Use rdmd or xfBuild to automatically compile all needed modules.
Everyone we'll keep asking that question forever until the D compiler does this
by itself :-)
Bye,
bearophile
Thanks for all the answers! Seems like rdmd did the trick.
I don't see why this isn't built in to dmd though, or does it cause
overhead when you are using rdmd? Benefits, Drawbacks?
I've also stumbled upon an additional error with the win32 DirectX
bindings, but this seems D related actually. Whe
Shouldn't the linker/compiler be able to solve this on its own then?
Use rdmd or xfBuild to automatically compile all needed modules.
sc.ini is going to get overwritten when you upgrade DMD so changing it
is a bad idea. An alternative is to copy sc.ini to your projects local
directory, this way DMD will use that one instead of its own. But this
is all working around the issue that you should be passing import
directories via a bu
On 2011-06-13 23:51, Jonathan M Davis wrote:
On 2011-06-13 14:44, Loopback wrote:
Thanks for your answer!
Seems like supplying with the file location solved the problem, though I
still wonder about one thing. The imported module is located in
"c:/d/dmd2/import/win32/windef.d" and I have used th
On 2011-06-13 14:44, Loopback wrote:
> Thanks for your answer!
>
> Seems like supplying with the file location solved the problem, though I
> still wonder about one thing. The imported module is located in
> "c:/d/dmd2/import/win32/windef.d" and I have used this command line to
> the DMD compiler:
Thanks for your answer!
Seems like supplying with the file location solved the problem, though I
still wonder about one thing. The imported module is located in
"c:/d/dmd2/import/win32/windef.d" and I have used this command line to
the DMD compiler: -I"c:/d/dmd2/import/". Shouldn't the linker/
On 2011-06-13 14:18, Loopback wrote:
> Hi!
>
> Let me begin by saying, I'm sorry if this is caused of some obvious
> error but since I am new to D, I am not aware of all the tricks and
> treats it offers.
>
> I am working with the WindowsAPI binding at dsource.org (though I do not
> believe this
Importing it means dmd knows about the function and emits a call but
doesn't automatically generate the function code.
This is only done if you also pass the file containing it to dmd.
Am 13.06.2011 23:18, schrieb Loopback:
Hi!
Let me begin by saying, I'm sorry if this is caused of some obvious
error but since I am new to D, I am not aware of all the tricks and
treats it offers.
I am working with the WindowsAPI binding at dsource.org (though I do not
believe this is related t
Hi!
Let me begin by saying, I'm sorry if this is caused of some obvious
error but since I am new to D, I am not aware of all the tricks and
treats it offers.
I am working with the WindowsAPI binding at dsource.org (though I do not
believe this is related to the binding itself). However, in m
14 matches
Mail list logo
