linking pthread library issue - c

Am facing a problem that may be slightly complicated to explain and understand as giving the entire picture would be too big and difficult.
Please excuse me for it.
Consider the following Makefile:
all: clients.so simulator backup
LD_PRELOAD=/home/Juggler/client/clients.so ./simulator
backup: backup.c libclient.a
gcc backup.c -o backup -L /home/Juggler/client -L. -lclient -ldl
simulator: simulator.c libclient.a
gcc -g simulator.c -o simulator -L /home/Juggler/client -L. -lclient -ldl -pthread
libclient.a: libclient.o client.o
ar rcs libclient.a libclient.o client.o
libclient.o:libclient.c
gcc -c libclient.c -o libclient.o -pthread
clients.so: client.o client_invoke.o
ld -shared -o clients.so client_invoke.o client.o -ldl
client_invoke.o: client_invoke.c
gcc -Wall -fPIC -DPIC -c -g client_invoke.c
client.o: client.c
gcc -Wall -fPIC -DPIC -c -g client.c -ldl -pthread
We call function written in client.c from libclient.c and these functions in client.c make call to pthread_key_create(), pthread_setspecific..etc.
Threads are created by simulator.c and theses threads access functions written in he other files.
On doing make...Errors like the following appear.
/home/Juggler/client/libclient.a(client.o):In function 'setup_connection':
/home/Juggler/client/client.c:35: undefined reference to 'pthread_setspecific'
pthread.h has been included in both client.c and libclient.c
Would be grateful for anypointers . I understand information is very less...
Thanks

On linux, pthread functions live in the libpthread library. So you have to link to that.
The proper way, when using pthreads, is to compile and link using the -pthread , which, among other things, will link in the pthread library. You have the -pthread flag for some of your executables, but not for others, and not for your clients.so library, so add the flag where required.
Also, remember, when you are creating a shared library, you should compile the source files with the -fPIC flag.
(And, seems you are calling ld directly to produce the client.so library, you really should use gcc to do the linking.)

Related

Creating several projects from one code in one makefile

I have one program and it uses static or shared library. Now I want to do something like
make static
or
make shared
to compile the project in two cases.
My Makefile looks like
shared: main.o libresult.so
gcc -o shared main.o -L. -lresult -Wl,-rpath,.
main.o: main.c
gcc -c main.c
libresult.so: func.o
gcc -shared -o libresult.so func.o
func.o: func.c
gcc -c -fPIC func.c
static: main.o libresult.a
gcc -o static main.o -L. -lresult
main.o: main.c
gcc -c main.c
libresult.a: func.o
ar cr libresult.a func.o
func.o: func.c
gcc -c func.c
clean:
rm -f *.o *.a *.so static shared
Off course, terminal gives some warnings. It works well, but I dont think that
is much beautiful :). How to make it better?
1) You have two copies of the main.o rule:
main.o: main.c
gcc -c main.c
Delete one of them.
2) You have two versions of the func.o rule:
func.o: func.c
gcc -c -fPIC func.c
func.o: func.c
gcc -c func.c
This is a more serious problem. The object you put in the shared library (libresult.so) must be compiled with -fPIC; the object you put in the static library (libresult.a) may be compiled with -fPIC, but there is no reason to do so and it may prevent the compiler form performing some optimisation. Make doesn't know your intentions, so it is better to make two versions of the object with different names:
func_so.o: func.c
gcc -c -fPIC func.c -o func_so.o
func_a.o: func.c
gcc -c func.c -o func_a.o
(Don't forget to modify the rules that rely on these objects.)
3) Use automatic variables to reduce redundancy and make your makefile cleaner. For example:
main.o: main.c
gcc -c $< -o $#
Further improvements are possible, once you are comfortable with these.

How to compile with a .o file that was compiled with other .o files (C99)

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.

How can I compile with shared library if I use Autotools

I have two C programs named drive.c and mylib.c.
drive.c is main module mylib.c is sub modulle that I want work as shared library .
I can compile them with following step and run.
gcc –fPIC –g –c –Wall mylib.c
gcc -shared -Wl,-soname,libmylib.so.1 -o /c/opt/lib/libmylib.so.1.0.1 mylib.o -lc
gcc -g -Wall -Wextra -pedantic -I./ -L/c/opt/lib -o drive.exe drive.c –l:libmylib.so.1
Now I want know is How can I compile them by autotools as same effect of above way ?
What and how do I have to edit configure.ac and Makefile.am for compile them?

Trouble with implementing a basic Makefile in c

Okay so I need to make a basic Makefile for a program I wrote. Here are the files:
list.c
hash.c
order_book.c
libdefault_hash.a //provided already so I do not need to create.
I need to create libraries for list.c and hash.c so that orderbook can use them when it compiles. So this is what I currently have in Makefile:
all: orderbook
orderbook: orderbook.c liblist.a libhash.a
gcc -std=c99 -o orderbook order_book.c list.c -L. -llist -lhash -libdefault_hash
liblist.a: list.c
gcc -std=c99 -c list.c
ar rcu liblist.a list.o
libhash.a: hash.c
gcc -std=c99 -c hash.c
ar rcu libhash.a hash.o
My understanding of how makefiles work is very small but here is my thought process,
all: orderbook will mean that orderbook: will run.
orderbook.c will then compile, then the code will compile the libraries.
Once the libraries are compiled it will run:
gcc -std=c99 -o orderbook order_book.c list.c -L. -llist -lhash -libdefault_hash
And the result should be a simple program file named orderbook, but the terminal prints out:
$ make
gcc -std=c99 -o orderbook order_book.c list.c hash.c -L. -llist -lhash -libdefault_hash
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible ./liblist.a when searching for -llist
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -llist
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -libdefault_hash
collect2: ld returned 1 exit status
make: *** [orderbook] Error 1
$
Any help/guidance is much appreciated.
Let's take this in small steps. First, here's a sequence of commands that looks like what you have in mind:
gcc -std=c99 -c list.c -o list.o
ar rcu liblist.a list.o
gcc -std=c99 -c hash.c -o hash.o
ar rcu libhash.a hash.o
gcc -std=c99 -o orderbook order_book.c -L. -llist -lhash -libdefault_hash
Try these commands without Make, and see which ones work (are you sure "rcu" shouldn't be "-rcu"?). Tell us the results either by commenting on this answer or editing your question. Once any of these commands works, we can start writing the makefile.

gdb and valgrind within a makefile

I have a very basic question. I did look around like over here http://www.cs.cmu.edu/~gilpin/tutorial/ but still doubtfull..
Consider the following makefile(had also given it in a previous question)
all: clients.so simulator backup
LD_PRELOAD=/home/Juggler/client/clients.so ./simulator
backup: backup.c libclient.a
gcc backup.c -o backup -L /home/Juggler/client -L. -lclient -ldl
simulator: simulator.c libclient.a
gcc -g simulator.c -o simulator -L /home/Juggler/client -L. -lclient -ldl -pthread
libclient.a: libclient.o client.o
ar rcs libclient.a libclient.o client.o
libclient.o:libclient.c
gcc -c libclient.c -o libclient.o -pthread
clients.so: client.o client_invoke.o
ld -shared -o clients.so client_invoke.o client.o -ldl
client_invoke.o: client_invoke.c
gcc -Wall -fPIC -DPIC -c -g client_invoke.c
client.o: client.c
gcc -Wall -fPIC -DPIC -c -g client.c -ldl -pthread
What do I do/change to debug using either gdb or valgrind. Actually I am getting a segmentation fault while doing make and would like to debug. But I have never used gdb or valgrind from within a makefile
Thanks
I made a small edit to your presentation. You originally wrote
client.o: client.c gcc -Wall -fPIC -DPIC -c -g client.c -ldl -pthread
Can you change it to the new form and see if make segfaults?
normally I would do something to the effect of:
$(DEBUGGER) ./simulator
then
$ make DEBUGGER=gdb --args
$ make DEBUGGER=valgrind
$ make # should still work without the debugger.
(technically the --args isn't needed for the command like it is, but if you add arguments to simulator in the future.)
but using LD_PRELOAD complicates this, because you probably don't want gdb loading libclient
gdb -ex 'set env LD_PRELOAD=/home/Juggler/client/clients.so' -ex 'run' ./simulator
Additionally its normal to link shared libraries through gcc via gcc -shared -o client.so
One inelegant way would be to spawn the process via the makefile, and then attach to it with GDB in another terminal. Using the trick from linux: suspend process at startup, you can launch the process and have it suspend immediately, and then connect with gdb.
have a script called launch.sh:
#!/bin/bash
echo "Pid is $$"
echo -n "Press Enter.."
read
exec $#
have a makefile recipe like this:
whatever_target: whatever_deps
./launch.sh PROGRAM [ARGS]
if for some reason you can't see the output (like if you are redirecting), you can still get the PID via ps -ef or something. then with gdb:
gdb PROGRAM_NAME PID

Resources