Jump to content

error #define FALSE 0


remon

Recommended Posts

Hi,

I'm trying to compile uGFX on a NXP Cortex M0+ microcontroller using freeRTOS, however when compiling I get the following error:

 

Building file: ../src/gwin/gwin.c
Invoking: MCU C Compiler
arm-none-eabi-gcc -DDEBUG -D__CODE_RED -DCORE_M0PLUS -D__MTB_BUFFER_SIZE=256 -D__USE_ROMDIVIDE -D__USE_LPCOPEN -D__LPC11U6X__ -D__REDLIB__ -I"/home/remon/Repositories/Heisenberg/firmware/heisenberg_v2/lpc_board_nxp_lpcxpresso_11u68/inc" -I"/home/remon/Repositories/Heisenberg/firmware/heisenberg_v2/freertos/inc" -I"/home/remon/Repositories/Heisenberg/firmware/heisenberg_v2/lpc_chip_11u6x/inc" -O0 -fno-common -g3 -Wall -c -fmessage-length=0 -fno-builtin -ffunction-sections -fdata-sections -mcpu=cortex-m0 -mthumb -specs=redlib.specs -MMD -MP -MF"src/gwin/gwin.d" -MT"src/gwin/gwin.o" -MT"src/gwin/gwin.d" -o "src/gwin/gwin.o" "../src/gwin/gwin.c"
In file included from ../src/gwin/gwin.c:13:0:
../src/gwin/../../gfx.h:31:22: error: expected identifier before numeric constant
  #define FALSE       0
                      ^
/home/remon/Repositories/Heisenberg/firmware/heisenberg_v2/lpc_chip_11u6x/inc/lpc_types.h:50:15: note: in expansion of macro 'FALSE'
 typedef enum {FALSE = 0, TRUE = !FALSE} Bool;
               ^
make: *** [src/gwin/subdir.mk:80: src/gwin/gwin.o] Error 1

There seems to be an conflict between the FALSE define in the uGFX and the chip library, Any thoughts on how to solve this?

 

Kind regards,

Remon

Link to comment
Share on other sites

This might be an issue with the inclusion order. µGFX only defines TRUE and FALSE if they haven't been defined so far. Snipped from gfx.h:

/**
 * @brief   Generic 'false' boolean constant.
 */
#if !defined(FALSE) || defined(__DOXYGEN__)
	#define FALSE       0
#endif

/**
 * @brief   Generic 'true' boolean constant.
 */
#if !defined(TRUE) || defined(__DOXYGEN__)
	#define TRUE        -1
#endif

You might/should include the "base system" before the uGFX stuff in your build tree.

Issues like this won't happen in the future anymore. µGFX 3.0 will use prefixes for all types and definitions to avoid collisions like this.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...