LDC2 -I option results in unresolved externals
I'm using the latest LDC2 beta, and when running the compiler with -I (Look for imports also in ) it fails with unresolved externals. These are my commands. = $ ldc2 "source\setup.d" -I "source" -J "build\vars" -of "build\bin\setup.exe" -m32 -g setup.obj : error LNK2019: unresolved external symbol __D6common17createErrorDialogFxC9ExceptionZv referenced in function __Dmain setup.obj : error LNK2019: unresolved external symbol __D6common14getConsoleArgsFxPuZAAya referenced in function __D5setup20getAvailableBrowsersFZ14__foreachbody1MFKC3std7windows8registry3KeyZi setup.obj : error LNK2001: unresolved external symbol __D6common12__ModuleInfoZ build\bin\setup.exe : fatal error LNK1120: 3 unresolved externals Error: C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.15.26726\bin\HostX86\x86\link.exe failed with status: 1120 = But this next one works fine. = $ ldc2 "source\setup.d" "source/common.d" -J "build\vars" -of "build\bin\setup.exe" -m32 -g = I'm using LDC2 version 1.12.0-beta2, on DMD v2.082.0, on Windows with VS Build Tools 2017. Any solutions or corrections appreciated.
Re: Use nested functions as callbacks with Windows API functions?
On Monday, 1 October 2018 at 21:03:24 UTC, Boris-Barboris wrote:
On Monday, 1 October 2018 at 20:27:43 UTC, spikespaz wrote:
I was hoping I could use something more akin to JavaScript's
syntax: (void* hWnd, long) => {}.
I tried this but I'm getting errors with the signature, it
says the function is a delegate and apparently Windows API
can't accept a delegate.
You can make it a non-delegate by passing a pointer to hWndList
in lParams as it was supposed to by WinApi devs, instead of
zero, and not implicitly capturing stack pointer by referencing
hWndList directly from the body.
https://run.dlang.io/is/t4k4Nc
The problem with the code you have is that the callback needs to
be extern (Windows). I don't know how to do that with a "lambda".
===
import core.sys.windows.windows: EnumWindows;
import std.stdio: writeln;
void main() {
void*[] hWndList;
EnumWindows((void* hWnd, void* lParam) nothrow {
*(cast(void*[] *) lParam) ~= hWnd;
return true;
}, );
writeln(hWndList);
}
===
source\cb.d(7): Error: function
core.sys.windows.winuser.EnumWindows(extern (Windows) int
function(void*, long) nothrow, long) is not callable using
argument types (bool function(void* hWnd, void* lParam) pure
nothrow @system, void*[]*)
source\cb.d(7):cannot pass argument __lambda1 of type
bool function(void* hWnd, void* lParam) pure
nothrow @system to parameter extern (Windows) int function(void*,
long) nothrow
Re: Use nested functions as callbacks with Windows API functions?
On Monday, 1 October 2018 at 21:03:24 UTC, Boris-Barboris wrote:
On Monday, 1 October 2018 at 20:27:43 UTC, spikespaz wrote:
I was hoping I could use something more akin to JavaScript's
syntax: (void* hWnd, long) => {}.
I tried this but I'm getting errors with the signature, it
says the function is a delegate and apparently Windows API
can't accept a delegate.
You can make it a non-delegate by passing a pointer to hWndList
in lParams as it was supposed to by WinApi devs, instead of
zero, and not implicitly capturing stack pointer by referencing
hWndList directly from the body.
https://run.dlang.io/is/t4k4Nc
I don't know how to do this. I'm not the best with pointers, I'm
still learning D and I'm unfamiliar with functional programming.
==
import core.sys.windows.windows: EnumWindows;
import std.stdio: writeln;
extern (Windows) int callback(void* hWnd, long hWndList) nothrow {
hWndList ~= hWnd;
return true;
}
void main() {
void*[] hWndList;
EnumWindows(, );
writeln(hWndList);
}
==
Clearly I can't use to pass the reference, how would I
access the variable by the memory address inside the callback?
Use nested functions as callbacks with Windows API functions?
I have the following code, this works.
import core.sys.windows.windows: EnumWindows;
import std.stdio: writeln;
void*[] hWndList;
extern (Windows) int callback(void* hWnd, long /* lParams */ )
nothrow {
hWndList ~= hWnd;
return true;
}
void main() {
EnumWindows(, 0);
writeln(hWndList);
}
I was hoping I could use something more akin to JavaScript's
syntax: (void* hWnd, long) => {}.
I tried this but I'm getting errors with the signature, it says
the function is a delegate and apparently Windows API can't
accept a delegate.
import core.sys.windows.windows: EnumWindows;
import std.stdio: writeln;
void main() {
void*[] hWndList;
EnumWindows((void* hWnd, long /* lParams */ ) nothrow {
hWndList ~= hWnd; return true;
}, 0);
writeln(hWndList);
}
I'm not going to even paste the compiler error because I am very
clearly going about this the wrong way.
Of course there is nothing wrong with defining each callback as a
separate function, but then comes the issue of naming them. I
also don't like the way it makes my code look.
Thanks.
Entry point errors when using LDC to compile Windows Subsystem module with -m32
I have a user having issues running my project on their 32-bit Windows install. I thought LDC2 compiled as 32-bit by default, but for some reason the errors persist for him regardless. In attempt to resolve this, I am doing everything that requires 32-bit explicitly. I downloaded a known-good 32-bit libcurl.dll to distribute with the project, I added -m32 to all of the compile commands, added -L/SUBSYSTEM:WINDOWS etc. When comping with the command below, I get linker errors saying that '/SUBSYSTEM:WINDOWS" isn't recognized and is ignored, and entry point must be defined. MSVCE linker fails with status 1221. ldc2 "source/launcher.d" "source/common.d" -of="build/$release/launcher.exe" \ -m32 -O3 -ffast-math -release -g -L/SYBSYSTEM:WINDOWS Compiling with the following command however works fine, but doesn't work on 32-bit systems. ldc2 "source/launcher.d" "source/common.d" -of="build/$release/launcher.exe" \ -O3 -ffast-math -release -g The issue stems from using 'extern (Windows) WinMain' as the entry point in the file. Any ideas how I can resolve this? https://github.com/spikespaz/search-deflector/blob/master/source/launcher.d https://github.com/spikespaz/search-deflector/blob/master/build.sh
Is it possible to translate this API's C headers?
There is a project that I wish to use from D (https://ultralig.ht). It's Electron, but with forked WebKit and the samples are very, very fast. This is a great compromise between wanting to have a very custom interface and not wanting to use the slow Electron/Sciter/Awesomium/WebView. I am having trouble porting the C headers though. Firstly, I barely know C at all, especially not enough to do this. The extent of my C knowledge is terminal TicTacToe game I made three years ago. I tried using all of the conversion tools under the "Interfacing with C" page of the wiki, but I'm getting import errors. Probably because the paths are all using "<>", expecting an include path from the compiler. I tried to solve this by refractoring the imports to use relative quoted paths. But even when I fixed that, I kept hitting miscellaneous problems with MSVC, LLVM, and every other dependency under the sun those conversion tools needed. So I figured that Windows was just a crappy ecosystem, and tried it on Linux. No easier. So now I'm here, a C noob, really wanting to use Adam's great project from the D language. The only barrier is my lack of knowledge in C. And I definitely do not have the means to port these headers by hand. Could one of you give me pointers about how to go about this? I have the dynamic link libraries, the static libraries, and the header includes. https://github.com/ultralight-ux/ultralight https://github.com/ultralight-ux/ultralight-0.9-api
Re: Trouble with LDC2 and definition file to hide console?
On Monday, 20 August 2018 at 13:42:58 UTC, spikespaz wrote: I am trying to add a *.def file to my program to hide the console window on launch, as it doesn't need to display anything to function. It is a Windows only application. [...] Also adding that the linker flag I have stated above also is ignored by the linker. LINK : warning LNK4044: unrecognized option '/exet:nt/su:windows'; ignored
Trouble with LDC2 and definition file to hide console?
I am trying to add a *.def file to my program to hide the console window on launch, as it doesn't need to display anything to function. It is a Windows only application. I saw at this post (https://forum.dlang.org/post/ilj5vn$ef4$1...@digitalmars.com) that I could either use a linker flag, -L/exet:nt/su:windows, or add a module definition file. I decided on the definition file. EXETYPE NT SUBSYSTEM WINDOWS I have this file named deflector.def, and I compile with the command as follows. ldc2 source/* -of="build/SearchDeflector-x86.exe" -O3 -ffast-math -release All of my source code and the *.def file is in the source/ directory. I am not using DUB. The issue when compiling says that those two definitions(?) aren't supported for my target. That doesn't make sense because I am using the MSVC linker with LDC2. source\deflector.def(1) : warning LNK4017: EXETYPE statement not supported for the target platform; ignored source\deflector.def(2) : warning LNK4017: SUBSYSTEM statement not supported for the target platform; ignored Any help would be appreciated. I would also like to know how to add a PNG or ICO file to my compiled executable. I have icons in the resolutions of 16, 32, 64, 128, 256. Currently I'm adding them in using GitHub's RCEDIT tool (https://github.com/electron/rcedit) but I would like a more proper way.
Linker error for core.sys.windows.winuser imports when compiling as 64 bit.
Hey guys, I'm getting a linker error when compiling with DMD `-m63` that I don't get as 23 bit. I'm importing `ShowWindow` from `core.sys.windows.winuser`, and I get the following: C:\D\dmd2\windows\bin\lld-link.exe: warning: main.obj: undefined symbol: ShowWindow error: link failed Error: linker exited with status 1 My compiler command is `dmd main.d -m64 -i -O -release -inline -boundscheck=off `. I don't think the source code would make a difference other than to say that I'm calling `ShowWindow`. Any help would be much appreciated. Thanks! Also, how does formatting work? Markdown doesn't seem to work, or HTML.
