RejectedSoftware Forums

Am 14.02.2014 17:15, schrieb Matthew Fong:

What steps are necessary to compile vibe.d to in 64-bit mode in windows?
When I tried the default just with --arch=x86_64, it said it can't find "lib\win-amd64\event2.lib", which indeed is not there:

Linking...
LINK : fatal error LNK1104: Datei "..\..\Users\Unknown\AppData\Roaming\dub\packages\vibe-d-master\lib\win-amd64\event2.lib" kann nicht geöffnet werden.
--- errorlevel 1104

So I thought I might simply use the "VibeWin32Driver" version in my package.json, which turned up the same error.

"versions": ["VibeWin32Driver"] should actually work (just tested
successfully on a local project). Do you build on the command line or
within VisualStudio? In the latter case, did you regenerate the project
file?

On Fri, 14 Feb 2014 17:15:20 GMT, Matthew Fong wrote:

On Fri, 14 Feb 2014 17:59:44 +0100, Sönke Ludwig wrote:

-snip-
"versions": ["VibeWin32Driver"] should actually work (just tested
successfully on a local project). Do you build on the command line or
within VisualStudio? In the latter case, did you regenerate the project
file?

Hmmm... then there must be something wrong with my setup. I'm building with mono-d, but these tests are done on command line. It shouldnt matter anyways I guess. Maybe my package.json? I haven't yet fully grasped the format.

C:\test_flash\project>cat package.json
{
        "name": "packetexport",
        "description": "A minimal D application.",
        "copyright": "Copyright © 2014, Unknown",
        "authors": ["Unknown"],
        "dependencies": {
                "vibe-d": "~master"
        },
        "excludedSourceFiles" : ["source/lzma.d"],
        "versions": ["VibeWin32Driver", "VibeDefaultMain"]
}

C:\test_flash\project>dub --arch=x86_64
Got application for true
Checking dependencies in 'C:\test_flash\project'
Copying files...
Failed to copy to C:\test_flash\project\libevent.dll
Building configuration "application", build type debug
Compiling...
source\autodata.d(46): Warning: toHash() must be declared as extern (D) size_t toHash() const nothrow @safe, not const ulong()
Linking...
LINK : fatal error LNK1104: Datei "..\..\Users\Unknown\AppData\Roaming\dub\packages\vibe-d-master\lib\win-amd64\event2.lib" kann nicht geöffnet werden.
--- errorlevel 1104
Error executing command run: Link command failed with exit code 1104


C:\test_flash\project>

I did a few more tests. Here are my findings:
dub does correctly set the -version=VibeWin32Driver flag for dmd and -m64, so that should be fine.
when it comes to the linking stage though, it still instructs the compiler to link in the non-existen libevent file.
So I wondered why that would be the case and indeed I found it also passes -version=VibeLibeventDriver to dmd. So somehow it must think I specified that too. (which I didn't - at least not in my local package.json).
Is there any other files that dub checks for for these version specifiers? Some files that I might have changed (I can't remember doing so, but I dont want to rule out the possibility)?
Here is my complete dub output on pastebin (since its too long otherwise):
http://pastebin.com/uiUU3BPd

I hope that helps diagnosing the problem

On Tue, 18 Feb 2014 10:06:05 GMT, Sönke Ludwig wrote:

On Mon, 17 Feb 2014 18:02:02 GMT, Matthew Fong wrote:

I did a few more tests. Here are my findings:
dub does correctly set the -version=VibeWin32Driver flag for dmd and -m64, so that should be fine.
when it comes to the linking stage though, it still instructs the compiler to link in the non-existen libevent file.
So I wondered why that would be the case and indeed I found it also passes -version=VibeLibeventDriver to dmd. So somehow it must think I specified that too. (which I didn't - at least not in my local package.json).
Is there any other files that dub checks for for these version specifiers? Some files that I might have changed (I can't remember doing so, but I dont want to rule out the possibility)?
Here is my complete dub output on pastebin (since its too long otherwise):
http://pastebin.com/uiUU3BPd

I hope that helps diagnosing the problem

Oh sorry, I completely missed something. Selecting the driver must be done by choosing a different configuration instead of manually specifying a version constant:

{
	...
	"subConfigurations": {
		"vibe-d": "win32"
	},
	"versions": ["VibeDefaultMain"]
}

This will use the correct linker settings. Have a look at vibe.d's package.json to see how this is organized.

Ok, this almost fixes the problem.
After adding that section to my package.json, the output is as follows:

C:\test_flash\project>dub --arch=x86_64
Got application for true
Checking dependencies in 'C:\test_flash\project'
Copying files...
Building configuration "application", build type debug
Compiling...
source\autodata.d(46): Warning: toHash() must be declared as extern (D) size_t toHash() const nothrow @safe, not const ulong()
Linking...
packetexport.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__imp_TranslateMessage" in Funktion "_D4vibe4core7drivers5win3216Win32EventDriver15doProcessEventsMFkZb".
packetexport.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "PostMessageW" in Funktion "_D4vibe4core7drivers5win3216Win32ManualEvent4emitMFZv14__foreachbody2MFKC4vibe4core7dri
vers5win3216Win32EventDriverKbZi".
packetexport.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__imp_RegisterClassA" in Funktion "_D4vibe4core7drivers5win3216setupWindowClassFZv".
packetexport.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__imp_DefWindowProcA" in Funktion "_D4vibe4core7drivers5win3216Win32EventDriver9onMessageWNbPvkmlZl".
packetexport.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "PostThreadMessageW" in Funktion "_D4vibe4core7drivers5win3216Win32EventDriver13exitEventLoopMFZv".
packetexport.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "DispatchMessageW" in Funktion "_D4vibe4core7drivers5win3216Win32EventDriver15doProcessEventsMFkZb".
packetexport.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "SetWindowLongPtrA" in Funktion "_D4vibe4core7drivers5win3216Win32EventDriver6__ctorMFC4vibe4core6driver10DriverCor
eZC4vibe4core7drivers5win3216Win32EventDriver".
packetexport.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "GetWindowLongPtrA" in Funktion "_D4vibe4core7drivers5win3216Win32EventDriver6__ctorMFC4vibe4core6driver10DriverCor
eZC4vibe4core7drivers5win3216Win32EventDriver".
packetexport.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "PeekMessageW" in Funktion "_D4vibe4core7drivers5win3216Win32EventDriver15doProcessEventsMFkZb".
packetexport.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "MsgWaitForMultipleObjectsEx" in Funktion "_D4vibe4core7drivers5win3216Win32EventDriver13waitForEventsMFkZv".
phobos64.lib(windows_273_50d.obj) : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__imp_CreateWindowExA" in Funktion "CreateWindowA".
.dub\build\application-debug-x86_64-dmd-DA39A3EE5E6B4B0D3255BFEF95601890AFD80709\packetexport.exe : fatal error LNK1120: 11 nicht aufgelöste Externe
--- errorlevel 1120
Error executing command run: Link command failed with exit code 1120

So I looked up these missing functions on MSDN and turns out they're all from User32.lib, so I simply added

"libs-windows": [
				...
				"user32"
			],

to dub's package.json. That made it compile+link+run correctly. I'm now a happy guy :)
Still, I wonder why this was necessary for me though. If this really is required, maybe it should be added by default.

On Tue, 18 Feb 2014 19:32:46 +0100, Sönke Ludwig wrote:

Seems like the 32-bit toolchain has these symbols defined automatically
somehow (probably dragged in by Phobos/Druntime). I didn't notice the
problem on 64-bit either, because the tested projects all had user32.lib
manually linked in already for other reasons. I'll add it to the list now.

Perfect! Looks good now.
Do you think a note for future explorers should be added on how to compile the different versions?