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…

Hi,

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 ?

Jean-Claude

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.

[i]libp3framework.lib
libpanda.lib
libpandafx.lib
libpandaexpress.lib
libp3dtool.lib
libp3dtoolconfig.lib
libp3pystub.lib
libp3direct.lib

libpandatoolbase.lib
ode.lib
libpandaode.lib
libprogbase.lib
libp3direct.lib
libcvscopy.lib
libdxf.lib
libflt.lib
libimagebase.lib
libobjegg.lib

libconverter.lib libpstatserver.lib

libp3pystub.lib
libpandaskel.lib
libpandaphysx.lib
libpandaphysics.lib

libpandaegg.lib
libpandadx9.lib
libpandaai.lib
libp3vision.lib
libp3heapq.lib

libp3direct.lib
libp3ptloader.lib
libp3windisplay.lib

libcvscopy.lib libdxf.lib libflt.lib
[/i]

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

Jean-Claude

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.

Cheers

Jean-Claude

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)…