C/C++ linkage code error

Ther are two Header file IMG_fnconst.h & TAL_Messages.H included in source file IMG_FileNet.C

Part code content of IMG_fnconst.h . In this file we have #defines in C semantics :
#define TAL_SUCCESS 0
#define TAL_ERR_NEXTIMAGEID -1


Part code content of TAL_Messages.H . In this file we have proper primitive data type declaration with actual definition in some other C++ files.
extern unsigned long int TAL_SUCCESS ;
extern unsigned long int TAL_I_DOC_NOT_COMMITTED ;

The above code is ported from IBM AIX6.1 to Linux , In IBM AIX6.1, the code compilation works fine with xlC compiler.

g++ -c -g -m32 -DSYS_NO_DB_ACCESS -DDEBUG -DSRVR_BUILD -DUSENODCE -DAIX_MIGRATION -I/usr/include/ -I/usr/include -I/usr/include/c++/4.4.4/ -I/usr/include/c++/4.4.4/x86_64-redhat-linux/32/ -I/xenv/OracleSDK/X/11.2.0.4//precomp/public -I/xenv/OracleSDK/X/11.2.0.4/rdbms/demo -I/xenv/OracleSDK/X/11.2.0.4//rdbms/public -I/home/dev11i/inc -I/home/GSOAP/gsoap-2.8/gsoap -qlanglvl=noansifor /home/dev11i/src/IMG_FileNet.C -o /home/dev11i/libImgClient_dir/obj/IMG_FileNet.o

With above g++ rule in Linux , we get following refdef error wrt C/C++ linkage.

In file included from /home/as79475/dev11i/inc/IMG_fnconst.h:24,
from /home/as79475/dev11i/src/IMG_FileNet.C:72:
/home/as79475/dev11i/inc/TAL_Messages.H:38: error: previous declaration of 'long unsigned int TAL_SUCCESS' with 'C++' linkage
/home/as79475/dev11i/inc/TAL_Messages.H:38: error: conflicts with new declaration with 'C' linkage
/home/as79475/dev11i/inc/TAL_Messages.H:39: error: previous declaration of 'long unsigned int TAL_I_DOC_NOT_COMMITTED' with 'C++' linkage
/home/as79475/dev11i/inc/TAL_Messages.H:39: error: conflicts with new declaration with 'C' linkage

Is there any g++ flag that will implicitly handle this code redefinition? We want the C++ code to be active.
Instead of trying to silence your compiler you really should fix your code.

To fix your code you need to understand that the two definitions are not doing the same thing. First the #define is creating a constant where the "extern definition" is creating non-constant global variables. Second the #define is probably creating an int constant not an unsigned int constant. Third it may be possible that in some compilation units the code may be expecting a const and in other compilation units the code may be expecting a non-const variable instead, you need to insure that you "fix" the problem correctly to avoid possible hard to find bugs being caused by using the incorrect type of variable. And you need to ask yourself why there are two different definitions in the first place.

Topic archived. No new replies allowed.