Compile errors on mdk 10.1 official (gcc 3.4.1)

#1 I am getting the exact same issue.

I'm running Fedora Core 3 with gcc3 version 3.4.2.

As you stated, I handled the resManager error by moving resManager and resDictionary before the resource wrapper class in resManager.h

From my initial look at the event.h error, what is causing the error is that the code attempts to use dereference operators and address-of operators within an enum initialization.

It would be my guess that the GG devs are using an older version of gcc3 (the #ifdefs in the code indicate that their version is at least v3.1) with less strict adherence to standards.

Has anyone had success with a compiler option that relaxes the standards-checking?

Thanks,

Marc

#2 I did a little searching on the net and found that a temporary solution is to use the offsetof macro. I added the following lines to the event.h file and got passed this error only to run into another one. =/

// CRC - added new macro so that offset uses g++ offsetof macro. This
// will only work for PODs and not classes.
#if defined(TORQUE_COMPILER_GCC) && (__GNUC__ > 3) || ((__GNUC__ == 3) && (__GNUC_MINOR__ >= 4))
#define Offset(m,T) offsetof(T, m)
#else
#define Offset(x, cls) ((dsize_t)((const char *)&(((cls *)0)->x)-(const char *)0))
#endif
#endif

I am using 3.4.2 for compilation hence the check for minor version of 4.

As you can see in the code comment that this macro only works for PODs and not classes. I found this solution at this web site:
gcc website

Chris

With some more testing the replacement of the macro does not work. I had to go in and change the code itself to use the offsetof macro instead of the Offset macro. The changes are now:
/// Byte offset to payload of a PacketReceiveEvent
PacketReceiveEventHeaderSize = offsetof(struct PacketReceiveEvent, data[0]),

/// Byte offset to payload of a ConnectedReceiveEvent
ConnectedReceiveEventHeaderSize = offsetof(struct ConnectedReceiveEvent, data[0]),

/// Byte offset to payload of a ConsoleEvent
ConsoleEventHeaderSize = offsetof(struct ConsoleEvent, data[0])

These lines produce the following warnings, but compilation contiues. Use at your own risk!

./platform/event.h:147: warning: invalid access to non-static data member 'PacketReceiveEvent::data' of NULL object
./platform/event.h:147: warning: (perhaps the 'offsetof' macro was used incorrectly)
./platform/event.h:150: warning: invalid access to non-static data member 'ConnectedReceiveEvent::data' of NULL object
./platform/event.h:150: warning: (perhaps the 'offsetof' macro was used incorrectly)
./platform/event.h:153: warning: invalid access to non-static data member 'ConsoleEvent::data' of NULL object
./platform/event.h:153: warning: (perhaps the 'offsetof' macro was used incorrectly)

*** Final update ***
downloaded nasm from sourceforge and I was able to compile Torque and run the FPS demo with only the following errors printed on the command line after quiting the game:

Fatal: (sim/sceneObject.cc @ 825) Error, a GameBase (b5703688) isn't properly out of the bins!

Fatal: (sim/sceneObject.cc @ 825) Error, a GameBase (b7d3c108) isn't properly out of the bins!

Fatal: (sim/sceneObject.cc @ 825) Error, a GameBase (b697aeb8) isn't properly out of the bins!

Fatal: (sim/sceneObject.cc @ 825) Error, a GameBase (b6692738) isn't properly out of the bins!

Fatal: (sim/sceneObject.cc @ 825) Error, a GameBase (b697bc78) isn't properly out of the bins!

Fatal: (sim/sceneObject.cc @ 825) Error, a GameBase (b69488c8) isn't properly out of the bins!

Fatal: (sim/sceneObject.cc @ 825) Error, a GameBase (b6946958) isn't properly out of the bins!

Fatal: (sim/sceneObject.cc @ 825) Error, a GameBase (b6693318) isn't properly out of the bins!

Other than this, everything worked fine.

#3 I was finally able to get everything to work with no additional errors.

Basically, gcc3.4.2 *really* doesn't like the nonconstant initialization of the enum values. My solution was to get rid of the enum entirely, and store the "Offset"-initialized event header sizes as "static const U32" variables in each of the affected structs (PacketReceiveEvent, ConnectedReceiveEvent, and ConsoleEvent). There's really no need for an independent enum, anyways.

As I said, everything compiles fine at this point. I'll submit this as a patch shortly.

-Marc

#4 FYI, it looks like a patch for this and other gcc 3.4 issues was already submitted in January and is currently reflected in HEAD.

I gotta remember to check the change page more regularly. =)

-Marc

#5 Thanks for the update. I do not have access to CVS from my location so will have to wait for official releases or some such thing.

Chris

#6 I'm still getting compile errors with the HEAD version of the SDK, but this time it's pointing to problems with the /audio/* files (Mandrake 10.1, gcc 3.4.1). Here's the relevant part of the output:

$ make
--> Compiling audio/audio.cc
In file included from ./audio/audioBuffer.h:16,
                 from ./audio/audioDataBlock.h:13,
                 from ./audio/audio.h:13,
                 from audio/audio.cc:6:
./core/resManager.h: In member function 'void Resource<T>::unlock()':
./core/resManager.h:255: error: invalid use of undefined type 'struct
ResManager'
./core/resManager.h:38: error: forward declaration of 'struct ResManager'
./core/resManager.h: In member function 'void Resource<T>::purge()':
./core/resManager.h:263: error: invalid use of undefined type 'struct
ResManager'
./core/resManager.h:38: error: forward declaration of 'struct ResManager'
./core/resManager.h:265: error: invalid use of undefined type 'struct
ResManager'
./core/resManager.h:38: error: forward declaration of 'struct ResManager'
./core/resManager.h: In member function 'void Resource<T>::_unlock()':
./core/resManager.h:278: error: invalid use of undefined type 'struct
ResManager'
./core/resManager.h:38: error: forward declaration of 'struct ResManager'
audio/audio.cc: In function 'int loopingImageSort(const void*, const void*)':
audio/audio.cc:161: warning: converting to 'int' from 'float'
audio/audio.cc: In function 'int streamingSourceSort(const void*, const
void*)':
audio/audio.cc:193: warning: converting to 'int' from 'float'
audio/audio.cc: In function 'AUDIOHANDLE alxCreateSource(const
Audio::Description*, const char*, const MatrixF*,
AudioSampleEnvironment*)':
audio/audio.cc:707: warning: converting to non-pointer type 'ALuint' from
NULL
audio/audio.cc: In function 'ALuint alxGetWaveLen(ALuint)':
audio/audio.cc:2092: warning: converting to 'ALuint' from 'F64'
make[1]: *** [out.GCC3.4+.DEBUG/audio/audio.obj] Error 1
make: *** [default] Error 2
$

Does anybody know what's going on?

#7 @Chris, the "Isn't properly out of the bins!" error has nothing to do with your compilation, it's a particle effect problem.
I've posted the fix numerous times before but here it is again...

Fix To Annoying Console Message
Files modified...
~/Torque/engine/game/fx/explosion.cc

Found:
if (mDataBlock->particleEmitter) {
      ParticleEmitter* emitter = new ParticleEmitter;
      emitter->setDataBlock(mDataBlock->particleEmitter);
      emitter->registerObject();
      emitter->emitParticles(getPosition(), mInitialNormal, mDataBlock->particleRadius,Point3F(0, 0, 0), U32(mDataBlock->particleDensity * mFade));
   }
   
Replaced with:
if (mDataBlock->particleEmitter) {
      ParticleEmitter* emitter = new ParticleEmitter;
      emitter->setDataBlock(mDataBlock->particleEmitter);
      // sr: Adding the if else block and the deleteWhenEmpty, since this emitter isn't properly 
      // cleand up in onRemove
      if (emitter->registerObject()) {
         emitter->emitParticles(getPosition(), mInitialNormal, mDataBlock->particleRadius,Point3F(0, 0, 0), U32(mDataBlock->particleDensity * mFade));
         emitter->deleteWhenEmpty();
      } else {
         Con::warnf( ConsoleLogEntry::General, "Could not register emitter for particle of class: %s", mDataBlock->getName() );
      }
   }
END FIX

#8 Look in the Bugs forum for the Gcc 3.41 thread which covers compilation issues.

#9 Thanks for the info on the bin problem. I did not worry too much about it and figured I would get to it later.

#10 Ray,

I'm not sure if you've gotten an answer on this yet, but what I did was move the inlike template functions to the end of the file. They are trying to use the Resource class before it has been referenced.

So move these:

template<class T> inline void Resource<T>::unlock()
{
   if (obj) {
      ResourceManager->unlock( obj );
      obj=NULL;
   }
}

template<class T> inline void Resource<T>::purge()
{
   if (obj) { 
      ResourceManager->unlock( obj );
      if (obj->lockCount == 0)
         ResourceManager->purge(obj); 
      obj = NULL;
   }
}
template <class T> inline void Resource<T>::_lock()
{
   if (obj)
      obj->lockCount++;
}

template <class T> inline void Resource<T>::_unlock()
{
   if (obj)
      ResourceManager->unlock( obj );
}

to the end of your file. Should fix that problem.

#11

Quote:Basically, gcc3.4.2 *really* doesnt like the nonconstant initialization of the enum values. My solution was to get rid of the enum entirely, and store the "Offset"-initialized event header sizes as "static const U32" variables in each of the affected structs (PacketReceiveEvent, ConnectedReceiveEvent, and ConsoleEvent). Theres really no need for an independent enum, anyways.

Would it be possible to explain this in more detail? I am a complete newb and I have the exact same compile issue.
Thanks.