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
Related
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 am working on a C project for Linux-environment (compiled with gcc). I am using two libraries:
SDL image (source is stored at the directory SDL_img).
SDL TTF (source is stored at the directory SDL_ttf).
My CFLAGS variable:
CFLAGS = -std=c99 -pedantic-errors -Wall -g -lm `sdl-config --cflags` -ISDL_img -ISDL_ttf
As you can see, I am including those two library-directories.
My gcc command include the following:
`sdl-config --libs` -lSDLmain -lSDL -lSDL_img -lSDL_ttf
Finally, in my project I have the following includes:
#include "SDL_ttf.h"
#include "SDL_image.h"
For some reason, I get errors of the type:
undefined reference to 'IMG_Load'
Why?
EDIT:
all: Chess.o Commons.o Console.o Controls.o Coords.o File.o GameState.o GUI.o Keyboard.o List.o Minimax.o Move.o Piece.o SettingsState.o Slots.o Square.o Str.o
gcc $^ -lm -std=c99 -pedantic-errors -g -o Chess `sdl-config --libs` -lSDLmain -lSDL -lSDL_img -lSDL_ttf
Just cd to those src/SDL_xxx dirs and do make to build those libraries and then set the correct -L and -I. It failed on linking so the -I is "good" but your path to your libraries is incorect
basically linker is now searching its paths to find libSDL_img and libSDL_ttf then it also searches /usr/lib/x86_64-linux-gnu and it still can not find it, that is why you are getting undefined referecne.
To fix this: first build those SDL_xxx and then search where are those libraries and pass somethig like this along with other to gcc:
-Lsrc/SDL_img/lib -lSDL_img -Lsrc/SDL_ttf/lib -lSDL_ttf
consider c.c a code that includes a.h and b.h, and main.c a code that includes c.h
i tried to compile it like so
gcc --std=c99 -o a.o -c a.c
gcc --std=c99 -o b.o -c b.c
gcc --std=c99 -o c.o -c c.c a.o b.o
but when I run the last one, gcc yells at me
gcc --std=c99 -o c.o -c c.c a.o b.o
gcc: warning: a.o: linker input file unused because linking not done
gcc: warning: b.o: linker input file unused because linking not done
and then when I try to compile the main.c file using gcc -o main main.c c.o it says that there are a lot of undefined references, which is predictable once the c file was not correctly compiled.
I've seen some similar questions here at stackoverflow, but I couldn't get it to work neither way.
I'm on Arch Linux running gcc v4.9.2-3
First, it is -std=c99 with a single dash.
I guess you are on Linux.
Then, you always should pass -Wall -Wextra -g (especially since you are a newbie) to gcc : -Wall ask for nearly all warnings, -Wextra for even more warnings, -g ask for debug information.
At last, you want to produce an executable myprog (don't name executables as c.o, this is supposed to be an object file) with
gcc -std=c99 -Wall -Wextra -g -o myprog c.c a.o b.o
You need to remove any -c since you want the linking to happen.
If you really mean -but that is very unusual today, better make shared libraries!- to agglomerate several object files into one all.o (to be linked later with other objects) you might try the -r linker option
gcc -std=c99 -Wall -Wextra -g -r c.c a.o b.o -o all.o
But last time I tried it was in the previous century, so details could be wrong.
There are very few reasons to agglomerate objects using the -r linker option. Unless you really know what you are doing, you are very probably wrong (in trying -r).
Perhaps you want to make a software library. These days it is much better to make a shared library. A shared library (technically an ELF shared object) should contain position independent code. So, assuming you have three translation units t1.c, t2.c, t3.c you first compile them as PIC :
gcc -std=c99 -Wall -Wextra -g -fPIC t1.c -c -o t1.pic.o
gcc -std=c99 -Wall -Wextra -g -fPIC t2.c -c -o t2.pic.o
gcc -std=c99 -Wall -Wextra -g -fPIC t3.c -c -o t3.pic.o
then you link all these PIC object files into a shared library libmyt.so
gcc -std=c99 -Wall -Wextra -g -shared \
t1.pic.o t2.pic.o t3.pic.o \
-o libmyt.so
Later you'll use this shared library e.g. as
gcc -std=c99 -Wall -Wextra -g main.o -o myprog -Wl,-rpath . libmyt.so
or as
gcc -std=c99 -Wall -Wextra -g main.o -o myprog -Wl,-rpath . -L. -lmyt
You might consider static linking with ar to make a static library libmyt.a but I don't recommend that.
Of course, you'll debug your program using gdb ./myprog and you could try running it with ./myprog. To use valgrind, try valgrind ./myprog
If you have several translation units, better learn how to use GNU make. Read the Program Library HowTo and this and these hints.
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
I'm trying to compile a C project I've been working on on a remote server that runs OS X. The project depends, in part, on libcurl. I only have access to the machine through my administrator account remotely.
When I attempt to make the project I keep getting errors relating to libcurl functions and constants not being defined. I conclude that libcurl is not being properly included by the compiler.
I'm using fink to install opensource software for all the dependencies ( postgres, curl, a few others ) and all the dependencies appear to work except curl.
My compiler command looks like:
gcc -ggdb -ansi -Wall -D_GNU_SOURCE -L `/sw/bin/pg_config --libdir` `/sw/bin/curl-config --cflags` -I `/sw/bin/pg_config --includedir` -lpq -lcurl -lpthread -lm `/sw/bin/curl-config --libs` -c Client.c
If I make a test file like so:
/sw/bin/curl http://www.google.com/ --libcurl test.c
And then attempt to compile it with:
gcc test.c `/sw/bin/curl-config --cflags` `/sw/bin/curl-config --libs` -o test.o
It also fails. Can anyone help me shed some light on this problem?
One compilation line is:
gcc -ggdb -ansi -Wall -D_GNU_SOURCE -L `/sw/bin/pg_config --libdir` \
`/sw/bin/curl-config --cflags` -I `/sw/bin/pg_config --includedir` \
-lpq -lcurl -lpthread -lm `/sw/bin/curl-config --libs` -c Client.c
This will take Client.c and generate Client.o, an object file. It doesn't need the library information; there is no linking taking place because of the -c option.
The other compilation line is:
gcc test.c `/sw/bin/curl-config --cflags` `/sw/bin/curl-config --libs` -o test.o
It is aconventional to end the names of executables with '.o'; it leads to confusion. However, if test.c only references functions from the standard libraries and libcurl, it should 'work'.
On my Mac, there is a copy of curl-config in /usr/bin.
Try this test program:
$ cat curltest.c
#include <stdio.h>
#include <curl/curl.h>
int main(void)
{
if (curl_global_init(0) == CURLE_OK)
{
printf("CURL version %s\n", curl_version());
curl_global_cleanup();
}
else
fprintf(stderr, "Failed to initialize CURL\n");
return 0;
}
$ cc -o curltest $(curl-config --cflags) curltest.c $(curl-config --libs)
$ file curltest
curltest: Mach-O 64-bit executable x86_64
$ otool -L curltest
curltest:
/usr/lib/libcurl.4.dylib (compatibility version 6.0.0, current version 6.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
$ curltest
CURL version libcurl/7.19.7 OpenSSL/0.9.8r zlib/1.2.3
$
This is on MacOS X 10.6.8.