[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1268
  • Last Modified:

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.
0
ambuli
Asked:
ambuli
3 Solutions
 
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
 
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
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
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
 
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

Featured Post

Get free NFR key for Veeam Availability Suite 9.5

Veeam is happy to provide a free NFR license (1 year, 2 sockets) to all certified IT Pros. The license allows for the non-production use of Veeam Availability Suite v9.5 in your home lab, without any feature limitations. It works for both VMware and Hyper-V environments

Tackle projects and never again get stuck behind a technical roadblock.
Join Now