Expected unqualified-id

[Anonymous]

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:

virtual bool PropertyNotify(eFbxPropertyCallback, KFbxProperty*); //kfbxobject.h

virtual bool PropertyNotify(eFbxPropertyCallback pType, KFbxProperty* pProperty); //kfbxnode.h

virtual bool PropertyNotify(eFbxPropertyCallback pType, KFbxProperty* pProperty); //kfbxtexture.h

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

// property callbacks
    typedef enum {
        eFbxProperty_SetRequest,
        eFbxProperty_Set,
        eFbxProperty_Get
    } eFbxPropertyCallback;

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.

[viviane.rochon]

Hi drummerp,

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

I hope this helps,

[Anonymous]

No, that would not seem to be related to my problem, but thanks for trying.

[viviane.rochon]

Hi drummerp,

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

[Anonymous]

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

[Anonymous]

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?

[viviane.rochon]

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.

[Anonymous]

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

[Anonymous]

Try dumping out the C++ pre processing pass and see if that gives you any insight.

[viviane.rochon]

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,

[Anonymous]

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.

[Anonymous]

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.

[viviane.rochon]

Good to know! Thank you!

[Anonymous]

While I'm here, I have one other question. If I'm using GCC on Windows, should I link with the GCC Linux build, or the VS2010 Windows build?

[viviane.rochon]

The GCC Linux build.

[Anonymous]

I had the exact same problem as drummerp after some updates (it worked before). After reading this post, I fixed the problem by changing the order of the includes, as suggested. I am using gcc 4.6.1 and everything compiles fine again, even with -std=c++0x.

Thank you.

EDIT: Finally had some time to investigate this and found the error. The problem is that one function name and one enum member are already defined in X11/X.h (I am including <GL/glxew.h>, and it includes many X11 headers).

In the following lines, "PropertyNotify" is previously defined as an integer:

-> include/fbxfilesdk/kfbxplugins/kfbxobject.h:1214:
virtual bool PropertyNotify(eFbxPropertyNotify pType, KFbxProperty* pProperty);

-> include/fbxfilesdk/kfbxplugins/kfbxnode.h:2106:
virtual bool PropertyNotify(eFbxPropertyNotify pType, KFbxProperty* pProperty);

-> include/fbxfilesdk/kfbxplugins/kfbxtexture.h:646:
virtual bool PropertyNotify(eFbxPropertyNotify pType, KFbxProperty* pProperty);

In the following line, "None" is also previously defined:

-> include/fbxfilesdk/kfbxplugins/kfbxvideo.h:212:
None,           //!< Progressive frame (full frame).

Since now you know exactly what's wrong and it is an annoying conflict, it would be great to have it fixed for future releases. Please let us know if you intend to do something about it.

By the way, I am using FBX SDK 2012.2.

[RobertGoulet]

We do not support GCC on Windows. We only offer GCC builds on Linux and MacOSX. i.e. we do not support cygwin.

[Anonymous]

I would appreciate if, in a future update, you did add support for GCC/MinGW/Cygwin on Windows, as I would expect that it would represent a significant number of developers. For example, I am developing a multi-platform program that, for ease and simplicity, is compiled by GCC on all platforms, and it is to use FBX to import 3D models. I cannot simply tell customers that we don't support FBX loading on Windows...

[Anonymous]

I would appreciate if, in a future update, you did add support for GCC/MinGW/Cygwin on Windows, as I would expect that it would represent a significant number of developers. For example, I am developing a multi-platform program that, for ease and simplicity, is compiled by GCC on all platforms, and it is to use FBX to import 3D models. I cannot simply tell customers that we don't support FBX loading on Windows...

Second to this, it's quite weird that you guys never bothered to do so. I'm choosing GCC on Windows too for the same reason that -drummerp- have, simplicity and multi-platform. Now I'll need to create a VS FBX loader just to read the FBX and output into my own format for both unix and win platform...

I've search through the forum and found out that such request had been out there since 2008-02-29 (earliest date that i can find) and there are no update/reply at all after this reply:

from:
http://area.autodesk.com/forum/autodesk-fbx/fbx-sdk/linking-problem-mingw--name-mangling-win32/

Hi Decrement,

A suggestion has been opened in our database to support mingw on win32.

Viviane

Here's my questions:
1) Whats the status of that suggestion?
2) Why does MingW on Windows is not supported? Reason?

We do not support GCC on Windows. We only offer GCC builds on Linux and MacOSX. i.e. we do not support cygwin.

I understand that most of the developers out there does not bothered about cygwin (not widely used environment) but it's different story for MingW on Windows since it's quite widely used around so why it's not supported? Set a Windows' MingW version standard that you guys want to use (eg. the version that comes with the latest Code::Blocks) and set it as your standard

Edit: (Or MingW version that comes with the latest Qt C++)

[RobertGoulet]

Thanks for the info, I will try to remember to put this in the documentation.