I'm trying to identify what change has resulted in getting the error:

    Error 42: Symbol Undefined _VarCmp@16

I was doing my not so routine updates for the Juno Class Libraries. This symbol is the VARIANT compare function provided by oleaut32.lib on Windows. It is a very nice function and has been used in Juno for some time. I tracked down the most recent working commit and compiler. The only signature changed made was const parameters (reverting this did not help). All other changes were needed in one form or another to compile in the newer dmd versions.

Using the last known working compiler I attempted a reduced test to see if I can narrow it down as a compiler/linker bug/change. What I ended up with was a test case which exhibited the same behavior on this known working compiler (2.057/2.058).

http://dpaste.dzfl.pl/233d037d

This is not intended to run, I've changed the VARIANT definition to reduce dependencies. Hopefully it is the same size, but I did not make much effort. I've tried different export types, and using pointers instead of ref.

This obviously won't link in Linux, but otherwise any suggestions?

On 10/1/12, Jesse Phillips <jessekphillips+D@gmail.com> wrote:
> snip

1. The import lib shipped with DMD is outdated and is missing that
symbol (http://d.puremagic.com/issues/show_bug.cgi?id=6625)
2. The actual function has C linkage (STDAPI in WinAPI headers

Find oleaut32.dll in your Windows folder, and run implib on it: $ implib oleaut32.lib oleaut32.dll /s

Put the import lib in the same folder as the project and change linkage to extern(C). It works for me this way.

Btw, to verify linkage you can always search the function name on
google, find the MSDN page
(http://msdn.microsoft.com/en-us/library/windows/desktop/ms221006%28v=vs.85%29.aspx),
under requirement it says "Header - OleAuto.h".

Those headers are usually here (you'd need to install the Windows SDK though): C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include

In OleAuto.h VarCmp has STDAPI linkage, which is a macro to extern "C", defined in BaseTyps.h.

On 10/1/12, Jesse Phillips <jessekphillips+D@gmail.com> wrote:
>      Error 42: Symbol Undefined _VarCmp@16

P.S. as soon as pointers are involved you don't need the full type info of such a parameter to debug linker errors, so you can cut down on code when reducing. For example if you had to match this C function but are getting linker errors:

extern "C" void test(SomeType*);

You can prototype this in D as:
extern(C) void test(void*);

You will still get the same linker error, but you won't have to insert the definition of "SomeType".

On Monday, 1 October 2012 at 05:04:32 UTC, Andrej Mitrovic wrote:

> Find oleaut32.dll in your Windows folder, and run implib on it:
> $ implib oleaut32.lib oleaut32.dll /s

Thanks, I'll to play with this more because my first attempt did not resolve the issue and instead has resulted in even more missing symbols. I didn't change export type or anything else so we'll see.

On Monday, 1 October 2012 at 15:22:20 UTC, Jesse Phillips wrote:
> On Monday, 1 October 2012 at 05:04:32 UTC, Andrej Mitrovic wrote:
>
>> Find oleaut32.dll in your Windows folder, and run implib on it:
>> $ implib oleaut32.lib oleaut32.dll /s
>
> Thanks, I'll to play with this more because my first attempt did not resolve the issue and instead has resulted in even more missing symbols. I didn't change export type or anything else so we'll see.

From what i recall, i think i worked around this issue by using coffimplib.exe on the version of oleaut32.lib from the platform sdk, rather than trying to generate a lib from the dll.

On Monday, 1 October 2012 at 05:04:32 UTC, Andrej Mitrovic wrote:
> Find oleaut32.dll in your Windows folder, and run implib on it:
> $ implib oleaut32.lib oleaut32.dll /s
>
> Put the import lib in the same folder as the project and change
> linkage to extern(C). It works for me this way.

Thank you, making these changes did do the trick, bunches of linkages changes needed in the Juno library though... and I wonder how many more I won't find just from compiling the lib...

Still very confused why it ever compiled. Oh well.

I've made the changes needed to get past the linker error, but have run into an Access Violation when using CoInitializeEx

Once again I've returned to 2.057 (without changing ole32.lib) and this will compile and run.

pragma(lib, "ole32.lib");

extern(Windows)
int CoInitializeEx(void*, uint dwCoInit);

void main() {
     CoInitializeEx(null, 0x2);
}

So while this function is also defined as STDAPI in ObjBase.h it is working with windows linkage. Fastforward to dmd 2.060 with the a library update. The code does not link. I change it to extern(C) and linking is fine. However run-time is now an access violation.

So I'm not really sure what I'm should be doing with this. And Richard, I'm not having different results with coffimplib generated library.

When are we getting coff support? Thanks all.

I haven't tried to use DMD 2.060 yet, will see if i've got time later.

On 10/2/12, Jesse Phillips <jessekphillips+D@gmail.com> wrote:
> I've made the changes needed to get past the linker error

I'm sorry, I was completely wrong about STDAPI being extern(C). I saw EXTERN_C and immediately thought this was the calling convention, it's not:

#define STDAPI                  EXTERN_C HRESULT STDAPICALLTYPE #define STDAPICALLTYPE          __stdcall

So this is actually extern(Windows).

Linker errors persist when using implib, but when using coffimplib on an existing COFF import library it will link and work at runtime.

Here's one I made just now: https://dl.dropbox.com/u/9218759/Ole32_dmd.lib It works for me with this:

pragma(lib, "Ole32_dmd.lib");

extern(Windows)
int CoInitializeEx(void*, uint dwCoInit);

void main()
{
     CoInitializeEx(null, 0x2);
}

On 10/2/12, Jesse Phillips <jessekphillips+D@gmail.com> wrote:
> Thank you, making these changes did do the trick

As mentioned in the other thread I was wrong, it's extern(Windows), but implib produced an import lib which didn't quite work. coffimplib does the trick though.