ARX COM server linker problem

[davidm_adn]

Please does anyone have 10 minutes to see if they can build this minimal project?

ArxProject is an arx project which was set up as a COM server using ATL, as recommended.
LibProject is a static lib with one exported class with one member function, and is a dependency of the arx project.

The lib class' member function declares an instance of AcGePoint3dArray, and the OnInitApp function in the arx also declares an instance of an AcGePoint3dArray.  If I call the lib class' member function from the arx, I get lnk2005 and lnk1169 saying that AcGePoint3dArray is already defined.  It seems to be a problem with axdb.lib but I can't tell what I can do about it.  I have tried getting it to search axdb.lib before the lib project .lib but the linker error remains, but the other way around if you get my meaning.

This only happens if the arx project is set up as a COM server using ATL.

Visual Studio 2008

Version 9.0.21022.8 RTM
Microsoft .NET Framework
Version 3.5 SP1
ObjectARX 2010 (axdb.lib dated 22:02 08/02/09)

Thanks for any help.

[owenwengerd]

Are you familiar with the "_DEBUG workaround"? If not, use the ARX wizard to create a new project and select that option int he wizard. Your projects are both including CRT headers with _DEBUG defined, which will not work if you interface with the Releace CRT that AutoCAD uses. In addition, your LibProject is set for the Debug DLL CRT library, which cannot be used in AutoCAD's process. I'm not sure that these problems are the reason for your linker error, but they could be. If fixing the project settings doesn't help, I would try just setting axdb.lib to be ignored in your project's linker options and see if everything still links.

[davidm_adn]

Thank you for your reply Owen, unfortunately it's nothing to do with the _DEBUG settings, I had tried that previously.

I had also already tried ignoring axdb.lib (I think I read that on another thread here somewhere) but not surprisingly it comes up with a lot of missing symbols.

This must be something about the arx wizard when using COM because I do this kind of thing all the time (with libs and arx's), and I haven't seen this problem before.  But I've never built a COM arx project before this.  I have compared the project files of a COM and non-COM arx and apart from the obvious additional includes etc I can't see anything different about the settings.  I do wonder about that axdb.lib.

Thanks for trying, I appreciate it.

[owenwengerd]

Try adding the following to your stadafx.h files prior to any ARX includes:

#define AC_GEDLL_H
#define GE_DLLEXPIMPORT
#define GX_DLLEXPIMPORT

[davidm_adn]

Thanks Owen, but... no banana.  I tried putting those in various places in stdafx.h, even right at the top but with no luck.

Here is a clue maybe, if I knock out #include <AtlCom.h> from stdafx.h, everything compiles, but it precludes adding dynamic properties to the project.  As far as I know, that is a Microsoft header file, not an Autodesk one.

[owenwengerd]

I tested the Release build of your sample project, and it compiles and links without error after I applied the fixes.

[davidm_adn]

Well that is strange.  Where *exactly* did you put those 3 #defines?  I am guessing just before #include "arxHeaders.h".  Maybe you can post your stdafx.h.

Did you knock out #include <AtlCom.h> like I said?  That will certainly make it compile and link but it makes the project unusable for what I need.

[owenwengerd]

I've attached the four files I modified.

[davidm_adn]

Thank you Owen.  The difference was, I hadn't kept the /NODEFAULTLIB:"axdb.lib" in as well as adding the additional #includes you suggested (where did you find out about that?  I would like to read up on it).

It compiles and links but with these warnings, do you think they are significant?

acrxEntryPoint.obj : warning LNK4049: locally defined symbol ??1?$AcArray@VAcGePoint3d@@V?$AcArrayMemCopyReallocator@VAcGePoint3d@@@@@@QEAA@XZ (public: __cdecl AcArray<class AcGePoint3d,class AcArrayMemCopyReallocator<class AcGePoint3d> >::~AcArray<class AcGePoint3d,class AcArrayMemCopyReallocator<class AcGePoint3d> >(void)) imported
1>acrxEntryPoint.obj : warning LNK4049: locally defined symbol ??0?$AcArray@VAcGePoint3d@@V?$AcArrayMemCopyReallocator@VAcGePoint3d@@@@@@QEAA@HH@Z (public: __cdecl AcArray<class AcGePoint3d,class AcArrayMemCopyReallocator<class AcGePoint3d> >::AcArray<class AcGePoint3d,class AcArrayMemCopyReallocator<class AcGePoint3d> >(int,int)) imported

[owenwengerd]

You don't need to worry about the warnings, as long as they don't result in errors. The changes I suggested were just the result of looking at the relevant ObjectARX SDK files to see why the error occurred, then working around the problem by removing the offending __declspec(dllimport) directive via those preprocessor macros. There's no guarantee that this won't cause problems if you use other axdb.lib functions in the future, but if it works for this case, great.

[davidm_adn]

OK thank you, I understand.

Unfortunately calling any member of AcGePoint3dArray in the arx module which is not called in the lib, results in an unresolved external for that call, presumably because it needs axdb.lib for that.

eg, calling in the InitApp

AcGePoint3dArray pts;
AcGePoint3d pt;
pts.append (pt); // AcGePoint3d::append is also called in the lib, so this is fine and I guess the arx gets the symbol from there
printf ("%f", pts[0].x); // the [] operator is not called in the lib, so this causes a linker error

It seems to do this for anything using the AcArray template class.  Correction: AcGePoint2dArray and AcGePoint3dArray only.  A DUMPBIN /exports on axdb.lib reveals that this lib exports those two classes.  eg AcGeIntArray is fine.  I wonder if AcGePoint2dArray and AcGePoint3dArray are also exported from another ObjectARX lib.

[davidm_adn]

I never got this resolved as I had hoped, but I got around the problem by creating a separate arx (as a COM server with ATL of course) and put all my dynamic properties code into that.   As this arx uses AcGePoint2dArray and AcGePoint3dArray, I cannot link with any libs using those classes either, so I communicate with my other modules using LoadLibrary and GetProcAddress.  It's ugly but it works.

I had a suggestion from Autodesk to remove a few exports from axdb.lib to resolve the conflict but I think going forward it's probably not a great idea to mess with a 3rd party SDKs, one day somebody else will pick this project up and wonder what is going on.

Thank you Owen for trying to solve this, I really appreciate your efforts.  I am now just posting what I eventually did, so maybe someone else can benefit from my workaround.

[owenwengerd]

I'm glad you found a workaround. I think the best solution is for Autodesk to fix axdb.lib, and hopefully they will some day.