define gets ignored by target_compile_definitions - makefile

I am looking to build a library and I need to pass two defines to that build, but cmake's target_compile_definitions() scrambles them in a manner that renders them unusable.
The two defines are:
-D'_LIB_EXCEPTION_ABI=__attribute__((visibility("default")))'
-D'_LIB_FALLTHROUGH()=((void)0)'
Unfortunately, the first one gets translated to (in the command build line):
-D'_LIB_EXCEPTION_ABI="\__attribute__((visibility(\"default\")))'"
While the second one is missing altogether from the command line.

CMake has known limitations on what compile definitions could be.
Among these limitations are function-style definitions (_LIB_FALLTHROUGH()) and ones containing double quotes (").
Instead of attempting to overcome these limitations, it is recommended to create a separate header file with these compile definitions:
#define _LIB_EXCEPTION_ABI __attribute__((visibility("default")))
#define _LIB_FALLTHROUGH() ((void)0)
This header file could be included with -include compiler option (gcc) or /FI option (Visual Studio).

Related

How do I create a custom library in GNU?

How do I create a custom library in GNU? What I mean is:
When we use #include < stdio.h> and printf
we can compile it with gcc main.c
Now I create my custom headers and .a/.so library files, I know I can set the environment variable C_INCLUDE_PATH and include my header files with #include<> instead of #include"". However, I still have to compile it with
gcc main.c -o program -L/whatever/ -lwahtever
(with set environment variable if using .so)
Is it possible to make it behave like #include< stdio.h> where I don't need to include the paths with corresponding command line arguments?
You actually don't need -L/whatever/, just -lwhatever. The first option supplies the path to your library, but you have already taken care of that with the #include and modifying C_INCLUDE_PATH. The second option tells the linker which library to link your executable with. An example of this is when using functions from the C math library, you #include <math.h>, but to compile, you still need the linker option -lmath. So to answer your question, no. You can remove the first option, but you must leave the second.

Substituting for a .SET on the the command line

I have some (Microblaze) assembly I need to build (via the GCC cross-assembler and linker) and execute many times with the (same) constants, currently fixed via
.SET
commands, changed each time.
Is there a way to automate the setting of in-assembly constants in this way and so avoid the dull task of resetting the code for each build?
You can use the power of C pre-processor in your assembler files. This could be done simply changing file extension from .s to .S (capital S) on Unix-like platform or to .sx on Windows. Then using gcc instead of gas over these files will let C pre-processor first run through the source and then gas will be called automatically.
In this case you can use all regular pre-processor #define, #ifdef, etc. And of cause you can pass these defines from the command line with gcc's -D parameter.

Run preprocessor and keep directives

Is there a way I can run gcc -E to run the preprocessor but also to keep the #define, #include, other directives in the output (possibly as comments)? I thought I remembered seeing an option for this but I can't find it in the GCC Preprocessor Options page. I need this to track down where things are going wrong in a complex case involving lots of include files and macros.
The relevant options are listed under -dCHARS. -dD outputs macro definitions (both #define and #undef directives), -dI outputs #include directives, and they can be combined to -dDI.

gcc: passing list of preprocessor defines

I have a rather long list of preprocessor definitions that I want to make available to several C programs that are compiled with gcc.
Basically I could create a huge list of -DDEF1=1 -DDEF2=2 ... options to pass to gcc, but that would create a huge mess, is hard to use in a versioning-system and may at some time in the future break the command line length limit.
I would like to define my defines in a file.
Basically the -imacros would do what I want except that it only passes it to the first source file: (below from the gcc documentation):
-include file Process file as if #include "file" appeared as the first line of the primary source file. However, the first directory searched
for file is the preprocessor's working directory instead of the
directory containing the main source file. If not found there, it is
searched for in the remainder of the #include "..." search chain as
normal. If multiple -include options are given, the files are included
in the order they appear on the command line.
-imacros file Exactly like -include, except that any output produced by scanning file is thrown away. Macros it defines remain defined.
This allows you to acquire all the macros from a header without also
processing its declarations. All files specified by -imacros are
processed before all files specified by -include.
I need to have the definitions available in all source files, not just the first one.
Look at the bottom of this reference.
What you might want is the #file option. This option tells GCC to use file for command-line options. This file can of course contain preprocessor defines.
Honestly - it sounds like you need to do a bit more in your build environment.
For example, one suggestion is that it sounds like you should create a header file that is included by all your source files and #define all your definitions.
You could also use -include, but specify an explicit path - which should be determined in your Makefile/build environment.
The -imacros would work, if your Makefile were building each source file independently, into its own object file (which is typical). Its sounds like you're just throwing all the sources into building a single object.

Concatenation problems with debug print macro under gcc

To completely disable a debug output in c-source,
I usually define the following SIMPLE macro #1
#define dprintf(args)
To enable a debug output, I define macro #2 alternatively
#define dprintf(args) printk##args
The usage in source looks like:
dprintf(("Irqs:%lu\n",irqs));
A preprocessor should create following line if I use macro #2
printk("Irqs:%lu\n",irqs);
Under Windows Visual c++, there is no problem.
Using gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) under NETBEANS IDE 6.8,
I got the following error message:
"printk" and "(" does not give a valid preprocessing token
I tried the following under Linux
#define dprintk(args...) printk(args)
This works only with
dprintf("Irqs:%lu\n",irqs);
Visual C++ however does not know args...
I have to compile source code on windows
and Linux(386) platform alternatively.
Does anyone have an idea ?
Why not #define dprintf(args) print args ?
The double parenthesis could have been added to replace the variadic macro in visual C++ : the preprocessor will handle macro invocation as if there was only one parameter.
The token pasting operator ## can only be used to concatenate tokens, as its name implies. Some compilers, e.g. newer versions of gcc, enforce this more rigidly than others, as you have now discovered. As philippe says, though, you don't actually need ## in this particular example.

Resources