How do I make shared libs on Linux?

Hi,
I'm building static and shared libs (.a & .sl) with these make options:

Code:

---

SHLIB=libname.sl
CC=cc
AR=ld
ARFLAGS=-Bdynamic -shared -warn-common -warn-constructors -warn-multiple-gp -warn-once -o
INC=../src
DEFS=-DPOSIX -DANSI
CFLAGS=-Wall -Wno-unused -fpic -shared -I. -I$(INC) $(DEFS)

$(SHLIB): $(OBJS)
        rm -f $(SHLIB)
        $(AR) $(ARFLAGS) $(SHLIB) $(OBJS)

debug.o: $(SRC)/debug.c $(HEADERS)
        $(CC) -c $(CFLAGS) $(SRC)/debug.c
...

---

But after I build my test program and run it, I get a segmentation fault. The program works fine with the static libs.

On Solaris, the LD_LIBRARY_PATH environment variable is used to specify where the shared libs are. As far as I can tell, Linux uses LIBRARY_PATH. Is that right, or do I need something else?

Do I need any other link options, or should I get rid of any that I have...?

This is how my test program is built:

Code:

---

CC=cc
CFLAGS=-Wall -DPOSIX -DANSI
SHLIBS=-L$$SHLIB_PATH

ivpslibs: scp.o rproc.o sstubs.o smain.o
        $(CC) -shared -o ivpslibs scp.o rproc.o sstubs.o smain.o $(SHLIBS)

sstubs.o: sstubs.c ivp.h
        $(CC) $(CFLAGS) -c $(INCS) sstubs.c
...

---

I don't know if it's a problem with how I build the shared lib or the test program or both?

Quote:

---

Originally Posted by cpjust

On Solaris, the LD_LIBRARY_PATH environment variable is used to specify where the shared libs are. As far as I can tell, Linux uses LIBRARY_PATH. Is that right, or do I need something else?

---

No, it is also LD_LIBRARY_PATH.

You don't need "-shared" in your CFLAGS. Also, why name the library with .sl instead of .so? The dynamic linker is probably confused by that.

You do not create shared libraries with "ar" - you create them with gcc or ld - I'm not quite sure about which switches you throw to make it create a .so file [which is the correct name, by the way].

If you want statically link with a .a file (which is the normal output name from a "ar" built archive) that would be fine too - but you need to specify -lname to make that happen in that case - you are only specifying -L<somepath> which tells the linker (as called by gcc) to look for libraries in this path, not actually to include any of the libraries that may be in there.

--
Mats

Quote:

---

Originally Posted by matsp

You do not create shared libraries with "ar" - you create them with gcc or ld - I'm not quite sure about which switches you throw to make it create a .so file [which is the correct name, by the way].

---

He IS using ld, he just sticks it in a variable called $(AR). I thought it was weird but didn't say anything.

Quote:

---

Originally Posted by brewbuck

He IS using ld, he just sticks it in a variable called $(AR). I thought it was weird but didn't say anything.

---

Ah, ok, so it's just the two things then: strange name (which may be OK, but it's hardly helping) and not linking in the actual library.

--
Mats

OK thanks, I'll try those suggestions.

The .sl looked weird to me too. I ported this makefile from HPUX...

Quote:

---

Originally Posted by cpjust

OK thanks, I'll try those suggestions.

The .sl looked weird to me too. I ported this makefile from HPUX...

---

I should have known.

Yes, on Linux use .so not .sl

Great! It's working now! :)

I didn't change anything in the first makefile for the shared libs (should I?). I just changed the test program makefile to use:

Code:

---

SHLIBS=$$SHLIB_PATH/libnwrpc.so $$SHLIB_PATH/libnwstcp.so

---

and removed the -shared flag.

One strange thing I just noticed though... I changed the LD_LIBRARY_PATH, LIBRARY_PATH & SHLIB_PATH environment variables to /lib and the program still runs. Did the paths get hard coded using the compile options I gave it?

Quote:

---

Originally Posted by cpjust

One strange thing I just noticed though... I changed the LD_LIBRARY_PATH, LIBRARY_PATH & SHLIB_PATH environment variables to /lib and the program still runs. Did the paths get hard coded using the compile options I gave it?

---

Yes, it is possible for a shared library path to be hard-coded into the shared binary so that it doesn't have to occur in LD_LIBRARY_PATH. Run "ldd" on the binary to see a dump of where it thinks the libraries are.

Quote:

---

Originally Posted by brewbuck

Yes, it is possible for a shared library path to be hard-coded into the shared binary so that it doesn't have to occur in LD_LIBRARY_PATH. Run "ldd" on the binary to see a dump of where it thinks the libraries are.

---

OK, that reports:

Code:

---

/home/test/slib/libname.so => /home/test/slib/libname.so (0xb75e2000)

---

I'm guessing that means it's hard coded.

How can I make it look for that .so file in the LD_LIBRARY_PATH variable?

What exactly is your link command?

EDIT: I see the problem, anyway. You can't just list the full path to the .so file -- as you found out, that causes the path to be hard-coded. Instead, use "-L/home/test/slib -lname"

Quote:

---

Originally Posted by brewbuck

What exactly is your link command?

EDIT: I see the problem, anyway. You can't just list the full path to the .so file -- as you found out, that causes the path to be hard-coded. Instead, use "-L/home/test/slib -lname"

---

Thanks, that did it.

BTW, do you know when it's necessary to use the -shared flag?
I'm still using it for building the .so library. Should I remove it there too?

Quote:

---

Originally Posted by cpjust

Thanks, that did it.

BTW, do you know when it's necessary to use the -shared flag?
I'm still using it for building the .so library. Should I remove it there too?

---

-shared is how .so libraries are created. So yes, it's necessary there. You don't need it elsewhere.

Also remember that shared library code must be compiled with -fpic or -fPIC.

Quote:

---

Originally Posted by brewbuck

-shared is how .so libraries are created. So yes, it's necessary there. You don't need it elsewhere.

Also remember that shared library code must be compiled with -fpic or -fPIC.

---

Great. and the -Bdynamic flag for ld? Is that useful, or does -shared already imply that?