Hey guys can we use two or more main() in different C source files under same project in eclipse? What am I actually trying is to write a server and a client source file under same project with main() in each of it. I am getting an error main() redeclaration. is there any way to do this? If yes please tell me how to run that successfully in eclipse CDT Kepler. Regards,
You could also simulate having two main functions in the same project by having main call either mainClient or mainServer (your two main functions renamed) depending on a condition of your choice.
Yes, you just have ton include each one selectively when linking your two programs.
A build system (Makefile, IDE…) helps.
Example
If you have these source files:
Client only:
main-client.c
source1-client.c
Server only:
main-server.c
source1-server.c
Common sources:
source1-common.c
source2-common.c
source3-common.c
Then a simple (stupid) Makefile is:
all: client server
client:
gcc -o client main-client.c source1-client.c source1-common.c source2-common.c source3-common.c
server:
gcc -o server main-server.c source1-server.c source1-common.c source2-common.c source3-common.c
Hey guys we can actually do it by following what Simon and Brandin suggested. Also see this example if anyone still have doubts. Thankyou!
#define my main()
my() {
printf("hello frnz");
}
So we can have as many mains as we wish. Vola
Related
I am trying to compile some source codes about UNIX scokets programs, on Linux I have no problems but on macOS I get stuck in front of types definition problems. I don't know how many details I can put here, but I'll try.
The source codes to be compiled are:
errlib.c
errlib.h
server_test.c
sockwrap.c
sockwrap.h
where the main is located in server_test.c.
To compile I use:
gcc -Wall -DTRACE -o server_test server_test.c errlib.c sockwrap.c
There are no problems running this on Linux, but on macOS I get more than 20 error and all of these are about a (perhaphs) missing definition of bool_t. I suppose something not working in /usr/include/rpc/* files located in macOS internal libraries.
So I looked for if <sys/types.h> is included in /usr/include/rpc/xdr.h and it seems to be not missing.
Some of the first lines of the gcc output are:
In file included from server_test.c:16:
/usr/include/rpc/xdr.h:126:3: error: type name requires a specifier or qualifier
bool_t (*x_getlong)(struct __rpc_xdr *, int *);
^
/usr/include/rpc/xdr.h:126:10: error: function cannot return function type 'int (struct __rpc_xdr *, int *)'
bool_t (*x_getlong)(struct __rpc_xdr *, int *);
^
/usr/include/rpc/xdr.h:128:3: error: type name requires a specifier or qualifier
bool_t (*x_putlong)(struct __rpc_xdr *, const int *);
^
/usr/include/rpc/xdr.h:128:10: error: function cannot return function type 'int (struct __rpc_xdr *, const int *)'
bool_t (*x_putlong)(struct __rpc_xdr *, const int *);
^
/usr/include/rpc/xdr.h:128:3: error: duplicate member 'bool_t'
bool_t (*x_putlong)(struct __rpc_xdr *, const int *);
^
/usr/include/rpc/xdr.h:126:3: note: previous declaration is here
bool_t (*x_getlong)(struct __rpc_xdr *, int *);
^
/usr/include/rpc/xdr.h:136:3: error: type name requires a specifier or qualifier
bool_t (*x_getbytes)(struct __rpc_xdr *, char *, unsigned int);
...
and many others lines that are very similar.
For those who want to deepen, the sources are available here.
What could be the problem?
The bad answer
Issue solved by simply including <rpc/types.h> in the server_test.c source as follows:
#include <rpc/types.h>
The better one
This is a solution above is valid only for this server_test.c implementation.
If you want fix this issue "globally", you can follow follown steps:
disable SIP (how to? here)
get your macOS's xdr.h (from here /usr/include/rpc/xdr.h)
copy it elsewhere two times: one copy is for backup and modify the other one simply adding the required include (#include <rpc/types.h> and see the picture below)
overwrite your modified xdr.h onto the original one in /usr/include/rpc/
re-enable SIP
Here is how I did it:
I've added a new function wiringPiVersion() to wiringPi, but after I build and install the shared library, when I attempt to compile a small C program around it, I get:
wpi_ver.c:(.text+0xc): undefined reference to `wiringPiVersion'
However, when I include it in an XS based Perl module, all works well. I don't know enough about C to figure out what's going wrong here, and I've been searching for the better part of two hours trying different things to no avail.
Here's my small C program to test the new function:
#include <stdio.h>
#include <wiringPi.h>
int main (){
char * ver = wiringPiVersion();
printf("wiringPi version: %s\n", ver);
return 0;
}
Compilation that throws the error:
gcc -o ver wpi_ver.c -lwiringPi
The addition to wiringPi's header file:
extern char * wiringPiVersion(void);
The wiringPi's .c file addition:
#define WPI_VERSION "2.36"
char * wiringPiVersion(void){
return WPI_VERSION;
}
In my Perl module's XS file, I have:
char *
wiringPiVersion()
...and my Perl module's Makefile.PL
LIBS => ['-lwiringPi'],
...and after re-installing the Perl module, I can access the function without any issues in a test script.
I'm hoping this is something simple I'm overlooking which someone may be able to point out. My question is, how do I rectify this?
So it turned out that there were two .so files generated when I rebuilt wiringPi... one in the wiringPi's build directory way under my home directory, and the other in /usr/local/lib.
After a tip in comments, I added the library path explicitly:
gcc -o ver wpi_ver.c -L/usr/local/lib -lwiringPi
...and it all fell together and works as expected:
$ ./ver
wiringPi version: 2.36
Note: I have sent Gordon the patch in hopes it gets included in the next wiringPi cut.
Update: I received an email back from Gordon and he stated that currently, only the gpio application has the ability to report the version, so he advised that he's going to add something similar to my patch in a future release.
Although already solved, I added this answer to show what gave me the hint.
Error message "undefined reference" points to a linker error (cf. answer on SO), so its about checking if the correct library is drawn.
I created windows console program project in visual studio, and made two c language files. Both has same source:
#include<stdio.h>
int main() {
printf("hello");
}
When I try to compile, compiler screams about having two main()s. See below:
I can't understand. I thought two files in one project works separately. Am I wrong?
Yes, you are wrong. IIRC, the whole project is compiled and then linked to form a single executable.
In a single executable, there can be only one main() function.
These two main functions are within the same Project. You should have only one main function in your program.
Try to implement a new project, and then add the main function in there.
I'm trying to use YCM for the first time so in order to make it work I decided to give a chance for the YCM-Generator, which generates the .ycm_extra_conf.py file automatically based on the makefile.
So far my program is just a simple hello world.
#include <stdio.h>
int main()
{
printf("Hello World!");
return 0;
}
I'm using the CMakeLists.txt trick to generate the makefile.
file(GLOB sources *.h *.c)
add_executable(Foo ${sources})
then after executing the YCM-Generator script, I get this output
Running cmake in '/tmp/tmp_YknVy'... $ cmake
/home/pedro/Desktop/Projetos/teste
Running make... $ make -i -j4
Cleaning up...
Build completed in 1.5 sec
Collected 2 relevant entries for C compilation (0 discarded).
Collected 0 relevant entries for C++ compilation (0 discarded).
Created YCM config file with 0 C flags
YCM plugin does find the .ycm_extra_conf.py file, but the auto-completion doesn't work right, for example, if I type "floa", it doesn't suggests "float", but It only suggests things that I used before like "int" or "printf".
Am I missing something or this is working as intended?
So I fixed it.
For c it does require a .ycm_extra_conf.py , while a friend of mine could make it work without one in c++.
The auto complete only suggest automatically functions that were previously used, if you don't remember a function name you have to press <Ctrl-Space>
YCM-Generator didn't do the job, so I modified the example file myself following the comments.
If you are used to Visual Assist, the auto complete works but it's really weak if compared to VA, which is a shame... I really hope someone port that plugin to Linux.
I'm currently developing an application using SDL. In order to utilize it, I have already added the library and header files in the project's settings under C/C++ Build -> Settings -> Tool Settings -> Libraries/Includes. However, when I try to build a test program like
#include <stdio.h>
#include <SDL/SDL.h>
int main(int argc, char *argv[])
{
SDL_Init(SDL_INIT_EVERYTHING);
SDL_Quit();
return 0;
}
I get this beautiful error message during the link process:
d:/programme/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../libmingw32.a(main.o): In function main':
C:\MinGW\msys\1.0\src\mingwrt/../mingw/main.c:73: undefined reference toWinMain#16'
Which is rather weird, given that the directory C:\MinGW doesn't even exist at all.
The command used for linking is this one:
gcc "-LD:\Programme\SDL\lib" -o test.exe test.o -lsdl
After two hours of trying to get a library link to work, I'm pretty confused and have no idea what I'm doing wrong. Help would be appreciated.
It looks like you are building a Windows GUI application, which requires a WinMain, while your code only provides a main function which would be for console applications.
So if this is supposed to be a console application, you must adjust your linker settings accordingly, or you must declare a WinMain.