I'm trying to build a simple c application using gcc on aix
gcc -I. -c hello.c -o hello.o
gcc -o helloWorld hello.o -L helloHelper.so -ldl
I get the following errors
ld 0711-317 ERROR: Undefined symbol: .PrintHello
PrintHello is a method in the library helloHelper.
I can build the application in windows.
The option -L is for indicating directories where to search for libraries. To link a dynamic library directly, just put it in the linker command:
gcc -o helloWorld hello.o helloHelper.so -ldl
Other option would be to use -lhelloHelper but then the library should be called libhelloHelper.so.
Try this:
gcc -o helloworld hello.o -L. -lhelloHelper -ldl
Related
For some reasons, I want to build a static shared library: a self sustain
library that without any external dependent library.
My build environment is alpine linux.
(I believe that gcc is /usr/bin/aarch64-alpine-linux-musl-gcc)
I build my shared library as follows:
gcc -fpic -c jpg_to_bmp.c -o jpg_to_bmp.o
ld -fpic -shared -static -lc -lstdc++ jpg_to_bmp.o FreeImage/Dist/libfreeimage.a -o libmy_img_static.so
gcc -I ./ -L ./ main.c -o main.o
However
LD_LIBRARY_PATH=`pwd` ./main test.jpg test.bmp
dies with Segmentation fault
if I link the shared library without -static -lc -lstdc++
ld -fpic -shared -static -lc -lstdc++ jpg_to_bmp.o FreeImage/Dist/libfreeimage.a -o libmy_img_static.so
Everything works fine.
How do I build a static shared library(self-sustain) using musl ?
Did I miss any step or flag ?
gcc -fpic -c -o LuaLIB.o LuaLIB.c -lFOREIGNLIB -Wall
gcc -O -shared -lFOREIGNLIB -fpic -o LuaLIB.so LuaLIB.o -lFOREIGNLIB
This gives me:
lua5.3: error loading module 'LuaLIB' from file './LuaLIB.so':
libFOREIGNLIB.so.1: cannot open shared object file: No such file or directory.
How can I use/include another library while compiling a C-module for Lua?
I have a simple "Hello World!" c program, named hello.c on my desktop:
#include <stdio.h>
int main() {
printf("Hello world!\n");
return 0;
}
I run the following commands.
I pre-process it with : cpp hello.c > hello.i
I compile it with : gcc -S hello.i
I assemble it with : as -o hello.o hello.s
All good so far. But, i'm unable to link it. I've tried, among other commands, these:
ld -o hello.exe hello.o
ld -o hello.exe hello.o -lgcc
ld -o hello.exe hello.o -nostdlib -lgcc
Nothing works. The link errors i get in every single case are :
hello.o:hello.c:(.text+0x9): undefined reference to `__main'
hello.o:hello.c:(.text+0x15): undefined reference to `puts'
How can i link this assembled program hello.o in order to finally produce the executable program hello.exe? What am i missing? [Using Windows 8.1, Mingw version 0.6.2.] Thanks in advance.
Even if your answers to clarification questions are not particularly useful:
Try something like
ld hello.o -lmsvcrt -entry=_main -subsystem=console -o hello.exe
If you want to see the linker command line the standard gcc uses, invoke gcc like so:
gcc test.c -o test -Wl,-v
The last lines output is what you should be using...
If you want to compile something rather than experimenting with tools, don't link it using the linker directly. Use gcc, which will call the linker for you with the right options:
Compile step:
gcc -c hello.c
Link step:
gcc -o hello.exe hello.o
Or all in one:
gcc -o hello.exe hello.c
You can also use a simple Makefile, then run make:
all: hello.exe
I have a file test.pyx and a test.c generated by $ cython test.pyx. I want to create a shared object test.so with gcc so that I can import it into Python. Compilation for linux x86-64 with
gcc -Wall -fPIC -I /usr/include/python2.7 -shared -o test.so test.c
Terminates successfully.
I want to compile the same file to a .dll for windows with mingw32. However when I attempt to execute
i586-mingw32msvc-gcc -Wall -fPIC -I /usr/include/python2.7 -shared -o test.dll test.c
I get this error:
test.c:1: warning: -fPIC ignored for target (all code is position independent)
In file included from /usr/include/python2.7/Python.h:58,
from test.c:16:
/usr/include/python2.7/pyport.h:338:24: error: sys/select.h: No such file or directory
Am I doing something wrong?
You do this with it:
<your_compiler> <cython_generated_c_file> -o <your_outputfilename> -fPIE -lpython<python_version>
<cflags> <ldflags>
To get cflags:
python-config --cflags
For ldflags:
python-config --ldflags
I have problem link libgcc into a static linked .so
it only happens when linking 64bit module with -m64
Ubuntu 64bit 12.10 gcc 4.7
also failed on Ubuntu 64bit 12.04 gcc 4.6
32bit no problem
$gcc -fPIC -c -o hello.o hello.c -m32
$gcc -shared -m32 hello.o -o libhello.so -static-libgcc -Wl,-Bstatic -lc
$ ldd libhello.so
statically linked
64bit failed
$ make
gcc -fPIC -c -o hello.o hello.c
gcc -shared -m64 hello.o -o libhello.so -static-libgcc -Wl,-Bstatic -lc
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libc.a(iofclose.o): relocation R_X86_64_32 against `__gcc_personality_v0' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libc.a: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
make: *** [libhello.so] Error 1
hello.c
#include <stdio.h>
int f(){
FILE *out = fopen("/tmp/x.log", "wb");
fclose(out);
return 1;
}
Makefile
all: libhello.so
libhello.so: hello.o
gcc -shared -m64 hello.o -o libhello.so -static-libgcc -Wl,-Bstatic -lc
hello.o: hello.c
gcc -fPIC -c -o hello.o hello.c
clean:
rm -f hello.o libhello.so
The answer is basically "you can't do that." You're trying to link non-PIC code into a shared library, which is simply impossible on the x86_64 (amd64) architecture. You would need a static but PIC version of libgcc, and I suspect that would be only the start of your problems.
One of the reasons why libgcc is normally shared is that a given running executable has to have one and only one copy of some of the key data structures that libgcc maintains. Static linking makes sense for a final executable, since that one and only one copy will be the one statically linked into the executable, but the whole point of a dynamic object is to be loaded into another executable (which in turn will have its own copy of libgcc, either shared or static).