Compiling a C program without Main [duplicate] - c++

This question already has answers here:
How to compile C source code without a main function?
(6 answers)
Closed 7 years ago.
I have a simple C program I have to make (Which can't use a main function).
As such:
test.c
#include <stdio.h>
int getUserID(int id);
int getUserID(int id) {
return 0;
}
Where my current function does nothing as of now:
However, I'm trying to compile this through a makefile, as such:
all:
gcc test.c
Which didn't work because I didn't have a main so then I added the -c command within it.
all:
gcc -c test.c
Which now compiles with make, but gives me an object file (but without a working executable), the executable I get when I try to run it: i.e ./test tells me permission denied
Any help would be greatly appreciated.

You cannot have a C++ or C program without a main (without evil, non-standard hacks at least). You can build a library without a main, but not a standalone executable.
For standalone applications, the main function is crucial because it defines where to start execution.

You can create an image where "main" is not the entry point.
Here is one such way (using gcc on a RHEL6 system):
$ cat sample.c
#include <stdio.h>
#include <unistd.h>
int notmain ( void ) {
printf("hello, world\n");
exit(0);
}
$ cc -ffreestanding -c sample.c
$ ld -enotmain -o sample sample.o -I/lib64/ld-linux-x86-64.so.2 -lc
$ ./sample
hello, world
And, BTW, this is not an "evil, non-standard hack" -- the C Standard defines two execution environments: (1) "hosted", which is the one most people are familiar with, and (2) "freestanding", which is typically some sort of embedded system (a toaster or whatnot).

You can separately compile this c file into an object file, but it will need to be linked with another object file containing the main function to become an executable program.
If you are not allowed to have a main function in this file, there must be another file you are expected to link with it.

Related

Mixed Fortran/C++ with intel compilers: undefined references to 'system_'

I am working on a large mixed-language code in Fortran 1990 and C++ 11. I recently compiled on a new platform with intel compilers (which I have successfully used before), specifically Intel Version 19.1.1.217.
I have boiled the issue down to a simple test:
f.F90
subroutine ff()
implicit none
call system('echo y')
end subroutine ff
main.cc
#include <iostream>
extern "C"
{
void ff_(void);
}
int main(void)
{
ff_();
return 0;
}
I have emulated exactly how my code is built, which boils down to this:
mpif90 -f90=ifort -c f.F90 -o f.o
mpicxx -cxx=icpc -c main.cc -o main.o
mpicxx -cxx=icpc main.o f.o -L/software/intel/2020.1/compilers_and_libraries/linux/lib/intel64 -lifcore
...after which I get the following:
f.o: In function `ff_':
f.F90:(.text+0xd): undefined reference to `system_'
I am aware that calls to system() are not part of the stardard, but I can successfully compile and run the following with no problem:
p.F90:
program ff
implicit none
call system('echo y')
end program
mpif90 -f90=ifort p.f90 -o pexe && ./pexe
y
This suggests to me that using mpif90 -f90=ifort is imlicitly telling the linker to link in some extra libraries, but running ldd on the resulting executable shows a subset of the libraries linked in when I compile a simple C++ program.
What do I need to link to stop this error?
Well, I stumbled upon the solution immediately after asking this question. By using mpif90 -f90=ifort -v (source files) I was able to see everything that was being linked, and tried each library one at a time until it worked.

Compiling several source (main and headers) files and linking them in ROOT CINT?

Let me first set the context, it is CERN's ROOT and CINT and ACLiC etc.
Suppose I have a main macro named macro.cpp and two headers h1.cpp (contains the definition of a function) and h1.h containing the declaration of the function defined in h1.cpp similarly I have h2.cpp and h2.h. The main program macro.cpp calls those functions inside h1 and h2. I was successful compiling the source files using:
root [0] .L h1.cpp+
root [1] .L h2.cpp+
root [2] .L macro.cpp+
which generated three .so files macro_cpp.so, h1_cpp.so and h2_cpp.so. I want to know what to do with them ? How do I link them so that I have something like a "macro.out" or something like that (a single executable file of some kind) which I can execute (although I don't know how !) and achieve whatever I wished to achieve with the macro.
Note: If I just load all the files using .L file_name.cpp etc and just execute the main macro using .x macro.cpp then everything works fine and I have results, but this is not what I want ! I want to compile like we do in usual g++ and by the way in every forum everyone keeps advising on compiling using .L file_name.cpp+ or ++ .. I would really like to know the whole story. Because nobody seems to explain beyond .L file_name.cpp+ .. what next ? What to do with the .so etc.
I am a beginner, I will really appreciate a simple and step by step answer and explanation.
Thanks.
Edit-1: I am working with:
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Edit-2: ROOT related information:
ROOT 5.34/36 (v5-34-36#v5-34-36, dic 07 2016, 23:31:51 on linuxx8664gcc)
CINT/ROOT C/C++ Interpreter version 5.18.00, July 2, 2010
If you want to compile and link you can use a standard compiler instead of Cint/Aclic.
For example, assuming you are working on a *nix platform, you can use the example files below:
h1.h
int add_one(int a);
h1.cpp
#include "h1.h"
int add_one(int a)
{
return a+1;
}
h2.h
#include <TLorentzVector.h>
TLorentzVector multiply_by_two(const TLorentzVector v);
h2.cpp
#include "h2.h"
TLorentzVector multiply_by_two(const TLorentzVector v)
{
return 2.0*v;
}
macro.cpp
#include "h1.h"
#include "h2.h"
#include <TLorentzVector.h>
#include <iostream>
using std::cout;
using std::endl;
int main()
{
int a = 0;
TLorentzVector v;
v.SetPtEtaPhiM(1.0, 0.0, 0.0, 0.0);
cout<<"calling add_one on "<<a<<": "<<add_one(a)<<endl;
cout<<"calling multiply_by_two on "<<v.Pt()<<": "<<multiply_by_two(v).Pt()<<endl;
return 0;
}
Then you can compile with
g++ -c -g -Wall `root-config --cflags` h1.cpp
g++ -c -g -Wall `root-config --cflags` h2.cpp
g++ -c -g -Wall `root-config --cflags` macro.cpp
and link with
g++ `root-config --glibs` h1.o h2.o macro.o
The executable will be a.out:
$ ./a.out
calling add_one on 0: 1
calling multiply_by_two on 1: 2
You can put these g++ commands in a script or, when you start having several files and directories, you can write your make file (or cmake). For this last step, see for example the tutorial here
http://www-pnp.physics.ox.ac.uk/~brisbane/Teaching/Makefiles/Tutorial_1_Makefiles_and_ROOT.pdf
Note 1: one advantage of using g++ is that you will get clear error messages when something doesn't compile. The error messages from Cint can
be difficult to understand--although this is very much improved in root 6 with Cling.
Note 2: another advantage of using a standard compiler is that you will be able to easily link your main executable against libraries other than root.
This answer is based mostly on the answer by user2148414, but if one follows the answer will notice that there were some issues with the method of linking the source (*.cpp) files. My answer also addresses another important object called a TApplication that will play a crucial role in such applications involving root libraries. The following linking step:
g++ `root-config --glibs` h1.o h2.o macro.o
will likely show a lot of errors complaining about the root objects like TWhatever (in user2148414's answer TLorentzVector will show problems). In the comments to that answer one can find the discussion on including various physics libraries that can solve the problem but without discussing that (and I am not comfortable either :) ) let me write down the command that solves everthing.
This procedure is a one-liner, that is no need to compile individual files, create *.cpp files and *.h files as discussed in that answer then compile and link and create a single executable named "someExecutable" using:
g++ macro.cpp h1.cpp h2.cpp `root-config --libs --cflags` -o someExecutable
or better (and one should do it)
g++ -Wall -Wextra -Werror -pedantic -std=c++14 macro.cpp h1.cpp h2.cpp `root-config --libs --cflags` -o someExecutable
This will solve my original answer but for completeness I would like to add a few more things.
TApplication
My original motivation was to create an application that talks to "ROOT" but I didn't want to work with the ROOT shell, CINT, ACLiC etc and wanted to work entirely with g++. user2148414's and my answer will solve the part of creating an application but the application will not serve any purpose, it will run, create histograms draw them and do all the stuff but all the canvases will close in the end when the code reaches "return 0;". To keep the canvases open we will need "TApplication". So the consider the main of user2148414's answer, I am going include just two more lines and include two arguments to the main:
macro.cpp
#include "h1.h"
#include "h2.h"
#include <TLorentzVector.h>
#include <iostream>
using std::cout;
using std::endl;
int main(int argc, char* argv[]) //introduced arguments to main
{
// here I introduce TApplication
TApplication* SomeApp = new TApplication("SomeApp",&argc, argv);
int a = 0;
TLorentzVector v;
v.SetPtEtaPhiM(1.0, 0.0, 0.0, 0.0);
cout<<"calling add_one on "<<a<<": "<<add_one(a)<<endl;
cout<<"calling multiply_by_two on "<<v.Pt()<<": "<<multiply_by_two(v).Pt()<<endl;
//and just before returning 0
SomeApp->Run();
return 0;
}

include class and compile with g++

Im a beginner in C++ and working with unix. So here is my question.
I`ve written few lines in the main-function, and i needed a function, that is defined in the c_lib - library.
main.cpp:
#include <iostream>
#include "c_lib.cpp"
int main()
{
return 0;
}
i want to execute it on the terminal, so i wrote
g++ -c c_lib.cpp
g++ -c main.cpp
g++ -o run c_lib.o main.o
Until here, there is no error report.
Then
./run
I get the error
error: ./run: No such file or directory
What's wrong?
Including a .cpp is not usually done, usually only headers are included. Headers usually contain the declarations that define the interface to the code in the other .cpp
Can you show us the source of c_lib? That may help.
As the source of c_lib is #included, there is no need to compile it seperately. In fact this can/will cause errors (multiple definitions being the first to come to mind). You should only need to do:
g++ -o run main.cpp
to compile your code in this case.
(When using a header (.h), you will need to compile the implementation (.cpp) seperately)
Compile with warnings turned on:
g++ -Wall -Wextra -o run main.cpp
and you will get more output if there are problems with your code.
Is the run file being output by gcc? You can test by calling ls in the terminal (or ls run to only show the executable if it is present).
If the executable is present, it could be that it isn't marked as runnable. I'll go into that if it is a problem as it is outside the general scope of the site (though still related)
First of all you should not include source file into another source. You should create a header file and put declarations there (that allows main() to call functions from c_lib.cpp or use global variables if any)
When you run g++ you have to look into it's output, if operation succeed or not. In your case it failed so executable run was not created.
Usually you do not call compiler manually but write a makefile and let make utility to call g++.

Link dynamic shared library in Linux - Undefined reference to function

I know there are many questions related to shared libraries on Linux but maybe because I'm tired of having a hard day trying to create a simple dynamic library on Linux (on Windows it would have taken less than 10 minutes) I can't find what happens in this case.
So, I am trying to create a library to be linked at build-time and used at run-time (not a static library, not a library to be embedded into the executable, in other words). For now it contains a simple function. These are my files:
1.
// gugulibrary.cpp
// This is where my function is doing its job
#include "gugulibrary.h"
namespace GuGu {
void SayHello() {
puts("Hello!");
}
}
2.
// gugulibrary.h
// This is where I declare my shared functions
#include <stdio.h>
namespace Gugu {
void SayHello();
}
3.
// guguapp.cpp
// This is the executable using the library
#include "gugulibrary.h"
int main() {
GuGu::SayHello();
return 0;
}
This is how I try to build my project (and I think this is what is wrong):
gcc -Wall -s -O2 -fPIC -c gugulibrary.cpp -o gugulibrary.o
ld -shared -o bin/libGugu.so gugulibrary.o
gcc -Wall -s -O2 guguapp.cpp -o bin/GuGu -ldl
export LD_LIBRARY_PATH=bin
This is saved as a .sh file which I click and execute in a terminal. The error I get when trying to link the library is this:
/tmp/ccG05CQD.o: In function `main':
guguapp.cpp:(.text.startup+0x7): undefined reference to `SayHello'
collect2: ld returned 1 exit status
And this is where I am lost. I want the library to sit in the same folder as the executable for now and maybe I need some symbols/definitions file or something, which I don't know how to create.
Thanks for your help!
In your C++ file, GuGu::SayHello is declared as a C++ symbol. In your header, you are wrapping it in an extern "C" block. This is actually undefined, as you aren't allowed to use C++ syntax (namespace) in that context. But my guess is that what the compiler is doing is ignoring the namespace and generating a C symbol name of "SayHello". Obviously such a function was never defined by your library. Take out the extern "C" bits, because your API as defined cannot be used from C anyway.
You are inconsistent with your GuGu, there are also Gugu's running around, this needs to be made consistent, then it works (At least on my computer are some Gugu's now)

Compiling C++ using -pthreads for Openwrt Linux-Get segmentation fault

I´m pretty new to programming in C++ and I´m using pthreads. I´m cross compiling my code for OpenWRT but for some reason I get segmentation fault when I run the program on my board but it runs fine on my PC. I suspect that the error occurs in the linking stage of the compilation because I tried a small C program and that worked fine. Also if I change the name of the file to .cpp and compile it with g++ it also works.
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
void *run(void *dummyPtr) {
printf("I am a thread...\n");
return NULL;
}
int main(int argc, char **argv) {
printf("Main start...\n");
pthread_t connector;
pthread_create(&connector, NULL, run, NULL);
printf("Main end...\n");
return 0;
}
The output from the eclipse compiler:
**** Build of configuration Release for project ThreadTest ****
make all
Building file: ../src/ThreadTest.cpp
Invoking: GCC C++ Compiler
mipsel-linux-g++ -O3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/ThreadTest.d" -MT"src/ThreadTest.d" -o"src/ThreadTest.o" "../src/ThreadTest.cpp" -lpthread
mipsel-linux-g++: -lpthread: linker input file unused because linking not done
Finished building: ../src/ThreadTest.cpp
Building target: ThreadTest
Invoking: GCC C++ Linker
mipsel-linux-g++ -o"ThreadTest" ./src/ThreadTest.o -lpthread -static
Finished building target: ThreadTest
Edit: Removed the old code and put in a new simpler example. This code runs if I compile it as a C program but no if I compile it as a c++ program. I´m runnig the 2.6.26.3 kernel on the board.
This could easily be due to a low memory condition. You should try to enable some form of page file and free up any other memory.
Also, why -static? if your using a dynamic -lpthread, wouldn't linking the shared library be preferable?
Also, it could be due to your C++ lib being mis-matched, make sure your uclibc++ is the correct version, you may also want to install ldd if you have not already. Depends on your firmware.
It's not sufficient to simple link against pthread with -lpthread. You need gcc -pthread (as an option its own right) or gcc -D_REENTRANT -lpthread (define a symbol named _REENTRANT). I don't know if this necessary affects anything.
I don't know if you found an answer yet or if this was the problem, but there is a race condition in the code you showed. It is possible that main will return and your program will try to exit before your "run" thread has finished running. You can never assume that it will run in any particular order or with any particular timing. You should add a call to pthread_join(connector, NULL); before returning from main.
Before returning from the main and thus exiting the program, you should be doing a
pthread_join(connector, NULL);
which avoids exiting your application before the thread has terminated.
A correct declaration of main() is
int main(int argc, char **argv)
Edited to correct this answer:
This is because your compile -c line for your .c include -lpthread: linker input file unused
I found this answer about compiling c++ programs on openwrt:
http://manoftoday.wordpress.com/2007/10/11/writing-and-compiling-a-simple-program-for-openwrt/
I think you'll also want to read this to get gdb working:
http://forum.openwrt.org/viewtopic.php?pid=29712