I downloaded the FBX SDK a while ago and have been trying to integrate it with my code for a custom importer. The problem I am running into is that when I try to compile, I get the error “expected unqualified-id before numeric constant” in 3 different places: kfbxobject.h, kfbxnode.h, and kfbxtexture.h, all in include/fbxfilesdk/kfbxplugins.

I’m using GCC 4.3.2 in Code::Blocks 10.05 on a Linux 2.6.32 x86_64 system, specifically Debian 6.0.2 (Squeeze, Stable). The errors are whenever it uses an enum called eFbxPropertyCallback:

eFbxPropertyCallback is declared in kfbxobject (interestingly, just above the declaration for kFbxObject::PropertyNotify, as such:

I have tried searching for this error on the internet, and have found that generally it occurs due to a naming conflict. However, I know I have declared nothing of the sort in my project, and a search (using the “find” command) shows that there are only 4 places eFbxPropertyCallback anywhere in any libraries I’m using: the 4 places I’ve presented here. More importantly, if I try changing the name (I’ve tried everything from eFbxCallback to eFbxRandomEnumName) and using that in these places, I still get the same error.

Please, any help would be appreciated. I have no clue why it is doing this or how to fix it.

Hi drummerp,

Possibly your issue is linked with this post: 2012.1 SDK under Ubuntu Linux?

I hope this helps,

Viviane Rochon
Maya Data Platform
Autodesk

Hi drummerp,

Ok, I will log a bug then.
You are using FBX SDK 2012.1, right?

Viviane Rochon
Maya Data Platform
Autodesk

Yes, I’m using 2012.1. Sorry for not clarifying that.

Any information on what’s going on with this? Presumably it’s been added as a trouble ticket which some developer will find at some point in the future and work on resolving? And if so, any suggestions for getting it to work in the short term?

Hi drummerp,

At present, task BARB-205 is open.

I have no other suggestion than the thread already posted: 2012.1 SDK under Ubuntu Linux. It does mention that using a GCC version higher than GCC 4.1.2 might cause compilatiton errors.

I am sorry, I don’t have any other hints to help you.

Viviane Rochon
Maya Data Platform
Autodesk

If a fix is introduced based on this task, should I expect not to see it until the next version is released?

Hi drummerp,

A developer investigated this case. Here is what he has to say:

First of all, we do not have eFbxPropertyCallback defined in FBX SDK 2011.3, 2012.1 or 2012.2. We are assuming that you are referring to eFbxPropertyNotify.

Our FBX developer is convinced that you are experiencing the same problems as this post, i.e: using a compiler more recent than then one we use to build FBX SDK. We build perfectly fine with gcc 4.0.2 (maybe 4.1.x too) but, clearly, gcc 4.3.x does not like the way we define the enum.

Anyway, in FBX 2013 we have changed the definition of the enums. Now, instead of :

typedef enum {
eFbxProperty_SetRequest
eFbxProperty_Set
eFbxProperty_Get
} eFbxPropertyNotify;

we have:

enum PropertyNotifyType
{
ePropertySetRequest
ePropertySet
ePropertyGet
}

The pre-processor on Linux can play nasty tricks depending on the include order of the header files. Maybe this is what is happening here. We suspect that the typedef style we use does not meet the requirements for GCC 4.3.x. With a little bit of luck, the new way we define the enum will pass better.

You could try moving some include statement, maybe they will fix the problem. It is sad to say, but we have no way of testing this, and with GCC 4.0.2 everything compiles without any errors.

Another possibily may be that you are using some compiler flags that are garbling the symbols names and make them incompatible with the FBX SDK library ?

I hope this helps,

Viviane Rochon
Maya Data Platform
Autodesk

Thank you very much for the help. I shall try that and get back to you shortly.

EDIT: I’m sorry, that doesn’t seem to have worked either. I might be able to switch over to GCC 4.0.3, but it would just be difficult because it would require me to rebuild every library I have, and it’ll require me to build GCC from source since the oldest version in my Debian repository is 4.3.

Well, I seem to have stumbled upon a fix. Code::Blocks, by default, passes the flag --std=c++0x to GCC, causing it to use the upcoming C++0x standard. By disabling this in Build Options (which I did for a different reason), it eliminates the error. I assume that C++0x redefines the way enums are used in C++ or some such. At any rate, there’s your fix.

Good to know! Thank you!

Viviane Rochon
Maya Data Platform
Autodesk