I am writing a program that could very much use __sync_fetch_and_add. Unfortunately my autoconf script that searches for it with this fairly straightforward test:
AC_CHECK_FUNCS([__sync_fetch_and_add])
Generates this error:
Wsuggest-attribute=noreturnconftest.c:56:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
conftest.c:56:6: warning: conflicting types for built-in function '__sync_fetch_and_add' [enabled by default]
conftest.c:65:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
/tmp/ccqPsZz4.o: In function `main':
/home/simsong/domex/src/bulk_extractor/tags/1.2.x/conftest.c:67: undefined reference to `__sync_fetch_and_add'
collect2: ld returned 1 exit status
This is super-annoying, because I would like to use the function, but some people on some platforms have told me that it doesn't compile properly. I want a prototype, but there doesn't seem to be one.
Thanks.
AC_CHECK_FUNCS is not usable in this case, since redeclarating the function — which autoconf does (char functionthatiwant() in conftest.c/config.log) — will override the builtin function detrimentally. You would need something like the following instead.
AC_MSG_CHECKING([for __sync_fetch_and_add])
AC_LINK_IFELSE(
[AC_LANG_SOURCE([
int main(void) { return __sync_fetch_and_add((int *)0, 0); }
])],
[AC_MSG_RESULT([yes])],
[AC_MSG_RESULT([no])]
)
Related
I have written a simple jiffies code and when I try to do rmmod I get
ERROR: Removing 'jiffi_module': Device or resource busy
so I did bit of research and found by doing lsmod below symptom of "permanent" being the problem which is caused by exit_function not being found.
Module Size Used by
jiffi_module 1027 0 **[permanent]**
infact my make file do show me warning related to exit function
Warning when exit function is defined as
static void __exit
jif_exit(void)
{
remove_proc_entry("jif", NULL);
}
warning: data definition has no type or storage class
warning: type defaults to ‘int’ in declaration of ‘modile_exit’
warning: parameter names (without types) in function declaration
warning: ‘jif_exit’ defined but not used
when I remove the __exit seems it atleast identifies jif_exit - so now the warning I get is
warning: data definition has no type or storage class
warning: type defaults to ‘int’ in declaration of ‘modile_exit’
warning: parameter names (without types) in function declaration
Reading through below Why is this kernel module marked at permanent on 2.6.39
it talks about gcc mismatch being a problem ? Can someone please help I am not able to debug it further ? Any pointers how to load module properly such that its not permanent?
Kernel module is marked as permanent (cannot be unloaded) if there is no exit function is defined for it.
exit function accepts no arguments and return nothing and should be defined either with predefined name
void cleanup_module(void)
{
...
}
or with arbitrary name but registered with module_exit macro
void <func_name>(void)
{
...
}
module_exit(<func_name>);
static, __exit and other attributes for exit function are optional.
Well, it's a very strange error I met.
When I try to compile my program with the fftw library by the command:
g++ -std=c++11 -o main main.cpp BFSCcommandlineParser.cpp BFSCframe.cpp BFSCgeometry.cpp ImageIO.cpp -lfftw3 -lm
... I get this:
/tmp/cczUuTb0.o: In function `fftw_prog::fftw_prog(char const*)':
main.cpp:(.text._ZN9fftw_progC2EPKc[_ZN9fftw_progC5EPKc]+0x5c): undefined reference to `fftwf_import_wisdom_from_file'
/tmp/cczUuTb0.o: In function `fftw_prog::~fftw_prog()':
main.cpp:(.text._ZN9fftw_progD2Ev[_ZN9fftw_progD5Ev]+0x31): undefined reference to `fftwf_export_wisdom_to_file'
/tmp/cczUuTb0.o: In function `fft<2, float, std::complex<float> >::fft(tensor<int, 2ul>, bool)':
main.cpp:(.text._ZN3fftILi2EfSt7complexIfEEC2E6tensorIiLm2EEb[_ZN3fftILi2EfSt7complexIfEEC5E6tensorIiLm2EEb]+0xcf): undefined reference to `fftwf_plan_dft_r2c'
main.cpp:(.text._ZN3fftILi2EfSt7complexIfEEC2E6tensorIiLm2EEb[_ZN3fftILi2EfSt7complexIfEEC5E6tensorIiLm2EEb]+0x111): undefined reference to `fftwf_plan_dft_c2r'
/tmp/cczUuTb0.o: In function `fft<2, float, std::complex<float> >::~fft()':
main.cpp:(.text._ZN3fftILi2EfSt7complexIfEED2Ev[_ZN3fftILi2EfSt7complexIfEED5Ev]+0x25): undefined reference to `fftwf_free'
main.cpp:(.text._ZN3fftILi2EfSt7complexIfEED2Ev[_ZN3fftILi2EfSt7complexIfEED5Ev]+0x35): undefined reference to `fftwf_destroy_plan'
main.cpp:(.text._ZN3fftILi2EfSt7complexIfEED2Ev[_ZN3fftILi2EfSt7complexIfEED5Ev]+0x45): undefined reference to `fftwf_destroy_plan'
/tmp/cczUuTb0.o: In function `fft<2, float, std::complex<float> >::r2F()':
main.cpp:(.text._ZN3fftILi2EfSt7complexIfEE3r2FEv[_ZN3fftILi2EfSt7complexIfEE3r2FEv]+0x25): undefined reference to `fftwf_execute'
/tmp/cczUuTb0.o: In function `fft<2, float, std::complex<float> >::F2r()':
main.cpp:(.text._ZN3fftILi2EfSt7complexIfEE3F2rEv[_ZN3fftILi2EfSt7complexIfEE3F2rEv]+0x35): undefined reference to `fftwf_execute'
collect2: error: ld returned 1 exit status
I thought it could be a problem of fftw itself, so I tested the library with a proram, and it worked. That means that it's not so.
The following code is a template from my file which is the only one in my project that uses fftw.
template <int N, typename rT, typename FT>
inline fft<N,rT,FT>::~fft() {
if (data != 0) {
if (Precision<rT>::IsFloat) {
fftwf_free((fftwf_complex *)data);
fftwf_destroy_plan((fftwf_plan_s*) r2Fplan);
fftwf_destroy_plan((fftwf_plan_s*) F2rplan);
}
else {
fftw_free((fftw_complex *)data);
fftw_destroy_plan((fftw_plan_s*) r2Fplan);
fftw_destroy_plan((fftw_plan_s*) F2rplan);
}
}
}
For single precision (float) you need to link the libfftwf library, for double precision (double) you need the libfftw library. I would guess you are just linking the latter and not the former. For gcc et al the command line needs to contain -lfftw3 -lfftw3f if you want both double and single precision support.
I'm using GCC (CygWin) cross-compiling targeting an Arm7 processor. the problem is none of the standard library functions are available for my program. as I understand it, libc.a is the library i should be using. strangely, this file has been copied to the application source directory.
I would've thought if I did the following, I should be able to use these functions:
have included (enclosed in <>) string.h and stdlib.h in my LCD.c file
mention libc.a to the linker
During make, here's what it says:
$ make
.compiling
..linking
arm-elf-ld -v -Map main.map -nostartfiles -T simple.cmd -o main.out start.o ivt.
o main.o libc.a LCD.o
GNU ld version 2.14 20030612
LCD.o(.text+0x75c): In function `LCD_DispSmallDigits':
: undefined reference to `strlen'
LCD.o(.text+0x22d4): In function `LCD_DispSelMsgAt':
: undefined reference to `malloc'
LCD.o(.text+0x22e0): In function `LCD_DispSelMsgAt':
: undefined reference to `strcpy'
LCD.o(.text+0x2308): In function `LCD_DispSelMsgAt':
: undefined reference to `free'
LCD.o(.text+0x2358): In function `LCD_DispNumMsgAt':
: undefined reference to `malloc'
LCD.o(.text+0x2368): In function `LCD_DispNumMsgAt':
: undefined reference to `sprintf'
LCD.o(.text+0x2384): In function `LCD_DispNumMsgAt':
: undefined reference to `free'
the code I'm using is quite mundane:
void LCD_DispSelMsgAt(int iRow, int iCol, int bSelected, char* s)
{
int i;
char* sBuffer = (char*) malloc(100);
strcpy(sBuffer, s);
if (bSelected)
for (i=0; i<strlen(sBuffer); i++)
if ((*(sBuffer + i)>='a') && (*(sBuffer + i)<='z'))
*(sBuffer + i) = (*(sBuffer + i)) - 0x20;
LCD_DispMsgAt(iRow, iCol, sBuffer);
free(sBuffer);
}
how can I get access to those standard routines?
thank you!
PS: it seems to me I'm having quite a "general" problem so what I'm about to say is not central to this question but i'll mention it anyway...
I noticed something that specifically relates to strlen( ). the prototype for strlen( ) has the parameter as "const char* s". it seems then it works fine with:
i = strlen("abc")
but not in the code sample routine shown above. that wouldn't be a very helpful library routine that can't be used as strlen(char* s).
reply to #n.m.:
adding /gnude/arm-elf/lib/libc.a to the linker command line introduced a "thousand" errors.
$ make
..linking
arm-elf-ld -v -Map main.map -nostartfiles -T LinkerScript.cmd -L /gnude/arm-elf/
lib -o main.out start.o ivt.o main.o LCD.o /gnude/arm-elf/lib/libc.a
GNU ld version 2.14 20030612
/gnude/arm-elf/lib/libc.a(syscalls.o)(.text+0x714): In function `_sbrk':
: undefined reference to `end'
/gnude/arm-elf/lib/libc.a(vfprintf.o)(.text+0x8c0): In function `_vfprintf_r':
: undefined reference to `__eqdf2'
/gnude/arm-elf/lib/libc.a(vfprintf.o)(.text+0x1054): In function `_vfprintf_r':
: undefined reference to `__nedf2'
/gnude/arm-elf/lib/libc.a(vfprintf.o)(.text+0x155c): In function `_vfprintf_r':
: undefined reference to `__umoddi3'
/gnude/arm-elf/lib/libc.a(vfprintf.o)(.text+0x1578): In function `_vfprintf_r':
: undefined reference to `__udivdi3'
/gnude/arm-elf/lib/libc.a(vfprintf.o)(.text+0x1834): In function `_vfprintf_r':
: undefined reference to `__ltdf2'
/gnude/arm-elf/lib/libc.a(vfprintf.o)(.text+0x1d98): In function `cvt':
: undefined reference to `__eqdf2'
/gnude/arm-elf/lib/libc.a(vfprintf.o)(.text+0x1e10): In function `cvt':
: undefined reference to `__nedf2'
/gnude/arm-elf/lib/libc.a(vfprintf.o)(.text+0x1e30): In function `cvt':
: undefined reference to `__negdf2'
/gnude/arm-elf/lib/libc.a(dtoa.o)(.text+0x7c): In function `_dtoa_r':
: undefined reference to `__eqdf2'
not sure what i should do next. i think i'll start by removing the explicit libc.a from the linker command line.
I have been told that you could add some special instruction to your code to make GCC issue a warning when it detects that 0 is being passed as an argument (which means, when it is possible at compile-time).
I have looked for it but haven’t been able to find it. Is this true?
There is a function attribute you can use to warn on null pointers:
void foo(void *data) __attribute__((nonnull));
int main(void)
{
foo(0);
return 0;
}
$ gcc -Wall -c t.c
t.c: In function ‘main’:
t.c:5:5: warning: null argument where non-null required (argument 1) [-Wnonnull]
I'm not aware of anything built-in to check for 0 for integer types though.
You might find something that suits your need in the various BUILD_BUG_* macros from the Linux kernel though. They're in include/linux/kernel.h. (Cross-referenced here.)
I'm trying to compile a file with the V8 the JavaScript Engine by Google. I installed scons and have compiled the V8 engine. But, here is where the problem lies, I stay in the V8 directory as they say and make a file named hello_world.cpp with the code:
#include <v8.h>
using namespace v8;
int main(int argc, char* argv[]) {
// Create a stack-allocated handle scope.
HandleScope handle_scope;
// Create a new context.
Persistent<Context> context = Context::New();
// Enter the created context for compiling and
// running the hello world script.
Context::Scope context_scope(context);
// Create a string containing the JavaScript source code.
Handle<String> source = String::New("'Hello' + ', World!'");
// Compile the source code.
Handle<Script> script = Script::Compile(source);
// Run the script to get the result.
Handle<Value> result = script->Run();
// Dispose the persistent context.
context.Dispose();
// Convert the result to an ASCII string and print it.
String::AsciiValue ascii(result);
printf("%s\n", *ascii);
return 0;
}
Then I compile using gcc hello_world.cpp -o libv8.a. But, when I compile it I get a skew of errors:
hello_world.cpp:1:16: error: v8.h: No such file or directory
hello_world.cpp:3: error: ‘v8’ is not a namespace-name
hello_world.cpp:3: error: expected namespace-name before ‘;’ token
hello_world.cpp: In function ‘int main(int, char**)’:
hello_world.cpp:8: error: ‘HandleScope’ was not declared in this scope
hello_world.cpp:8: error: expected `;' before ‘handle_scope’
hello_world.cpp:11: error: ‘Persistent’ was not declared in this scope
hello_world.cpp:11: error: ‘Context’ was not declared in this scope
hello_world.cpp:11: error: ‘context’ was not declared in this scope
hello_world.cpp:11: error: ‘Context’ is not a class or namespace
hello_world.cpp:15: error: ‘Context’ is not a class or namespace
hello_world.cpp:15: error: expected `;' before ‘context_scope’
hello_world.cpp:18: error: ‘Handle’ was not declared in this scope
hello_world.cpp:18: error: ‘String’ was not declared in this scope
hello_world.cpp:18: error: ‘source’ was not declared in this scope
hello_world.cpp:18: error: ‘String’ is not a class or namespace
hello_world.cpp:21: error: ‘Script’ was not declared in this scope
hello_world.cpp:21: error: ‘script’ was not declared in this scope
hello_world.cpp:21: error: ‘Script’ is not a class or namespace
hello_world.cpp:24: error: ‘Value’ was not declared in this scope
hello_world.cpp:24: error: ‘result’ was not declared in this scope
hello_world.cpp:30: error: ‘String’ is not a class or namespace
hello_world.cpp:30: error: expected `;' before ‘ascii’
hello_world.cpp:31: error: ‘ascii’ was not declared in this scope
hello_world.cpp:31: error: ‘printf’ was not declared in this scope
I don't get why it say V8.h is not declared. I already built it and I'm in its directory and I'm guessing if I get rid of that all the other errors will go away. Any suggestions?
i just believe you in that you are really inside the toplevel source directory (and since i do not have compiled v8 i only believe that libvp8.a is created in that toplevel directory):
% g++ -Iinclude hello_world.cpp -o hello_world libv8.a
it says "v8.h" is not declared because that file is inside the "include" directory and the preprocessor is not able to find it out of thin air.
furthermore: you are compiling a .cpp file with the C compiler instead of the C++ compiler.
you are using the '-o' flag wrong because it defines the name of the linked binary and thus needs a name, you do not want the output binary be named "libvp8.a"