• Igor (12/12) Jan 25 2016 error LNK2019: unresolved external symbol GetStockObject
• Mike Parker (24/36) Jan 25 2016 For clarity, libraries are not imported, they are linked.
• Mike Parker (2/3) Jan 25 2016 *compiled* form

Igor <Vladamir.I google.com> writes:

  error LNK2019: unresolved external symbol GetStockObject 
referenced in function _D2Application10createWindowMFPFZvZi (int 
Application.createWindow(void function()*))

and the line of code is

wc.hbrBackground = GetStockObject(WHITE_BRUSH);

I've tried to

import core.sys.windows.wingdi;

But that just got me to this error. When I don't use it, the code 
compiles

I was able to solve this problem by importing gdi32.lib on the 
command line.  Shouldn't the module import the lib like it does 
for the other ones? or does it?

Mike Parker <aldacron gmail.com> writes:

On Monday, 25 January 2016 at 22:57:22 UTC, Igor wrote:
  error LNK2019: unresolved external symbol GetStockObject 
 referenced in function _D2Application10createWindowMFPFZvZi 
 (int Application.createWindow(void function()*))

 and the line of code is

 wc.hbrBackground = GetStockObject(WHITE_BRUSH);

 I've tried to

 import core.sys.windows.wingdi;

 But that just got me to this error. When I don't use it, the 
 code compiles

 I was able to solve this problem by importing gdi32.lib on the 
 command line.  Shouldn't the module import the lib like it does 
 for the other ones? or does it?

For clarity, libraries are not imported, they are linked. 
*Modules* are imported. Imports are processed at compile time to 
determine which symbols are available for use in the current 
compilation units. Libraries and object files are processed by 
the linker after compilation and imports have no role to play in 
that. Unresolved external symbol errors are linker errors, 
meaning you used a symbol in your code, the linker looked for its 
copied form in all the available object files (including any 
libraries it was given) and couldn't find it.

The Windows API is implemented in multiple libraries. I believe 
DMD links to kernel32.lib and user32.lib by default, as those 
contain the most commonly used functions, but if you want to call 
any functions from any of the other Win32 libraries, you will 
need to link with them manually either by passing them on the 
command line or by using a lib pragma. If you aren't sure which 
library needs linking with when you get a missing symbol, the 
thing to do is to look up the function in the MSDN (Microsoft 
Developer Network) documentation and it will tell you which 
library you need. Usually it's enough to feed the function to 
Google and you will get the MSDN page in one of the first few 
links (though you'll need to make sure to go to the Win32 API 
page and not the documentation for the .NET version of the 
function).

Mike Parker <aldacron gmail.com> writes:

On Tuesday, 26 January 2016 at 05:05:43 UTC, Mike Parker wrote:

 the linker looked for its copied form

*compiled* form