error: conflicting types for 'BOOL'

Hi Experts,

I am using two different libraries and they both have BOOL defined.  I am getting multiple definition(actually conflicting type) errors.  How can I fix this without changing the library code?

Thank you.
ambuliAsked:
Who is Participating?
 
satsumoSoftware DeveloperCommented:
This is a problem with BOOL, unless the language has its own definition you get endless conflicting versions of how it should be defined. I've seen TRUE defined as 1, 1 as an enum (as above), -1, 0xFFFFFFFF, !FALSE, !0, !NULL. I don't define BOOL, TRUE or FALSE directly, I regard it is an unnecessary complication that cause issues like this. In my book something is zero or it isn't zero, you don't need a define or a header and zero is 100% portable. That's how the processor evaluates booleans now matter what people call them.

In this case you have two definitions of a macro with the same name but used in different contexts. You cant reliably make them the same because the two contexts might define the macro as different values. I would rename at one of those definitions. If that second, less used bool is from a library called foo.lib with foo.h I would call it FOO_BOOL and change all the uses in its header file to match.
0
 
jkrCommented:
Any chance to separate the code that uses each of them into different source files? That would solve the problem in a simple way.

Also: How do both 'typdef' their 'BOOL' types? If both are somewhat compatible (i.e. the types' sizes match), there might be a workaround.
0
 
ambuliAuthor Commented:
Yes, I am using one of the library in only one file.  I was able to do away with the compile error
using :
#ifdef BOOL
#undef BOOL
#include "newlibrary.h"
#endif

However, I am not sure if this would be okay.

They are typedef like below.
typedef unsigned char BOOL;
typedef int BOOL;
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

 
jkrCommented:
>>However, I am not sure if this would be okay.

'#undef' won't take care of a user-defined 'typedef', only expressions created with a '#define' would be affected.

And 'int' and 'unsigned char' aren't really compatible. If passed to one of the libs' functions, there easily might be a problem. Without recompoiling one of the libs, I can only think of strictly separating their use into different compilation units i.g. source files. If they aren't used together in one unit, they'll not cause trouble.
0
 
Duncan RoeSoftware DeveloperCommented:
You absolutely will have to modify the library headers if any source file needs to use both of them. So you might as well do a decent job:
Both libraries have bad definitions for BOOL. For C programs you want
typedef enum
{
  false,
  true
} BOOL;

Open in new window

(this assumes you assign values false or true to BOOL variables). The benefit you get is that when running gdb to debug the program, it will shiow the values of BOOL variables as "true" or "false" (rather than "1" or "0" if they were integer).
Also, you only ever want to typedef it once. To achieve that as well
#ifndef BOOL_TYPEDEF_DONE
$define BOOL_TYPEDEF_DONE
typedef enum
{
  false,
  true
} BOOL;
#endif

Open in new window

Change both library header files as above. Remove #define lines for true and false. If using something else (e.g. TRUE & FALSE), remove those lines and change the enum to use whatever identifiers are expected.
You need to recompile the libraries afterwards
0
 
evilrixSenior Software Engineer (Avast)Commented:
If you can't modify and rebuild either of these libraries the simplest solution would be to write an abstraction layer (a proxy) for each and build them a shared libraries. The proxy will need to marshal whatever types your using to represent BOOL and true/false to whatever type/value is being used by the library. Your main code base will then need to interface to these libraries as DSOs (Dynamic Shared Objects) via your abstraction (proxy) interface.

If you need to link both of them as static libraries you are going to have to change at least one of them. If you are going to change the libraries and you are building with C99 support you'd be better off just typedef'ing BOOL to _Bool, which is a proper boolean type in C99. Unfortunately, ANSI C doesn't have real boolean types so, in that case, what Duncan suggests is probably your best bet.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.