In my Makefile.am file I have something like this:
bin_PROGRAMS = foo bar
foo_SOURCES = foo.cpp
bar_SOURCES = bar.cpp
I am interested in having bar only compiled when I do a make bar, not when I do a make all. But I want foo always compiled. How do I do that?
Thanks.
If you want do declare a program can be built (i.e. the target must be emitted by Automake), but should not be built by make all or make check, you can simply declare it as EXTRA_PROGRAMS.
bin_PROGRAMS = foo
EXTRA_PROGRAMS = bar
foo_SOURCES = foo.cpp
bar_SOURCES = bar.cpp
Related
In A.proto, I defined an enum called Foo. Then in B.proto, I referenced this enum as:
message Bar {
.pathofA.Foo foo = 1;
}
Notice that A.proto does not have a go_proto_library declared. It's only in java. While B.proto has both go_proto_library and java_proto_library declared.
Now in C.go, I'm trying to build a Bar object, but I continuously got errors when trying to set the value for Foo. I could not import A.proto in C.go, as A does not have a go proto library. Would there be a way to reference/set value for Foo in C with only B.proto imported?
Many thanks for any help!
If I have a function foo() and use -ffunction-sections, gcc will place foo() inside its own .text.foo section. Is it possible to change the prefix of .text? Such that I get .customName.foo instead of text.foo.
I have the same problem, and I solved it using the section attribute.
The following solution is the simplest but does not create a section for each function (as the -ffunction-section parameter allows to do)
#define AT_FLASH_TEXT_SECTION(var) \
__attribute__((section(".text.flash"))) var
AT_FLASH_TEXT_SECTION(int myFunction(float param1, long param2));
So the function myFunction will appear in the section .text.flash, but also all other functions that are declared using the macro AT_FLASH_TEXT_SECTION.
To get the desired behavior I modified the macro as follows:
#define AT_FLASH_TEXT_SECTION_SYM(var, subsectionName) \
__attribute__((section(".text.flash." #subsectionName))) var
AT_FLASH_TEXT_SECTION_SYM(int myNewFunction(float param1, long param2), myNewFunction);
This is the best solution I've found so far.
Unfortunately, it is error-prone: the function name must be repeated identically in the subsectionName parameter of the AT_FLASH_TEXT_SECTION_SYM macro.
Furthermore, if two c modules contain two static functions with the same name, they will be emitted in the same section, going back to the previous problem.
I hope this helps, and maybe you can find a better solution starting from this.
No, that does not seem possible. See gcc/varasm.c (I haven't run the debugger, but am fairly sure this is the code that computes section names.)
void
default_unique_section (tree decl, int reloc)
{
[...]
switch (categorize_decl_for_section (decl, reloc))
{
case SECCAT_TEXT:
prefix = one_only ? ".t" : ".text";
break;
[...]
name = IDENTIFIER_POINTER (id);
name = targetm.strip_name_encoding (name);
[...]
string = ACONCAT ((linkonce, prefix, ".", name, NULL));
set_decl_section_name (decl, string);
}
Besides, that might be a bad idea, as e.g. linker scripts treat sections based on their names (see ld --verbose). Something like .text.customprefix.foo might be a better choice, but I don't know why you want custom prefices.
As a workaround, you can assign sections manually with the section attribute.
'section ("SECTION-NAME")'
Normally, the compiler places the code it generates in the 'text'
section. Sometimes, however, you need additional sections, or you
need certain particular functions to appear in special sections.
The 'section' attribute specifies that a function lives in a
particular section. For example, the declaration:
extern void foobar (void) __attribute__ ((section ("bar")));
puts the function 'foobar' in the 'bar' section.
I have a set of code that relay on a function foo exported by module mod.
And I have a newer version of mod that exports foo_implementation instead.
The foo became a macro there...
So, the question is: how to express EXPORT_SYMBOL() to export foo_implementation as foo?
With minimal changes to the code, if possible...
Would it be ok to change, say
void foo_implementation(int arg) { ... }
EXPORT_SYMBOL(foo_implementation);
to
void foo_implementation(int arg) { ... }
EXPORT_SYMBOL(foo_implementation);
#ifdef foo
#undef foo
#endif
void foo(int arg) { return foo_implementation(arg); }
EXPORT_SYMBOL(foo);
???
Actually, there were two ways:
Hackish, proposed in the question. It works somehow allowing you to load a module at least.
Normal one :) Just rebuild not only kmod affected, but the entire set of the code that relays on it. This will make the #defines to work properly and the problem will go itself without any violence.
I have root project and subproject (:child).
Root build looks like like this:
def foo = {
println("foo")
}
allprojects {
task bar << {
println(project.name + ":bar")
}
afterEvaluate {
foo()
}
}
Running gradle bar prints:
foo
foo
:bar
:child:bar
child:bar
parent:bar
This make sense. However, IRL I need foo to be called by the child's build file (because I want it to be called only by some of the submodules).
The documentation seems to be clear enough: In a multi-project build, sub-projects inherit the properties and methods of their parent project
However, moving the "afterEvaluate" block above into child/build.gradle results in an error: Could not find method foo() for arguments [] on project ':child' of type org.gradle.api.Project.
Why does this happen and how do I fix this? I have tried a whole bunch of different variations - moving the def around (to buildscript, allprojects, to ext, to allprojects.ext, making it a variable in ext, instead of a method etc.), referring to it differently (as rootProject.foo, rootProject.foo(), ext.foo() etc.) - nothing seems to work.
Any ideas?
Vars need to be declared in the ext namespace for them to be propagated downstream. Try:
ext.foo = {
println("foo")
}
ref: https://docs.gradle.org/current/dsl/org.gradle.api.plugins.ExtraPropertiesExtension.html
I want to know data type using variable name
My final goal is getting a function signature for making a function stub(skeleton code)
but GCC error message just notify only undefined function name
Can I see a symbol table? (for inferencing function signature)
for example, foo.c is like below
#include <stdio.h>
int main() {
int n = 0;
n = foo();
return 0;
}
I want to make a function stub
so I want to know function foo has no parameter and returns an integer value
What should I do?
I think below:
linker error message say function foo is undefined
read line 5
n = foo();
inspect type of n using symbol table
is it right?
sorry for my bad english
please teach me inferencing a function signature
Inject his code into your source file:
typedef struct { int a; char c; } badtype_t;
badtype_t badtype;
then replace the error line like this:
n = badtype; //foo();
or if you want the type foo returns:
badtype = foo();
then you will get some error like this:
incompatible types when initializing type ‘int’ using type ‘badtype_t’
and you can get the type int.
or if you want the type of foo itself:
foo * 2
then you will get some error like this:
invalid operands to binary * (have 'int (*)()' and 'int')
and you can get the type int (*)() (that is, function taking nothing and returning an int).
It seems ok, but this strategy will not be good enough. Using the left-hand side of an expression is not enough to determine the return-type of the function. In particular, there may be no left-hand side at all, simply: foo();. What then?
If you just want to see a symbol table, that's what nm is for.
For example, if you get an error linking foo.o and bar.o together, you can do this:
nm -a foo.o
That will show you all the symbols defined in module foo.
But I don't see why you think this would help. C symbols do not have any type information. There may be enough metadata to distinguish extern linkage, and/or to tell whether a symbol function or data, but that's it. There is no way to tell an int from a float, or a function taking two ints and returning a double from a function taking a char * and returning a different char *.
So, you have some function named foo defined somewhere, and you want to know what its type is.
If you don't actually have a prototype for foo somewhere in your #included header files, this is easy:
If you're using C99, your code is invalid.
Otherwise, foo must take no arguments and return int, or your code is invalid.
And this isn't one of those "technically invalid, but it works on every platform" cases; it will break. For example, with gcc 4.2 for 64-bit x86 linux or Mac, if you do this:
double foo(double f) { return f*2; }
Then, without a header file, call it like this:
double f = foo(2.0);
printf("%f\n", f);
If compiled as C89, this will compile and link just fine (clang or gcc 4.8 will give you a warning; gcc 4.2 won't even do that by default), and run, and print out 2.0. At least on x86_64; on ARM7, you'll corrupt the stack, and segfault if you're lucky. (Of course it actually does double something—either your 2.0 or some random uninitialized value—but it can't return that to you; it's stashed it in an arbitrary floating-point register that the caller doesn't know to access.)
If it is in a header file, you can always search for it. emacs, graphical IDEs, etc. are very good at this. But you can use the compiler to help you out, in two ways.
First, just do this:
gcc -E main.c > main.i
less main.i
Now search for /foo, and you'll find it.
Or you can trick the compiler into giving you an error message, as in perreal's answer.