Prev: Loading numbered files in sequence
Next: Which inclue file to use to use the winapi. Not using stdafx or MFC.
From: muybluie on 23 Apr 2008 17:55
Hi,

I have encoutered a strange error which I cannot fathom.

I have a DLL that exports a base class and a derived class, both
exported. Here is an example header file snippet:

class __declspec(dllexport) A
{
//All kinds of stuff
virtual method( _RecordsetPtr rs );
};

class __dclspec(dllexport) B : public A
{
//override
virtual method( _RecordsetPtr rs );
};

In a different DLL, I link with the the LIB for the above code, and
attempt to use 'B'. However, I get an 'unresolved external' linker
error for 'B::method'. The weird thing is that if I change the method
to not be virtual, or if I change the parameter to not be a
RecordsetPtr, the code links successfully. It seems like the
combination of a virtual method and an ADO recordset does not work.
What gives?

The DLL that is attempting to link with the exported code makes use of
ADO recordsets elsewhere, so it knows how to locate the binary
instructions for the RecordsetPtr.

Any suggestions would be welcome - am I missing something, or is this
some quirk of Visual Studio (I am using VS 2003).

Thanks!
From: Giovanni Dicanio on 23 Apr 2008 18:12

<muybluie(a)hotmail.com> ha scritto nel messaggio
news:c962ea66-3eb7-418f-b474-620668bedc9a(a)z72g2000hsb.googlegroups.com...

> In a different DLL, I link with the the LIB for the above code, and
> attempt to use 'B'. However, I get an 'unresolved external' linker
> error for 'B::method'. The weird thing is that if I change the method
> to not be virtual, or if I change the parameter to not be a
> RecordsetPtr, the code links successfully. It seems like the
> combination of a virtual method and an ADO recordset does not work.
> What gives?

> Any suggestions would be welcome - am I missing something, or is this
> some quirk of Visual Studio (I am using VS 2003).

The first thing that comes in my mind is that you should make sure that
every DLLs in your solution is built with the same compiler (VS2003).

e.g. Avoid to mix DLLs with *C++* interfaces built using VC6, with DLLs or
other code built with a different compiler like VS2003.

If your DLL has a C++ interface - due to C++ name mangling - you should use
the *same* compiler to build both the DLL and the other modules like .EXEs.

Giovanni



From: muybluie on 23 Apr 2008 18:41
On Apr 23, 6:12 pm, "Giovanni Dicanio" <giovanni.dica...(a)invalid.com>
wrote:
> <muybl...(a)hotmail.com> ha scritto nel messaggionews:c962ea66-3eb7-418f-b474-620668bedc9a(a)z72g2000hsb.googlegroups.com...
>
> > In a different DLL, I link with the the LIB for the above code, and
> > attempt to use 'B'.  However, I get an 'unresolved external' linker
> > error for 'B::method'.  The weird thing is that if I change the method
> > to not be virtual, or if I change the parameter to not be a
> > RecordsetPtr, the code links successfully.  It seems like the
> > combination of a virtual method and an ADO recordset does not work.
> > What gives?
> > Any suggestions would be welcome - am I missing something, or is this
> > some quirk of Visual Studio (I am using VS 2003).
>
> The first thing that comes in my mind is that you should make sure that
> every DLLs in your solution is built with the same compiler (VS2003).
>
> e.g. Avoid to mix DLLs with *C++* interfaces built using VC6, with DLLs or
> other code built with a different compiler like VS2003.
>
> If your DLL has a C++ interface - due to C++ name mangling - you should use
> the *same* compiler to build both the DLL and the other modules like .EXEs..
>
> Giovanni

Weird - where did my reply go? OK, here it is again...

First off, thanks for replying.

All my DLLs are compiled using the same compiler for sure. There are
some third party DLLs, lie msado15.dll. However, that is a COM dll,
so importing it should suffice. In any case I know I can use the ADO
classes elsewhere, so I don't think that's it. Could it be that the
name mangling the linker does has a size limit, and I exceed it,
causing the linker to fail to recognize the method? Could there be
some linker setting I am unaware of that causes the two DLLs to mangle
the names differently? I'll take a look...

Thanks!
From: muybluie on 23 Apr 2008 18:35
On Apr 23, 6:12 pm, "Giovanni Dicanio" <giovanni.dica...(a)invalid.com>
wrote:
> <muybl...(a)hotmail.com> ha scritto nel messaggionews:c962ea66-3eb7-418f-b474-620668bedc9a(a)z72g2000hsb.googlegroups.com...
>
> > In a different DLL, I link with the the LIB for the above code, and
> > attempt to use 'B'.  However, I get an 'unresolved external' linker
> > error for 'B::method'.  The weird thing is that if I change the method
> > to not be virtual, or if I change the parameter to not be a
> > RecordsetPtr, the code links successfully.  It seems like the
> > combination of a virtual method and an ADO recordset does not work.
> > What gives?
> > Any suggestions would be welcome - am I missing something, or is this
> > some quirk of Visual Studio (I am using VS 2003).
>
> The first thing that comes in my mind is that you should make sure that
> every DLLs in your solution is built with the same compiler (VS2003).
>
> e.g. Avoid to mix DLLs with *C++* interfaces built using VC6, with DLLs or
> other code built with a different compiler like VS2003.
>
> If your DLL has a C++ interface - due to C++ name mangling - you should use
> the *same* compiler to build both the DLL and the other modules like .EXEs..
>
> Giovanni

Hi,

Thanks for your reply!

Well, I know all of my DLLs are built with the same compiler, but I
have no control over DLLs like msado.dll. However, that is a COM dll
and importing it should suffice.

I can work around this with some interface trickery, but I am baffled
by this on a purely theoretical level. I mean, am I seeing a linker
bug here?

Thanks!


From: Giovanni Dicanio on 24 Apr 2008 03:33

<muybluie(a)hotmail.com> ha scritto nel messaggio
news:d4621246-34db-483e-b8cc-7cd3473927e6(a)s50g2000hsb.googlegroups.com...

> First off, thanks for replying.

You're welcome.

> All my DLLs are compiled using the same compiler for sure.

OK.

> There are some third party DLLs, lie msado15.dll. However, that is a COM
> dll,

Yes, COM DLLs are different than C++-interface DLLs, and so COM DLLs can be
built and used also with different compiler versions (e.g. you can build a
COM DLL in VC6 and use that in VC2003 .EXE).

> Could it be that the
> name mangling the linker does has a size limit, and I exceed it,
> causing the linker to fail to recognize the method?

I don't think that.

However, you may use 'DUMPBIN /EXPORTS <YourDll>' on your DLLs to read how
class method names are mangled...

HTH,
Giovanni



 |  Next  |  Last
Pages: 1 2
Prev: Loading numbered files in sequence
Next: Which inclue file to use to use the winapi. Not using stdafx or MFC.