I made shared library using gcc . I would like to link this library using g++ comiler with source code *.c.
Example
test_init.c
#include<stdio.h>
int test_init()
{
printf(" test init success\n");
return 0;
}
gcc -shared -o libtest.so test_init.c
test.c
#include<stdio.h>
extern int test_init();
main()
{
test_init();
}
g++ -I. -L. -ltest test.c
/tmp/ccuH5tIO.o: In function main':
test.c:(.text+0x7): undefined
reference totest_init()' collect2:
ld returned 1 exit status
Note: If i compile test.c with gcc it works, but i would like to use this approach due to other dependencies. Is it possible??
You call C routines from C++ by declaring them
extern "C" {
....
}
Look into a few header files on your system or Google around -- that's the only way to do it because of different function signature systems between the languages.
As Dirk said, change extern int test_init(); to extern "C" { int test_init(); }
Usually -llibrary should be after object files or c/c++ files in gcc command line
g++ -I. -L. test.c -ltest
The linker searches for the symbols mentioned in test.c after it's processed and when you put -llib before test.c, it's just unable to find them.
See man ld for more info.
Not sure how the things are when you use extern, perhaps something is different in this case.
Related
My main executable links with a static library whose symbols need to be available for dynamic libraries loaded through dlopen(). I understand that I need to use -Wl,--export-dynamic,--whole-archive flags to make it work. However there are many libraries specified on the link command, some maybe unused, and I'm having difficulties applying --whole-archive selectively to the needed library through cmake within the current build infrastructure. What I'm seeing is that if only -Wl,--export-dynamic is used and the executable calls a function in the static library of interest, then the whole library gets included to the same effect of specifying --whole-archive for it, which is exactly what I need. Can I rely on this behavior to implicitly impose --whole-archive on libs whose symbols are referenced by the executable?
What I'm seeing is that if only -Wl,--export-dynamic is used and the executable calls a function in the static library of interest, then the whole library gets included to the same effect of specifying --whole-archive for it, which is exactly what I need.
This isn't supposed to happen, and it is very likely that you are mis-interpreting what you see.
Example:
// foo.c
int foo() { return 42; }
// bar.c
int bar() { return 24; }
// main.c
int main() { return foo() - 42; }
gcc -w -c foo.c bar.c main.c
ar ruv libfoobar.a foo.o bar.o
gcc -Wl,--export-dynamic main.o -L. -lfoobar
nm a.out | egrep ' (foo|bar)'
000000000000113c T foo
As you can see, the whole libfoobar.a was not included in the executable. Contrast with:
gcc -Wl,--export-dynamic main.o -L. -Wl,--whole-archive -lfoobar -Wl,--no-whole-archive
nm a.out | egrep ' (foo|bar)'
0000000000001147 T bar
000000000000113c T foo
Update:
if I add a function foo1() to foo.c it is pulled in, but it also happens regardless if --export-dynamic is supplied.
That is expected: the linker doesn't "split" a single .o file -- you get all or nothing.
You can change this behavior by using -ffunction-sections (and -fdata-sections for a good measure) at compile time and -Wl,--gc-sections at link time.
The cost is increased .o size and longer link time. The benefit is smaller executable.
I have compiled a c++ code using g++ -std=c++11 -o main main.cpp -pthread and it compiled fine however if I compile the same code using gcc -std=c++11 -o main main.cpp -pthread it does not compile and throws error. The program uses threading which properly taken care of using -pthread option while compiling. For the reference I am attaching the code below. Any help is highly appreciated.
#include <iostream>
#include <thread>
class foo
{
public:
void bar(int loop_num)
{
for (int i = 0; i < loop_num; ++i) {
std::cout << "Thread executing\n";
++n;
std::this_thread::sleep_for(std::chrono::milliseconds(10));
}
}
int n = 0;
};
int main()
{
int n = 0;
foo f;
std::thread t1(&foo::bar, &f, 5);
t1.join();
}
If you’ve written C++ code with GCC, you’ll know that you need to use the program g++, both for compilation and linking. For multi-module programs, this means every .cpp file gets compiled with g++, and then the entire program must be linked separately using g++. If you try to link the program using gcc, it will almost work, but you’ll get a lot of “undefined reference” errors, like this:
test.cpp:(.text+0x11): undefined reference to `std::cout'
The need to use g++ to link the entire program causes trouble when you have a very complicated build process you don’t have full control of. For instance, I’m trying to link C++ code with Mercury, and I have to use the Mercury linker, which in turn calls gcc.
So just a quick tip: If you are forced to use gcc to link the program, just add the library “stdc++”, as you would any other library, and it will work. That is, add the option “-lstdc++” to your GCC linker command line. For example:
g++ -c hello.cpp
gcc -lstdc++ -o hello hello.o
I assume the error you get looks something like this:
/tmp/ccUKAq0K.o: In function `main':
main.cpp:(.text+0x59): undefined reference to `std::thread::join()'
/tmp/ccUKAq0K.o: In function `__static_initialization_and_destruction_0(int, int)':
main.cpp:(.text+0xb6): undefined reference to `std::ios_base::Init::Init()'
main.cpp:(.text+0xcb): undefined reference to `std::ios_base::Init::~Init()'
/tmp/ccUKAq0K.o: In function `std::thread::~thread()':
main.cpp:(.text._ZNSt6threadD2Ev[_ZNSt6threadD5Ev]+0x1d): undefined reference to `std::terminate()'
(And so on.)
C++ programs which use the standard library (so most of them) need to be linked using g++, not gcc. Only the g++ compiler driver links in most of the standard library. The gcc compiler driver compiles C++ programs, just like g++, but when the linker is invoked, the program is treated as a C program, which usually leads to linker errors.
Try adding the -lrt flag after the pthread one.
I am trying to compile a source given a .so file libfoo.so. The only thing in this library is a function that just returns a number (yeah, I know, advanced stuff). The header file equivalent (I was provided with both, but am only supposed to use the .so) is named foo.h and the function is named int foo().
My source file is main.c:
#include <stdio.h>
#include "foo.h"
int main()
{
int x = foo();
printf("%d", x);
return 0;
}
Now, when trying to compile I have the following commands:
gcc -Wall -fPIC -c main.c -o main.o
gcc -Wall -fPIC main.o -o main -lfoo -L.
The first command fails to create the object file, outputting the following error:
fatal error: foo.h: No such file or directory
I am using Ubuntu 16.04.
I have also tried exporting the current location to LD_LIBRARY_PATH as I've seen suggested on a few other answers.
export LD_LBIRARY_PATH=$LD_LIBRARY_PATH:machine/Desktop/lib_test
You need to have the interface definition from the .h file and that file must be in the current directory or a directory on the include search path.
Note that on some systems filenames and paths are case dependent.
I know there have been a lot of such topics, but I didn't found the answer, really. There's nothing that isn't working.
I am compiling file
gcc -std=c99 -Lmem xx.c
in the file there is
#include "include/memory.h"
#include <stdlib.h>
void main(){
meminit(100);
}
and in memory.h
#include "private.h"
#pragma once
MEMI * memdiag();
void meminit(int block_number);
void * memalloc(int desired_size);
void memfree(void * ptr);
the folder contains libmem.a, and headers, yet I'm getting error
/tmp/ccSJ4trm.o: In function `main':
xx.c:(.text+0xa): undefined reference to `meminit'
collect2: error: ld returned 1 exit status
I would be very grateful if You helped me, tomorrow I have to hand in the project.
You need to read some tutorials about using GCC.
You might want to try to compile and link with with
gcc -std=c99 -Wall -g xx.c -L. -lmem
(assuming your current directory [not folder] i.e. the . in -L. contains a libmem.a or libmem.so* library)
BTW, order of program arguments to gcc matters a big lot!
I am trying to run a simple program in cygwin that includes fork and wait.
I thought it would be very easy to compile but I am having problems.
#include <stdio.h>
#include <unistd.h>
void testFork(){}
int main(int argc,char* argv[]){
if (fork()==0) {testFork();return 0;}
while (wait() == -1);
return 0;
}
Compiled using:
gcc -Wall -Wextra -o test.o test
I get the following error:
C:\Users\Aaron\AppData\Local\Temp\ccgh3MfS.o:ostest.c:(.text+0x11): undefined reference to `fork'
C:\Users\Aaron\AppData\Local\Temp\ccgh3MfS.o:ostest.c:(.text+0x22): undefined reference to `wait'
collect2: ld returned 1 exit status
I'm sure I'm missing something trivial. Any ideas?
The linker can't find the standard C libraries.
Did you install Cygwin in the normal way? (Here's a simple guide: http://www.eecg.utoronto.ca/~aamodt/ece242/cygwin.html).
Have you been able to compile even simpler programs:
#include <stdio.h>
int main(int argc, char **argv) {
printf("Found C library.\n");
}
If that doesn't compile, you might just want to try removing and reinstalling Cygwin - something is broken.
C:\Users\Aaron\AppData\Local\Temp\ccgh3MfS.o is a Windows-style path. If you're using Cygwin, you only be seeing Cygwin-style paths, perhaps something like /cygdrive/C/Users/Aaron/AppData/Local/Temp/ccgh3MfS.o.
You said your command line was
gcc -Wall -Wextra -o test.o test
but it was probably
gcc -Wall -Wextra -o test.o test.c
Are you invoking gcc from the Cygwin command line? What does type gcc say?
It seems that MinGW gcc is being invoked because the cygwin gcc package is not installed.
You can verify that by calling the "cygcheck -c" in the cygwin commandline which will list all the installed packages, if you can't find the gcc in the list you need to install it