CardMaker related to BamReader ??? Issue with Intel Compiler

Hi guys,

I’m experiencing a problem while compiling a short C++ program in Release mode.

Nailing it down, it appears that the issue is related to a single (stupid) line in the C++ code ie merely :

CardMaker cm(“ground”);

indeed when adding it to my code, here is the compile message I get :

1>jctut.obj : error LNK2001: unresolved external symbol “private: static class TypeHandle PandaNode::BamReaderAuxDataDown::_type_handle” (?_type_handle@BamReaderAuxDataDown@PandaNode@@0VTypeHandle@@A)

1>jctut.obj : error LNK2001: unresolved external symbol “private: static class TypeHandle BamReaderAuxData::_type_handle” (?_type_handle@BamReaderAuxData@@0VTypeHandle@@A)

I’m puzzled, what kind of library is missing ??

The load I’m using is Panda3D-2011.01.23-107
under intel Compiler on IDE VisualStudio_2008 + Microsoft SDK 7.1

Any clue ?

BTW. When using a Panda 1.7.1 debug version I fully compiled from scratch, everything works perfectly in debug mode,
… but this damned CardMaker(“name”) generates the same link error in Release mode…

Addendum 1: This behaviour is showing up while using Intel C++ compiler integrated in Visual Studio 2008.

Addendum 2: Just tried to compile it with Microsoft Compiler, the issue doesn’t pop up.

Apparently the issue is tied to Intel Compiler + PANDA…


Just wondering if anybody here is using Intel C++ compiler?

Since this compiler comes with SSE4 sets generation capabilities + optimized IPP (Intel Performance Primitives) + extras, I’m using it quite a bit on my others projects. So in terms of optimisation this is really a must!

With Panda3D:

(1) Easy approach: Tried to compile some C++ programs using Panda 1.7.1 last build, in most cases it works, but in others the compiler shouts about missing library entries. (see my previous post)

(2) Tried to recompile Panda3D from scratch: with success using plain Microsoft VS2008 (both in release and debug modes). Didn’t manage using Intel C++…
I guess this comes from the fact that the auto generated makefile is not understandable by this compiler.

Any hints ?


Can you show a list of the libraries you’re linking with?

Dag rdb,

Sure, here is the list of the libs I’m linking with on Release mode. Certainly more than needed.



libconverter.lib libpstatserver.lib




libcvscopy.lib libdxf.lib libflt.lib

This works ok if using plain Microsoft C++ compiler, but triggers the “missing” xternal symbol as soon as I try to compile and link it with Intel C++ (integrated in Visual Studio).

error LNK2001: unresolved external symbol “private: static class TypeHandle PandaNode::BamReaderAuxDataDown::_type_handle” (?_type_handle@BamReaderAuxDataDown@PandaNode@@0VTypeHandle@@A)

see post 1…

For a strange reason, the issue shows up as soon as I use the instruction: CardMaker cm(“ground”);

Having said so: now strange enough, from time to time when switching back from compiled Microsoft obj modules to Intel linker, it works:

ie. weird behaviour :

1>jctut.obj : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
1>Generating code
1>Finished generating code
1>Embedding manifest… (Microsoft VC++ Environment)
1>jctut - 0 error(s), 0 warning(s), 0 remark(s)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

I tend to suspect that the issue is somewhere related to some Panda names/symbols generation while Intel Compiler is doing (or not) its job.

Dank je wel for some hints


Bonsoir jean-claude,

Woah, that’s way too much. You’ll probably only need the first eight (and you probably don’t need libpandafx.lib), and maybe a few for specific functionality (if you use ODE or so).

I think I might know what the problem is. I can’t commit a fix for you because the CVS server is down at the moment, and I can’t make a build for you because the buildbot is not functional as a consequence of the CVS server being down.

But I think that in panda/src/pgraph/pandaNode.h, the following line:

class BamReaderAuxDataDown : public BamReaderAuxData {

Should say this instead:

class EXPCL_PANDA_PGRAPH BamReaderAuxDataDown : public BamReaderAuxData {

to properly export/import the symbols.

Hey well done!

You’re right.

I just modified the .h file in the include dir, and the Intel compiler is not shouting any longer!

BTW. I had to do the same in bamReader.h

class BamReaderAuxData : public TypedReferenceCount {
class EXPCL_PANDA_PGRAPH BamReaderAuxData : public TypedReferenceCount {

To be remembered for a new build.



Well, there is another side effect apparently tied to Intel C++ usage.

Although everything now compiles and links properly, at run time there is an error that has never shown before:

invalid operation for geom in locked space (..\..\ode\src\collision_kernel.cpp:703)

Funny, this error doesn’t show up when compiling with plain Microsoft VS2008 compiler.

BTW. Why is it needed to have ode.lib as a link library? my first understanding was that libpandaode.lib would fit the bill by itself (since it includes ode code)…