Game Development Community

HEAD version still has problems

by David Dougher · in Torque Game Engine · 05/14/2002 (3:11 pm) · 29 replies

I make it a habit of downloading a complete HEAD version about once a week a compiling it just to make sure that the errors that I am encountering I caused. For the past couple of weeks that has not been the case as I have found errors in virtually every download somewhere. I just downloaded the latest HEAD version a few minutes ago and compiled it. There have been no reported changes to this version for a while so I can only conclude that when people are making changes lately they are not doing a Rebuild All to make sure that their work isn't effecting other parts of the code (i.e. the tools)

Please be a bit more careful to check that your changes work everywhere.

Here's todays Link failures.

--------------------Configuration: max2dtsExporter Max3 - Win32 Release--------------------
Compiling resources...
Compiling...
exportUtil.cc
main.cc
maxUtil.cc
NvTriStripObjects.cc
NvVertexCache.cc
SceneEnum.cc
sequence.cc
ShapeMimic.cc
skinHelper.cc
stripper.cc
translucentSort.cc
Linking...
engine.lib(netStringTable.obj) : error LNK2005: "unsigned int __cdecl GameAddTaggedString(char const *)" (?GameAddTaggedString@@YAIPBD@Z) already defined in maxUtil.obj
engine.lib(netStringTable.obj) : warning LNK4006: "unsigned int __cdecl GameAddTaggedString(char const *)" (?GameAddTaggedString@@YAIPBD@Z) already defined in maxUtil.obj; second definition ignored
Creating library ../tools/out.VC6.RELEASE/max2dtsExporter.lib and object ../tools/out.VC6.RELEASE/max2dtsExporter.exp
../tools/max2dtsExporter.dle : fatal error LNK1169: one or more multiply defined symbols found
Error executing link.exe.

max2dtsExporter.dle - 2 error(s), 1 warning(s)
--------------------Configuration: max2dtsExporter Max3 - Win32 Debug--------------------
Compiling resources...
Compiling...
exportUtil.cc
main.cc
maxUtil.cc
NvTriStripObjects.cc
NvVertexCache.cc
SceneEnum.cc
sequence.cc
ShapeMimic.cc
skinHelper.cc
stripper.cc
translucentSort.cc
Linking...
engine_DEBUG.lib(netStringTable.obj) : error LNK2005: "unsigned int __cdecl GameAddTaggedString(char const *)" (?GameAddTaggedString@@YAIPBD@Z) already defined in maxUtil.obj
engine_DEBUG.lib(netStringTable.obj) : warning LNK4006: "unsigned int __cdecl GameAddTaggedString(char const *)" (?GameAddTaggedString@@YAIPBD@Z) already defined in maxUtil.obj; second definition ignored
Creating library ../tools/out.VC6.DEBUG/max2dtsExporter_DEBUG.lib and object ../tools/out.VC6.DEBUG/max2dtsExporter_DEBUG.exp
../tools/max2dtsExporter_DEBUG.dle : fatal error LNK1169: one or more multiply defined symbols found
Error executing link.exe.

max2dtsExporter_DEBUG.dle - 2 error(s), 1 warning(s)
--------------------Configuration: max2dtsExporter Max4 - Win32 Release--------------------
Compiling resources...
Compiling...
exportUtil.cc
main.cc
maxUtil.cc
NvTriStripObjects.cc
NvVertexCache.cc
SceneEnum.cc
sequence.cc
ShapeMimic.cc
skinHelper.cc
stripper.cc
translucentSort.cc
Linking...
engine.lib(netStringTable.obj) : error LNK2005: "unsigned int __cdecl GameAddTaggedString(char const *)" (?GameAddTaggedString@@YAIPBD@Z) already defined in maxUtil.obj
engine.lib(netStringTable.obj) : warning LNK4006: "unsigned int __cdecl GameAddTaggedString(char const *)" (?GameAddTaggedString@@YAIPBD@Z) already defined in maxUtil.obj; second definition ignored
Creating library ../tools/out.VC6.RELEASE/max2dtsExporter.lib and object ../tools/out.VC6.RELEASE/max2dtsExporter.exp
exportUtil.obj : error LNK2001: unresolved external symbol "public: virtual char * __thiscall ClassDesc::GetRsrcString(long)" (?GetRsrcString@ClassDesc@@UAEPADJ@Z)
main.obj : error LNK2001: unresolved external symbol "public: virtual char * __thiscall ClassDesc::GetRsrcString(long)" (?GetRsrcString@ClassDesc@@UAEPADJ@Z)
sequence.obj : error LNK2001: unresolved external symbol "public: virtual char * __thiscall ClassDesc::GetRsrcString(long)" (?GetRsrcString@ClassDesc@@UAEPADJ@Z)
skinHelper.obj : error LNK2001: unresolved external symbol "public: virtual char * __thiscall ClassDesc::GetRsrcString(long)" (?GetRsrcString@ClassDesc@@UAEPADJ@Z)
sequence.obj : error LNK2001: unresolved external symbol "public: virtual long __thiscall ParamBlockPLCB::Execute(int,unsigned long,unsigned long,unsigned long)" (?Execute@ParamBlockPLCB@@UAEJHKKK@Z)
../tools/max2dtsExporter.dle : fatal error LNK1120: 2 unresolved externals
Error executing link.exe.

max2dtsExporter.dle - 7 error(s), 1 warning(s)
--------------------Configuration: max2dtsExporter Max4 - Win32 Debug--------------------
Compiling resources...
Compiling...
exportUtil.cc
main.cc
maxUtil.cc
NvTriStripObjects.cc
NvVertexCache.cc
SceneEnum.cc
sequence.cc
ShapeMimic.cc
skinHelper.cc
stripper.cc
translucentSort.cc
Linking...
engine_DEBUG.lib(netStringTable.obj) : error LNK2005: "unsigned int __cdecl GameAddTaggedString(char const *)" (?GameAddTaggedString@@YAIPBD@Z) already defined in maxUtil.obj
engine_DEBUG.lib(netStringTable.obj) : warning LNK4006: "unsigned int __cdecl GameAddTaggedString(char const *)" (?GameAddTaggedString@@YAIPBD@Z) already defined in maxUtil.obj; second definition ignored
Creating library ../tools/out.VC6.DEBUG/max2dtsExporter_DEBUG.lib and object ../tools/out.VC6.DEBUG/max2dtsExporter_DEBUG.exp
exportUtil.obj : error LNK2001: unresolved external symbol "public: virtual char * __thiscall ClassDesc::GetRsrcString(long)" (?GetRsrcString@ClassDesc@@UAEPADJ@Z)
main.obj : error LNK2001: unresolved external symbol "public: virtual char * __thiscall ClassDesc::GetRsrcString(long)" (?GetRsrcString@ClassDesc@@UAEPADJ@Z)
sequence.obj : error LNK2001: unresolved external symbol "public: virtual char * __thiscall ClassDesc::GetRsrcString(long)" (?GetRsrcString@ClassDesc@@UAEPADJ@Z)
skinHelper.obj : error LNK2001: unresolved external symbol "public: virtual char * __thiscall ClassDesc::GetRsrcString(long)" (?GetRsrcString@ClassDesc@@UAEPADJ@Z)
sequence.obj : error LNK2001: unresolved external symbol "public: virtual long __thiscall ParamBlockPLCB::Execute(int,unsigned long,unsigned long,unsigned long)" (?Execute@ParamBlockPLCB@@UAEJHKKK@Z)
../tools/max2dtsExporter_DEBUG.dle : fatal error LNK1120: 2 unresolved externals
Error executing link.exe.

max2dtsExporter_DEBUG.dle - 7 error(s), 1 warning(s)

Please note, I'm not saying that there isn't an easy fix for these errors, what I AM saying is that when you check in, that every module should still compile and link properly after your checkin. It's one thing to loose a bug in the HEAD version - that's the risk you take when you use it. It's another thing when after you check in, things won't even compile.

'Nuff said. Good Hunting!
David Dougher's profile picture
Torque Owner David Dougher
Pariah Games

About the author

Owner - Pariah Games, Adjunct Professor - Bristol Community College, Mentor - Game Design - Met School Newport, Mentor - Game Design - Met School Providence

Recent Threads

  • Need help to finish your game?
  • System requirements
  • Equivalent of #ifdef in TorqueScript ?
  • AFX 1.1.3 Bugs
  • TGEA 1.7.1 and DirectX Nov. 2008 - broken
    • NextNext Thread
    PrevPrevious Thread
    More from Torque Game Engine
    Page «Previous 1 2

    Torque 3D Owner Joel Baxter
    #1
    05/14/2002 (5:28 pm)
    I'll see what I can do about those. The ParamBlockPLCB error, BTW, is not directly a problem with TGE; see changelog.txt for one solution to that, although I thought I remembered seeing a more elegant solution posted around here somewhere.

    Torque 3D Owner Joel Baxter
    #2
    05/14/2002 (6:11 pm)
    OK, I did a little update to maxUtil.cc that should take care of any errors left after you fix that VC++ header file problem.

    Torque Owner David Dougher
    Pariah Games
    #3
    05/15/2002 (11:21 am)
    Thanks for the updates Joel.

    I downloaded the latest version and your updates and it fixed all but the header file error you mentioned. I haven't found the changelog.txt file fix that you mentioned - the last entry in the file I just downloaded is dated 3/26/02. I also looked in the CVS Change List and didn't see it there either - although I may have missed it easily.

    Torque 3D Owner Joel Baxter
    #4
    05/15/2002 (11:31 am)
    changelog.txt in the root torque directory, it has a line like this:
    Quote:There are some problems building the Max 4 project, it works fine with VC7, but generates link errors with VC6. This has to do with a difference in the way the compilers define INT_PTR (a windows typedef). You can get it to link under VC6 by redefining INT_PTR to an int (instead of a long) in the VC6 header BASETSD.H. I'm not really sure what the real solution is.

    Torque Owner Desmond Fletcher
    fletcher
    #5
    05/15/2002 (12:08 pm)
    I did that Joel and still get the link errors.

    1. Just downloaded the HEAD
    2. Changed INT_PTR to int in the VC6 basestd.h
    3. Changed project settings to maxsdk40 for both release and debug versions

    Linking...
    Creating library ../tools/out.VC6.DEBUG/max2mapExporter_DEBUG.lib and object ../tools/out.VC6.DEBUG/max2mapExporter_DEBUG.exp
    main.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall ClassDesc::AddInterface(class FPInterface *)" (?AddInterface@ClassDesc@@UAEXPAVFPInterface@@@Z)
    main.obj : error LNK2001: unresolved external symbol "public: virtual class FPInterface * __thiscall ClassDesc::GetInterface(class Interface_ID)" (?GetInterface@ClassDesc@@UAEPAVFPInterface@@VInterface_ID@@@Z)
    main.obj : error LNK2001: unresolved external symbol "public: virtual class FPInterface * __thiscall ClassDesc::GetInterface(char *)" (?GetInterface@ClassDesc@@UAEPAVFPInterface@@PAD@Z)
    main.obj : error LNK2001: unresolved external symbol "public: virtual char * __thiscall ClassDesc::GetRsrcString(int)" (?GetRsrcString@ClassDesc@@UAEPADH@Z)
    ../tools/max2mapExporter_DEBUG.dle : fatal error LNK1120: 4 unresolved externals

    Torque Owner David Dougher
    Pariah Games
    #6
    05/15/2002 (3:05 pm)
    I have a different question. According to the requirements for compiling torque under windows you are expected to have Visual C++ 6 with Service Pack 5. When did the requirements change to Visual C++ 7? It seems to me that somebody compiled under VC++7 and then updated the CVS with the changes, including changes which are incompatible with the requirements for GG's customers.

    I personally have no desire to go to VC++7. It is not ready for "primetime". Nor do I have any desire to go to Visual C++ .NET anytime soon.

    In my opinion, all checkins to the CVS should conform to the requirements placed on the customers, that is, they should be compiled under Visual C++ 6 SP5. No one should be required to alter Microsoft headers to get the software to work.

    If it works under VC++7 or Visual Net or Borland that's very nice, but it shouldn't be allowed as a checkin.

    There was an earlier version of this code which did not have this problem. Perhaps we should roll back the code to that point, and make any follow-up changes using a VC++6 system and place those in CVS.

    Don't mean to sound harsh but I think that this was really a major faux pas. I can see how it happened but for the people who are allowed to update the source that everybody has to use you WILL be held to a higher standard. (Which is why I'm glad I'm not allowed to do check-ins. I'm afraid of heights!)

    Torque Owner Badguy
    #7
    05/15/2002 (3:13 pm)
    shrug,
    the head is not vc7 only ..
    I have no problems compiling with my stocker vc6
    no service pack.

    Im not sure why some have this basestd.h define issue, I do not.

    Torque Owner David Dougher
    Pariah Games
    #8
    05/15/2002 (3:53 pm)
    Here's some commentary from the Microsoft file in question. The name really is BASETSD.H not BASESTD.H for those who are keeping score :)

    Note the fact that there was a specific reason that the INT_PTR is set to a long value. There are other pieces of code which depend on it having the length it does.
    to quote from the file itself...

    "
    //
    // The INT_PTR is guaranteed to be the same size as a pointer. Its
    // size will change with pointer size (32/64). It should be used
    // anywhere that a pointer is cast to an integer type. UINT_PTR is
    // the unsigned variation.
    //
    // HALF_PTR is half the size of a pointer it intended for use with
    // within structure which contains a pointer and two small fields.
    // UHALF_PTR is the unsigned variation.
    //

    #ifdef _WIN64

    typedef __int64 INT_PTR, *PINT_PTR;
    typedef unsigned __int64 UINT_PTR, *PUINT_PTR;

    #define MAXINT_PTR (0x7fffffffffffffffI64)
    #define MININT_PTR (0x8000000000000000I64)
    #define MAXUINT_PTR (0xffffffffffffffffUI64)

    typedef unsigned int UHALF_PTR, *PUHALF_PTR;
    typedef int HALF_PTR, *PHALF_PTR;

    #define MAXUHALF_PTR (0xffffffffUL)
    #define MAXHALF_PTR (0x7fffffffL)
    #define MINHALF_PTR (0x80000000L)
    .
    .
    more code
    .
    .
    typedef long INT_PTR, *PINT_PTR;
    typedef unsigned long UINT_PTR, *PUINT_PTR;

    #define MAXINT_PTR (0x7fffffffL)
    #define MININT_PTR (0x80000000L)
    #define MAXUINT_PTR (0xffffffffUL)

    typedef unsigned short UHALF_PTR, *PUHALF_PTR;
    typedef short HALF_PTR, *PHALF_PTR;

    #define MAXUHALF_PTR 0xffff
    #define MAXHALF_PTR 0x7fff
    #define MINHALF_PTR 0x8000

    #define HandleToUlong( h ) ((ULONG) (h) )
    #define PtrToUlong( p ) ((ULONG) (p) )
    #define PtrToLong( p ) ((LONG) (p) )
    #define PtrToUshort( p ) ((unsigned short) (p) )
    #define PtrToShort( p ) ((short) (p) )

    #endif

    and so on....

    I did clean up a couple of typos in the Microsoft comments to make them readable, but as you can see the INT_PTR shouldn't be changed. In fact, there is a good chance that it is actually wrong in VC++7 if MS did change it.

    Now I have a suspicion that the reason that some people are having a problem and others are not is that the order the libraries are being searched in may be different. Could someone who is NOT having the problem post the order of their include file paths in Visual C++? Look in Tools -> Options -> Directories under "Show include files" and list the file paths in the order to be searched?

    Thanks.

    Torque Owner Badguy
    #9
    05/15/2002 (4:02 pm)
    sure :
    C:\SDK\DXSDK\INCLUDE
    C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE
    C:\Program Files\Microsoft Visual Studio\VC98\MFC\INCLUDE
    C:\Program Files\Microsoft Visual Studio\VC98\ATL\INCLUDE

    C:\SDK\DXSDK\LIB
    C:\Program Files\Microsoft Visual Studio\VC98\LIB
    C:\Program Files\Microsoft Visual Studio\VC98\MFC\LIB

    Torque Owner Shawn
    #10
    05/15/2002 (4:44 pm)
    *SEEMS* to be compiling fine. Did a full clean and rebuild with latest HEAD.

    D:\APIS\DXSDK\INCLUDE
    C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE
    C:\Program Files\Microsoft Visual Studio\VC98\MFC\INCLUDE
    C:\Program Files\Microsoft Visual Studio\VC98\ATL\INCLUDE
    C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\VC98\INCLUDE\GL
    C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\VC98\INCLUDE\GLUT
    C:\3DSMAX4\MAXSDK\INCLUDE

    Torque Owner David Dougher
    Pariah Games
    #11
    05/15/2002 (5:05 pm)
    Well here's one to add to your list of things that can mess up your day.

    We recently switched to Microsoft Active Directory in our shop. In the process it created all new accounts for each person. We rolled the contents of our old accounts over to the new ones but we didn't realize that it includes eliminating the registry entries (which are still in the old accounts but can't be rolled over) and basically changing my VC++ settings back to their original defaults - I don't even have DXSDK as a path in my system now.

    I'm going to try to compile on my home system - which still has all its original paths and compare it with the two lists you guys have provided and see if between the four I can come up with a minimal set that might fix this for everybody.

    My first thought is that if DXSDK isn't the first entry you might not get very far... In fact I'm amazed that the system compiled and worked at all without the DX entries - it must be using the old ones from WIN2K.

    Also, duh -- there is no path links to the MAXSDK, except those contained in the dsp files.

    Thanks for all the info, guys - I'll post when I've reached home and had a look.

    Torque Owner Desmond Fletcher
    fletcher
    #12
    05/15/2002 (5:06 pm)
    Shawn, BAdGuy are the maxsdk and dxsdk required? And if so, how do I add them?

    And, David:1, Desmond:0 Re: Basetsd.h (I knew that :)

    Torque Owner Badguy
    #13
    05/15/2002 (5:14 pm)
    the dx for this engine is pulled using project setting like the maxsdk..
    so you wont need it in the path for the engine to compile.

    But like you say , it could be the fact that the DX sdk is listed for me first to stop other project issue's,
    That could save me from the BASETSD.H (heh tx) error.

    So if you are having this error ..
    try to put the DX sdk as your first path.

    simply download it from microsoft and install it.
    then go and add the paths there.
    (which they should do for ya)

    Torque Owner Desmond Fletcher
    fletcher
    #14
    05/15/2002 (5:19 pm)
    k, I'll give it a whirl , thanks

    Torque Owner Badguy
    #15
    05/15/2002 (5:23 pm)
    nod, good luck :)

    Torque Owner David Dougher
    Pariah Games
    #16
    05/16/2002 (4:33 am)
    Didn't get home until after 10 pm. Long drive from Mass. to RI. Just to fill interested parties in. I updated from the CVS and compiled on my home system and - surprise! No errors. I checked my listing and after comparing it with the ones provided and eliminating anything that wasn't in all the working configurations I came to the conclusion that the common element was DXSDK as the first entry.

    I'll try recompiling when I get back to work today on the machine that failed. I plan on adding just that entry to the top of the path chain and then if all problems go away I'll repost, and I think we can raise the tombstone on this issue.

    Torque Owner David Dougher
    Pariah Games
    #17
    05/16/2002 (8:21 am)
    OK this one is history. After adding the path to DXSDK as the first path entry I recompiled with nothing but the usual warnings.

    So the solution does not require modifying the Microsoft BASETSD.H header file. Instead, simply move the DXSDK to be the first entry in the path and the problem will go away.

    Now I would like to thank...
    Joel Baxter - for fixing all the other problems and pointing out the area where the last one was hiding.

    Desmond Fletcher
    Badguy
    & Shawn
    For help, constructive suggestions, and those file listings.

    We now return you to your regularly scheduled programming...

    Torque Owner Desmond Fletcher
    fletcher
    #18
    05/16/2002 (9:53 am)
    Cool, but first: I went to MS last night to locate the DXSDK and found dx8a_sdk. Is this the required sdk? And could you give a quick discription of how to add it to VC6?

    OK, think I found the right SDK. It created the Program Files/Microsoft SDK directory. Includes the DirectX8.1 SDK I believe.

    Under tools/options/directories/include, VC6 now looks like:

    C:\Program Files\Microsoft SDK\include
    C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE
    C:\Program Files\Microsoft Visual Studio\VC98\MFC\INLCUDE
    C:\Program Files\Microsoft Visual Studio\VC98\ATL\INLCUDE

    Does this seem right?
    ----------------------------------------
    Nope, I'm still doing something wrong:

    Creating library ../tools/out.VC6.DEBUG/max2mapExporter_DEBUG.lib and object ../tools/out.VC6.DEBUG/max2mapExporter_DEBUG.exp
    main.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall ClassDesc::AddInterface(class FPInterface *)" (?AddInterface@ClassDesc@@UAEXPAVFPInterface@@@Z)
    main.obj : error LNK2001: unresolved external symbol "public: virtual class FPInterface * __thiscall ClassDesc::GetInterface(class Interface_ID)" (?GetInterface@ClassDesc@@UAEPAVFPInterface@@VInterface_ID@@@Z)
    main.obj : error LNK2001: unresolved external symbol "public: virtual class FPInterface * __thiscall ClassDesc::GetInterface(char *)" (?GetInterface@ClassDesc@@UAEPAVFPInterface@@PAD@Z)
    main.obj : error LNK2001: unresolved external symbol "public: virtual char * __thiscall ClassDesc::GetRsrcString(int)" (?GetRsrcString@ClassDesc@@UAEPADH@Z)
    ../tools/max2mapExporter_DEBUG.dle : fatal error LNK1120: 4 unresolved externals

    Torque Owner David Dougher
    Pariah Games
    #19
    05/16/2002 (11:35 am)
    If you install the Microsoft DirectX SDK taking the standard defaults it should create a series of subdirectories beginning at the root of your C:\ drive and with a root entry of DXSDK (i.e. C:\DXSDK)

    Note: If you have any earlier versions of DirectX you should remove them. The current default is different than the old one (it was mssdk) and you would be wasting 130MB+ on your disk.

    Based on this install the paths that I found as essential were as follows:

    These are the basic "Include Files" entries (DSHOWIDL might be optional but I included it for completeness)

    C:\DXSDK\INCLUDE
    C:\DXSDK\INCLUDE\DSHOWIDL
    C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE
    C:\Program Files\Microsoft Visual Studio\VC98\MFC\INCLUDE
    C:\Program Files\Microsoft Visual Studio\VC98\ATL\INCLUDE


    Under "Library Files" you need

    C:\DXSDK\LIB
    C:\Program Files\Microsoft Visual Studio\VC98\LIB
    C:\Program Files\Microsoft Visual Studio\VC98\MFC\LIB

    With these settings I can compile without error using the latest HEAD release using VC++6 with Service Pack 5. If you change any of these things your mileage may vary :)

    Torque Owner Desmond Fletcher
    fletcher
    #20
    05/16/2002 (12:50 pm)
    Evidently I'm not getting the right one. Do you have a link to the SDK?

    I went to MS http://www.microsoft.com/msdownload/platformsdk/sdkupdate/
    to get the DirectX8.1 SDK and it installed but isn't placed in C:\DXSDK as you suggest it should be.
    Page «Previous 1 2