Command line error macro names must be identifiers

:0:1: error: macro names must be identifiers #51

platform: Jetson Xavier NX, ubuntu18.04
It seems like #9. But #9 had been resolved.

The text was updated successfully, but these errors were encountered:

Can you copy and paste the full verbose output from catkin build ? Offhand I believe the command for this is catkin build —verbose .

Some more info about the build environment will be helpful:

• What version of PCL is installed?
• What version of CUDA are you using?

Thanks for your reply.

More info about the build environment:

• What version of PCL is installed? PCL1.8
• What version of CUDA are you using? cuda 10.2

verbose output follows:
[ 63%] Building CXX object CMakeFiles/yak_frontend.dir/src/yak_server.cpp.o
[ 68%] Building CXX object CMakeFiles/yak_frontend.dir/src/kfusion/tsdf_container.cpp.o
/usr/bin/c++ -D-ffloat-store -DDISABLE_DAVIDSDK -DDISABLE_DSSDK -DDISABLE_ENSENSO -DDISABLE_LIBUSB_1_0 -DDISABLE_PCAP -DDISABLE_PNG -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DvtkFiltersFlowPaths_AUTOINIT=»1(vtkFiltersParallelFlowPaths)» -DvtkIOExodus_AUTOINIT=»1(vtkIOParallelExodus)» -DvtkIOGeometry_AUTOINIT=»1(vtkIOMPIParallel)» -DvtkIOImage_AUTOINIT=»1(vtkIOMPIImage)» -DvtkIOParallel_AUTOINIT=»1(vtkIOMPIParallel)» -DvtkIOSQL_AUTOINIT=»2(vtkIOMySQL,vtkIOPostgreSQL)» -DvtkRenderingContext2D_AUTOINIT=»1(vtkRenderingContextOpenGL)» -DvtkRenderingCore_AUTOINIT=»3(vtkInteractionStyle,vtkRenderingFreeType,vtkRenderingOpenGL)» -DvtkRenderingFreeType_AUTOINIT=»2(vtkRenderingFreeTypeFontConfig,vtkRenderingMatplotlib)» -DvtkRenderingLIC_AUTOINIT=»1(vtkRenderingParallelLIC)» -DvtkRenderingVolume_AUTOINIT=»1(vtkRenderingVolumeOpenGL)» -Dyak_frontend_EXPORTS -isystem /usr/include/vtk-6.3 -isystem /usr/include/freetype2 -isystem /usr/lib/aarch64-linux-gnu/openmpi/include/openmpi -isystem /usr/lib/aarch64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent -isystem /usr/lib/aarch64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent/include -isystem /usr/lib/aarch64-linux-gnu/openmpi/include -isystem /usr/include/python2.7 -isystem /usr/include/aarch64-linux-gnu -isystem /usr/include/hdf5/openmpi -isystem /usr/include/libxml2 -isystem /usr/include/jsoncpp -isystem /usr/include/tcl -I/usr/local/cuda/include -I/home/research/catkin_ws_test/src/yak/yak/include -isystem /usr/include/pcl-1.8 -isystem /usr/include/eigen3 -isystem /usr/include/ni -isystem /usr/include/openni2 -isystem /usr/include/opencv -isystem /usr/include/aarch64-linux-gnu/qt5 -isystem /usr/include/aarch64-linux-gnu/qt5/QtWidgets -isystem /usr/include/aarch64-linux-gnu/qt5/QtGui -isystem /usr/include/aarch64-linux-gnu/qt5/QtCore -isystem /usr/lib/aarch64-linux-gnu/qt5/mkspecs/linux-g++ -fPIC -fPIC -std=gnu++14 -o CMakeFiles/yak_frontend.dir/src/yak_server.cpp.o -c /home/research/catkin_ws_test/src/yak/yak/src/yak_server.cpp
/usr/bin/c++ -D-ffloat-store -DDISABLE_DAVIDSDK -DDISABLE_DSSDK -DDISABLE_ENSENSO -DDISABLE_LIBUSB_1_0 -DDISABLE_PCAP -DDISABLE_PNG -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DvtkFiltersFlowPaths_AUTOINIT=»1(vtkFiltersParallelFlowPaths)» -DvtkIOExodus_AUTOINIT=»1(vtkIOParallelExodus)» -DvtkIOGeometry_AUTOINIT=»1(vtkIOMPIParallel)» -DvtkIOImage_AUTOINIT=»1(vtkIOMPIImage)» -DvtkIOParallel_AUTOINIT=»1(vtkIOMPIParallel)» -DvtkIOSQL_AUTOINIT=»2(vtkIOMySQL,vtkIOPostgreSQL)» -DvtkRenderingContext2D_AUTOINIT=»1(vtkRenderingContextOpenGL)» -DvtkRenderingCore_AUTOINIT=»3(vtkInteractionStyle,vtkRenderingFreeType,vtkRenderingOpenGL)» -DvtkRenderingFreeType_AUTOINIT=»2(vtkRenderingFreeTypeFontConfig,vtkRenderingMatplotlib)» -DvtkRenderingLIC_AUTOINIT=»1(vtkRenderingParallelLIC)» -DvtkRenderingVolume_AUTOINIT=»1(vtkRenderingVolumeOpenGL)» -Dyak_frontend_EXPORTS -isystem /usr/include/vtk-6.3 -isystem /usr/include/freetype2 -isystem /usr/lib/aarch64-linux-gnu/openmpi/include/openmpi -isystem /usr/lib/aarch64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent -isystem /usr/lib/aarch64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent/include -isystem /usr/lib/aarch64-linux-gnu/openmpi/include -isystem /usr/include/python2.7 -isystem /usr/include/aarch64-linux-gnu -isystem /usr/include/hdf5/openmpi -isystem /usr/include/libxml2 -isystem /usr/include/jsoncpp -isystem /usr/include/tcl -I/usr/local/cuda/include -I/home/research/catkin_ws_test/src/yak/yak/include -isystem /usr/include/pcl-1.8 -isystem /usr/include/eigen3 -isystem /usr/include/ni -isystem /usr/include/openni2 -isystem /usr/include/opencv -isystem /usr/include/aarch64-linux-gnu/qt5 -isystem /usr/include/aarch64-linux-gnu/qt5/QtWidgets -isystem /usr/include/aarch64-linux-gnu/qt5/QtGui -isystem /usr/include/aarch64-linux-gnu/qt5/QtCore -isystem /usr/lib/aarch64-linux-gnu/qt5/mkspecs/linux-g++ -fPIC -fPIC -std=gnu++14 -o CMakeFiles/yak_frontend.dir/src/kfusion/tsdf_container.cpp.o -c /home/research/catkin_ws_test/src/yak/yak/src/kfusion/tsdf_container.cpp
[ 84%] Built target yak_marching_cubes
/usr/bin/make -f CMakeFiles/marching_cubes_tests.dir/build.make CMakeFiles/marching_cubes_tests.dir/depend
make[2]: Entering directory ‘/home/research/catkin_ws_test/build/yak’
cd /home/research/catkin_ws_test/build/yak && /usr/bin/cmake -E cmake_depends «Unix Makefiles» /home/research/catkin_ws_test/src/yak/yak /home/research/catkin_ws_test/src/yak/yak /home/research/catkin_ws_test/build/yak /home/research/catkin_ws_test/build/yak /home/research/catkin_ws_test/build/yak/CMakeFiles/marching_cubes_tests.dir/DependInfo.cmake —color=
:0:1: error: macro names must be identifiers
:0:1: error: macro names must be identifiers
make[2]: Leaving directory ‘/home/research/catkin_ws_test/build/yak’
/usr/bin/make -f CMakeFiles/marching_cubes_tests.dir/build.make CMakeFiles/marching_cubes_tests.dir/build
make[2]: Entering directory ‘/home/research/catkin_ws_test/build/yak’
make[2]: Nothing to be done for ‘CMakeFiles/marching_cubes_tests.dir/build’.
make[2]: Leaving directory ‘/home/research/catkin_ws_test/build/yak’
[ 94%] Built target marching_cubes_tests
CMakeFiles/yak_frontend.dir/build.make:86: recipe for target ‘CMakeFiles/yak_frontend.dir/src/kfusion/tsdf_container.cpp.o’ failed
make[2]: *** [CMakeFiles/yak_frontend.dir/src/kfusion/tsdf_container.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs.
CMakeFiles/yak_frontend.dir/build.make:62: recipe for target ‘CMakeFiles/yak_frontend.dir/src/yak_server.cpp.o’ failed
make[2]: Leaving directory ‘/home/research/catkin_ws_test/build/yak’
make[2]: *** [CMakeFiles/yak_frontend.dir/src/yak_server.cpp.o] Error 1
CMakeFiles/Makefile2:67: recipe for target ‘CMakeFiles/yak_frontend.dir/all’ failed
make[1]: Leaving directory ‘/home/research/catkin_ws_test/build/yak’
make[1]: *** [CMakeFiles/yak_frontend.dir/all] Error 2
Makefile:129: recipe for target ‘all’ failed
make: *** [all] Error 2
cd /home/research/catkin_ws_test/build/yak; catkin build —get-env yak | catkin env -si /usr/bin/make —jobserver-fds=6,7 -j; cd —

@duanyongli Could you select the text in your console and paste it as a comment instead of posting it as a screenshot? It’s easier to read that way, and we can search it for keywords too.

In any case, I’m suspicious of that -D-ffloat-store argument at the beginning of the list of compiler arguments. -ffloat-store is a predefined GCC flag, and prepending -D to something tells GCC to treat whatever comes after -D as a macro name, which isn’t the right thing to do in this case. I think the error you see is because macro names can’t have hyphens in them, so the compiler gives an error when it encounters the invalid name.

I don’t think that this is a problem with the Yak library or its dependencies, since we have CI jobs that build with CUDA 10.2 on Ubuntu 18.04. If you can find what is adding -D-ffloat-store to the compiler options and figure out how to remove it I think you’ll be able to solve this problem.

In any case, I’m suspicious of that -D-ffloat-store argument at the beginning of the list of compiler arguments. -ffloat-store is a predefined GCC flag, and prepending -D to something tells GCC to treat whatever comes after -D as a macro name, which isn’t the right thing to do in this case. I think the error you see is because macro names can’t have hyphens in them, so the compiler gives an error when it encounters the invalid name.

I don’t think that this is a problem with the Yak library or its dependencies, since we have CI jobs that build with CUDA 10.2 on Ubuntu 18.04. If you can find what is adding -D-ffloat-store to the compiler options and figure out how to remove it I think you’ll be able to solve this problem.

I think -D-ffloat-store comes from PCL.

message says:
CMake Warning at CMakeLists.txt:17 (message):
-ffloat-store
-DDISABLE_ENSENSO-DDISABLE_DAVIDSDK-DDISABLE_DSSDK-DDISABLE_PCAP-DDISABLE_PNG-DDISABLE_LIBUSB_1_0

Based on some quick research it seems likely that -ffloat-store is automatically added by PCL based on the detected capabilities of the ARM CPU in the Jetson Xavier NX.

message says:
CMake Warning at CMakeLists.txt:17 (message):
-ffloat-store
-DDISABLE_ENSENSO-DDISABLE_DAVIDSDK-DDISABLE_DSSDK-DDISABLE_PCAP-DDISABLE_PNG-DDISABLE_LIBUSB_1_0

It’s significant that the -ffloat-store flag is written correctly here. That means that some later step is incorrectly adding the -D prefix.

I don’t think we’ve seen a -f flag in PCL_DEFINITIONS before, so this might be a case that Yak’s CMakeLists.txt doesn’t handle correctly. For PCL 1.9 the contents of PCL_DEFINITIONS get passed into target_compile_definitions for the yak_frontend library at this line, and that might not be the correct way to handle flags like -ffloat-store . We have a macro to parse mixed options and definitions, so we might need to create something similar to separate mixed flags and definitions.

@duanyongli I was able to replicate this by manually-prepending -ffloat-store to PCL_DEFINITIONS . Our target_add_options_and_definitions macro doesn’t check to see if the prefix is -f , so -ffloat-store was incorrectly being added through target_compile_definitions instead of target_compile_options . There were also some issues with PCL_DEFINITIONS being inconsistently-delimited so that multiple flags and definitions would be incorrectly concatenated. As discussed in #9 and #10 this is specifically a problem with PCL 1.8.X and it’s been fixed in PCL 1.9.X and later.

I modified the macro to correctly handle -f -prefixed options and inconsistent delimiters, and I’ll have a PR with the fix submitted shortly.

Источник

CodeLite IDE

Error: macro names must be identifiers

Error: macro names must be identifiers

Post by barry53 » Sun Jun 03, 2012 8:25 pm

Hello,
I’m completely new to CodeLite and C++ so this is probably just an oversite on my part.

CodeLite version: v3.5.5378
Installed from the Ubuntu repositories
My OS is Ubunutu 12.04 Precise

Build Window output:
[code———-Build Started———
/bin/sh -c ‘»make» -j 2 -f «ubnt_wsp.mk»‘
———-Building project:[ ubntinfo — Debug ]———-
make[1]: Entering directory `/home/barry/.codelite/ubnt/ubntinfo’
:0:1: error: macro names must be identifiers
make[1]: *** [Debug/main.o.d] Error 1
make[1]: Leaving directory `/home/barry/.codelite/ubnt/ubntinfo’
make: *** [All] Error 2
———-Build Ended———-
0 errors, 0 warnings
[/code]

What I’v done is copy an example program from libssh2.org’s site. It is c code and I’m pasted it into a c++ project.
At this point I’m so new at this I’m not sure what else to post. Let me know what else to post to get a handle on the

Thanks for your time,
Barry

Re: Error: macro names must be identifiers

Post by eranif » Mon Jun 04, 2012 6:53 pm

It seems like you have a macro defined somewhere (from the output it seems that you defined a macro with invalid name somewhere

Re: Error: macro names must be identifiers

Post by barry53 » Sun Jun 10, 2012 5:17 pm

Thanks for your reply Eran.
I too thought it was some invalid macro name, but I hadn’t defined any macros and was using all standard headers. So I decided to start from scratch and as I added a section of code, compiled and if all went well added some more code. To make along story short, when I added and used cout and cin the problem occurred again. Well after Googling and the usual debugging effort, I noticed Update Manager had some 70 updates to do. So I let Update Manager do the updates which of course required a restart. After I rebooted everything worked as it should. I don’t know if it was one of the packages that fixed the issue or just the reboot, but anyhow things are working now.

Thanks again for your response,
Barry

Источник

Command line error macro names must be identifiers

Community

Participate

Eclipse IDE

Home » Language IDEs » C / C++ IDE (CDT) » macro names error

macro names error [message #1765238]	Wed, 07 June 2017 18:02
Isabel F Messages: 2 Registered: June 2017
Hello: Thanks if someone can help me with this issue. IВґm using eclipse neon with cygwin and googletest and gnu++11. Also working with strings. But when I build the code, It haves 2 errors: Источник Adblock detector

Contents

Overview

These C compile/build errors and warnings are talked about largely in relation to embedded systems (i.e. microcontrollers).

“pointer of type void used in arithmetic”

Usually occurs when you are doing memory arithmetic, and can actually be a warning you ignore!

1
2
3
4
5
6

void* AppendNewArrayElement(void* arrayStart, uint8 currNumElements, uint8 sizeOfArrayElement) {
    // Create a new option at end of option array
    arrayStart = realloc(arrayStart , (currNumElements+1)*sizeOfArrayElement);
    // Set to 0
    memset(arrayStart + currNumElements*sizeOfArrayElement, '', sizeOfArrayElement);
}

“elf section ‘.bss’ will not fit in region ‘ram’

The .bss section contains all 0-initialized global and static variables. This error normally occurs when you have overly large static variables, or you haven’t allocated the stack/heap sizes correctly.

“Suggested parenthesis around assignment used as a truth value”

This is usually because you’ve forgotten to add the second = in the if statement.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Only one equal sign, if statement will produce unexpected results!
// value2 will be assigned to value1 and then
// checked to see if non-zero
if(value1 = value2) {
    // blah blah
}

// Correct way of comparing two values, with two equal signs
if(value1 == value2) {
    // blah blah
}

“Subscripted value is neither array nor pointer”

Normally occurs when you try and index something like an array which isn’t. For example…

1
2
3
4
5
6
7
8
9

#include 

double value;

// This will produce the error, as sin is a function, not an array
value = sin[180];

// The proper way of using sin
value = sin(180);

“#pragma once in main file”

This occurs when you incorrectly write “#pragma once” in a .c file (even though the error would suggest it, it doesn’t have to be main.c). “#pragma once” is a header guard which prevents an .h file from being included twice in a project and causing multiple declaration/definition errors. Hence “#pragma once” should be only place in .h files. It is an alternative to the “#ifndef” header guard style (see this page for more info).

“variable or field declared void”

This can occur when you declare/define a function in C++ and the compiler doesn’t recognise one of the data types used for an input variable. It will precede a <variable> was not declared in scope error.

1
2
3

// A function declaration with an unrecognised type used in the input.
// The will cause both a 'variable or field declared void' and 'inputVar was not declared in scope' error
void function1(unrecognisedType_t inputVar);

“macro names must be identifiers”

If you get the error macro names must be identifiers it is usually because you have been using both #if() and #ifdef directives, and accidentally used the combination #ifdef(). This is not allowed! When using #ifdef, do not enclose the proceeding identifier with brackets.

1
2
3
4
5
6
7
8
9

// BAD!
#ifdef(__linux)
    ...
#endif

// GOOD!
#ifdef __linux__
    ...
#endif

“Not In Formal Parameter List”

Applies To: Keil C51 Compiler

The “not in formal parameter list” build error is most likely to occur when you have forgotten to add the semi-colon at the end of a function declaration. Without the semi-colon, the compiler continues to read onto the following lines, and usually produces this error. Check the first first function declaration preceding this error for a missing semi-colon.

1
2
3
4

// The following function declaration is missing a semi-colon at the end
void function1()
// The "not in formal parameter list" build error will occur on this following line
void function2();

double free or corruption

Error Type: Run Time

This error normally codes with another keyword at the end, e.g.

1

double free or corruption (!prev)

It normally occurs when you accidentally free() the same piece of memory twice. I have also got this error due to a incremental-build bug in the Xilinx SDK (xsdk) for it’s Zynq FGPAs/microcontroller chips.

Hi guys,

I am having the same problem as S2rt. The error message looks the same. I get it for every file in my project using CVI 2013 with f1 patch, if I load the same .cws file in the CVI 2012SP1, everything works fine as expected.

I am using doxygen comments, so the files start like

/*! file 
 * 
 */
#include <userint.h>
#include <ansi_c.h>

 but I also get this error code for the NI-WordReport Instrument.

/*============================================================================*/
/*                        L a b W i n d o w s / C V I                         */
/*----------------------------------------------------------------------------*/
/*    Copyright (c) National Instruments 1999-2013.  All Rights Reserved.     */
/*----------------------------------------------------------------------------*/
/*                                                                            */
/* Title:       WordReport.c                                                  */
/* Purpose:     Source file for CVI Word Report Generation Instrument Driver  */
/* Notes: 		This library communicates with the Microsoft Word Automation  */
/*				Server.  The Microsoft Word Automation Server must be first   */
/*				generated before using this library.						  */
/*                                                                            */
/*============================================================================*/

//-------------------------------------------------------------------------------------------------
//-------------------------------------------------------------------------------------------------
// Implementation Overview:

 Any news about this topic? Possibly a configuration problem or another bug in the 2013 release ?