during compiling older C++ code on Ubuntu 11.10 with mpic++ (Open MPI C++ wrapper compiler) I got this warning connected with int main(int argc, char **argv){...}:
main(int, char**) : warning: deprecated conversion from string constant to ‘char*’
I tried to edit the code to int main(int argc, const char *argv[]){...} but it did not help (contrary to e.g. this issue).
What did I wrong? How can I fix it?
Related
I have a simple program to test basename() method:
#include <stdio.h>
#include <string.h>
//#include <libgen.h>
int main (int argc , char **argv)
{
char *a = strdup("test();");
printf("%s", basename(a));
return 0;
}
clang complains but it compiles anyway.
test.c:7:18: warning: implicit declaration of function 'basename' is invalid in C99 [-Wimplicit-function-declaration]
printf("%p", basename(a));
^
test.c:7:18: warning: format specifies type 'void *' but the argument has type 'int' [-Wformat]
printf("%p", basename(a));
And it results in segfault. But if I added libgen.h header, it works normally.
I've checked the binary with otool, it linked against the same dylib, nothing else. Why does the first one crash?
I've checked the answer here already, it uses a static buffer but I use the result from strdup(), so it's a different question.
The program does nothing except farewell to the world:
/* Ubuntu 18.04 with GCC 10.1.0 and libstdc++-10-dev */
#include <memory_resource>
#include <concepts>
#include <ranges>
#include <string_view>
/* declare global memory resource */
std::pmr::synchronized_pool_resource pool;
int main(int argv, char * argc[]){
std::puts("Goodbye World!");
}
It compiles fine, but terminates with SEGV on
/usr/include/c++/10/memory_resource
line 445, in constructor of SPR:
synchronized_pool_resource()
: synchronized_pool_resource(pool_options(), get_default_resource())
[Unknown/Just-In-Time compiled code] (Unknown Source:0)
libstdc++.so.6!std::pmr::synchronized_pool_resource::synchronized_pool_resource(std::pmr::pool_options const&, std::pmr::memory_resource*) (Unknown Source:0)
std::pmr::synchronized_pool_resource::synchronized_pool_resource(std::pmr::synchronized_pool_resource * const this) (/usr/include/c++/10/memory_resource:445)
__static_initialization_and_destruction_0(int __initialize_p, int __priority) (/data/solution/projects/test/source/main.cpp:10)
_GLOBAL__sub_I__Z4testRNSt3pmr26synchronized_pool_resourceE() (/data/solution/projects/test/source/main.cpp:16)
__libc_csu_init (Unknown Source:0)
libc.so.6!__libc_start_main(int ()(int, char **, char **) main, int argc, char ** argv, int ()(int, char **, char **) init, void ()(void) fini, void ()(void) rtld_fini, void * stack_end) (/build/glibc-OTsEL5/glibc-2.27/csu/libc-start.c:266)
_start (Unknown Source:0)
The chain of calls on stack explains me that the program might have been linked to libstdc++.so.6. Is this a possible reason and if so, what shall I do?
I was using
GNU gdb (Ubuntu 8.2-0ubuntu1~18.04) 8.2
for debugging. Would it be because GDB is not ready for this?
BTW: I really wasn't capable of using this editor to past images. It just doesn't show up.
You need to add -pthread to your g++ linking call. I can't fault you if you think there should be a comprehensible error message…
I'm trying to run some tests on vsoc_beta using arm-elf-gcc and arm-rtems-gcc. However, both compilers gave me the same error:
/home/student/vsoc-beta/apps/libgomp/root.o: In function `main':
/home/student/vsoc-beta/apps/libgomp/libgomp.c:24: multiple definition of `main'
app_obj.o:/home/student/vsoc-beta/apps/rotate/rot.c:103: first defined here
/home/student/vsoc-beta/apps/libgomp/root.o: In function `main':
root.c:(.text+0x219c): undefined reference to `_app_main'
root.c:(.text+0x2298): undefined reference to `_app_main'
make: *** [o-optimize/app.exe] Error 1
These tests are using libgomp and in libgomp.c there's a line:
extern int _app_main(int argc, char **argv, char **envp);
and the main is defined as:
int main(int argc, char **argv, char **envp)
In the test files, there is another main function:
int main(int argc, char **argv)
What could be the problem?
As the first error is a "Multiple definition of main" you must decide first which of the 2 main function you have is the application entry point.
An application as only one entry point or main function.
Here is my test program:
#include <stdio.h>
#pragma GCC diagnostic ignored "-Wcast-qual"
static void proc(char *buf)
{
printf("buf=%p\n",buf);
}
int main(int argc,char **argv)
{
const char *cbuf;
char *buf = (char *)cbuf;
proc(buf);
return(0);
}
Here is my compile:
$ g++ -Wcast-qual x.cpp
x.cpp: In function ‘int main(int, char**)’:
x.cpp:13: warning: cast from type ‘const char*’ to type ‘char*’ casts away constness
$
And here is the compile without the -Wcast-qual:
$ g++ x.cpp
$
I've used #pragma GCC diagnostic ignored in other places of my code without problems. Here it is not working. Can somebody tell me why?
It's a compiler bug on the Mac. GCC 4.7.2 on Linux does not have this problem. Neither does clang++. On the Mac you should try to use clang++, not g++.
Apple should update its compiler.
I'm using Xcode 3.2 on Mac OS 10.6 to build a very simple HelloWorld program for CUDA
but it fails to build .. any ideas !!!
this is the code :
#include <iostream>
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
#include <CUDA/CUDA.h>
__device__ char napis_device[14];
__global__ void helloWorldOnDevice(void){
napis_device[0]='H';
napis_device[1]='e';
napis_device[2]='l';
napis_device[3]='l';
napis_device[4]='o';
napis_device[5]=' ';
napis_device[6]='W';
napis_device[7]='o';
napis_device[8]='r';
napis_device[9]='l';
napis_device[10]='d';
napis_device[11]='\n';
}
int main (int argc, char * const argv[]) {
helloWorldOnDevice<<<1,1>>> ();
cudaThreadSynchronize();
char napis_host[14];
const char *symbol="napis device";
cudaMemcpyFromSymbol (napis_host, symbol, sizeof(char)*13, 0, cudaMemcpyDeviceToHost);
return 0;
}
The error appears at this line
helloWorldOnDevice<<<1,1>>> ();
Expected primary-expression before '<' token !!!!!!
You're compiling your program with gcc coming with Xcode. Should use nvcc compiler instead to compile CUDA code. Normally I would use a Makefile to tell that *.cu to be compiled by nvcc and *.cpp by gcc, then link produced objects to an executable.