x64 Link Issues - Can someone please help?
Hey all, I'm currently using D for a hook-based project that requires me to build both a 32bit and 64bit DLL. Naturally, the 32bit DLL builds fine, however I'm encountering linking issues for the 64bit. I followed the instructions at http://wiki.dlang.org/Installing_DMD_on_64-bit_Windows_7_(COFF-compatible) for setting up 64bit building (albeit I didn't use his environment variables - I just put the paths into sc.ini directly), so if there's a problem with my setup, I don't see it. Here is my build output (I'm using Xamarin Studio with Mono-D, if that means anything): --- Building: HookLib (Debug|x64) Performing main compilation... Current dictionary: C:\Development\Projects\EyefinityMaximizer\HookLib dmd.exe -debug -gc "main.d" "C:\Development\Projects\EyefinityMaximizer\EyefinityMaximizer\eyemax\WinAPI.d" "HookLib.def" "user32.lib" "-IC:\Development\Compilers\D\dmd2\src\phobos" "-IC:\Development\Compilers\D\dmd2\src\druntime\src" "-L/IMPLIB:C:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLib.x64.lib" "-odobj\Debug" "-ofC:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLib.x64.dll" -m64 HookLib.def(1) : warning LNK4017: EXETYPE statement not supported for the target platform; ignored HookLib.def(2) : warning LNK4017: SUBSYSTEM statement not supported for the target platform; ignored HookLib.x64.obj : warning LNK4197: export 'CallWndProc' specified multiple times; using first specification Creating library C:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLib.x64.lib and object C:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLib.x64.exp phobos64.lib(dmain2_4ac_1a5.obj) : error LNK2019: unresolved external symbol _Dmain referenced in function main C:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLib.x64.dll : fatal error LNK1120: 1 unresolved externals --- errorlevel 1120 Exit code 1120 Build complete -- 1 error, 0 warnings --- As you can see, there appears to be an issue with my usage of DLLMain() as opposed to just main(). For 32bit building, the documentation states that the compiler recognizes DLLMain and works accordingly - is this also the case for 64bit building? Here is my DLLMain function, in case I'm doing something wrong with it: --- extern (Windows) BOOL DllMain(HINSTANCE hInstance, ULONG ulReason, LPVOID pvReserved) { // Main DLL switch switch (ulReason) { case DLL_PROCESS_ATTACH: g_hInst = hInstance; dll_process_attach( hInstance, true ); break; case DLL_PROCESS_DETACH: dll_process_detach( hInstance, true ); break; case DLL_THREAD_ATTACH: dll_thread_attach( true, true ); break; case DLL_THREAD_DETACH: dll_thread_detach( true, true ); break; default: break; } return true; } --- Any assistance would be appreciated, as this project is stalled until I can build 64bit binaries. Thanks and regards, Trey
Re: x64 Link Issues - Can someone please help?
On Saturday, 20 April 2013 at 04:46:45 UTC, dnewbie wrote: phobos64.lib(dmain2_4ac_1a5.obj) : error LNK2019: unresolved external symbol _Dmain referenced in function main Please add -L/DLL to the command line. Ahhh ok, thanks! I assumed DMD would have detected the output file being a DLL and sent this itself, but clearly not. In any case, the DLL now builds fine, however one of my other projects in the solution is also refusing to build but for a different reason. Here is it's build output: -- Building: HookLoader (Debug|x64) Performing main compilation... C:\Development\Tools\ResourceCompiler\rc.exe /fo "obj\Debug\Resources.Win32Manifest.res" "C:\Development\Projects\EyefinityMaximizer\HookLoader\Resources\Win32Manifest.rc" Current dictionary: C:\Development\Projects\EyefinityMaximizer\HookLoader dmd.exe -debug -gc "obj\Debug\Resources.Win32Manifest.res" "C:\Development\Projects\EyefinityMaximizer\EyefinityMaximizer\eyemax\WinAPI.d" "main.d" "HookLoader.def" "-IC:\Development\Compilers\D\dmd2\src\phobos" "-IC:\Development\Compilers\D\dmd2\src\druntime\src" "-odobj\Debug" "-ofC:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLoader.x64.exe" -m64 HookLoader.def(1) : warning LNK4017: EXETYPE statement not supported for the target platform; ignored HookLoader.def(1) : warning LNK4017: SUBSYSTEM statement not supported for the target platform; ignored Creating library C:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLoader.x64.lib and object C:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLoader.x64.exp LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt --- errorlevel 1123 Exit code 1123 Build complete -- 1 error, 0 warnings -- Any ideas as to what would cause a 'failure during conversion to COFF'??
Re: x64 Link Issues - Can someone please help?
It seems my resources were breaking the link! Essentially, I was suffering from this problem: http://stackoverflow.com/questions/10888391/link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-invalid-or-c/14144713 In any case, problem solved. Thanks! :)
How/why can toStringz() and toUTFz() be used as properties?
Hey all, Can someone please explain to me how and why it is that toStringz() and toUTFz() can be used in the following way? string a = "123"; auto b = a.toStringz; auto c = a.toUTFz; Also, how is it that they can even be called as if they were class methods? That is: string a = "123"; auto b = a.toStringz(); // <-- Note I've added parentheses auto c = a.toUTFz(); As opposed to being limited to: string a = "123"; auto b = toStringz(a); auto c = toUTFz(a); I need to understand this, as I wish to write a function toWinStr() that can be used in the same way which will accept any string type, and, based on something like version(Unicode) and const-ness, output a WinAPI LPSTR, LPCSTR, LPWSTR or LPCWSTR as appropriate. Is such a thing possible?
Re: How/why can toStringz() and toUTFz() be used as properties?
On Friday, 26 April 2013 at 08:49:10 UTC, anonymous wrote: On Friday, 26 April 2013 at 07:31:57 UTC, Trey Brisbane wrote: Hey all, Can someone please explain to me how and why it is that toStringz() and toUTFz() can be used in the following way? string a = "123"; auto b = a.toStringz; auto c = a.toUTFz; Also, how is it that they can even be called as if they were class methods? That is: string a = "123"; auto b = a.toStringz(); // <-- Note I've added parentheses auto c = a.toUTFz(); As opposed to being limited to: string a = "123"; auto b = toStringz(a); auto c = toUTFz(a); There's two things at work here: a) Universal Function Call Syntax (UFCS). That basically means that you can call a free function via method/property-like dot syntax. The first argument to the function goes before the dot. UFCS should be explained in the online language documentation, but if it's in there I can't find it. So, with UFCS you get from toStringz(a) to a.toStringz() . b) Empty parentheses are optional. -- Unless you compile with the -property flag. There has been some discussion about the future of the feature. Optional empty parentheses and/or the -property flag may go away in the future. That gets you from a.toString() to a.toString . I need to understand this, as I wish to write a function toWinStr() that can be used in the same way which will accept any string type, and, based on something like version(Unicode) and const-ness, output a WinAPI LPSTR, LPCSTR, LPWSTR or LPCWSTR as appropriate. Is such a thing possible? You just write your function so that toWinStr(stuff) works. UFCS and optional empty parentheses then enable stuff.toWinStr . Ahhh ok, thanks for explaining :)
Why do 'abstract' methods with 'in' or 'out' contracts require a body?
Hey all, I have a class method defined like so: abstract class MyClass { public: @property abstract SomeClassType getField() pure nothrow out(result) { assert(result !is null, "Error: getField() returned null."); } } As you can see, this method is abstract, as well as in an abstract class. Why, then, do I get the following error when compiling it? "Error: function module.MyClass.getField in and out contracts require function body" Is this a compiler bug, or is there a reason for this? Thanks for your time!
Re: Why do 'abstract' methods with 'in' or 'out' contracts require a body?
On Saturday, 13 September 2014 at 07:32:23 UTC, Marc Schütz wrote: I thought it was an error, but then I found this in the documentation: http://dlang.org/attribute.html#abstract "Functions declared as abstract can still have function bodies. This is so that even though they must be overridden, they can still provide ‘base class functionality.’" => it's intentional Can != must ;) Interesting fact, but it still looks like a bug to me. The contract shouldn't be forcing a body on an abstract method regardless of whether or not abstract methods are allowed to have bodies.