views:

503

answers:

2

Hi, all,

I have a c++ project (g++/raw Makefile) designed for linux, I used to statically link everything which worked fine for ages. Now I want to build binaries both statically and dynamically linked. The following command is used in my Makefile to build the dynamic library (say libtest):

$(CXX) -shared -Wl,-soname,libtest.so.1 -o libtest.so.1.0.0 $(LIBTEST_OBJS)

The output is libtest.so.1.0.0 which has the so name libtest.so.1

I found at least a symbolic link libtest.so --> libtest.so.1.0.0 is required to link my client program that actually use the above generated libtest.so.1.0.0 library.

Here my question is if I want to build my software, what is the standard way of managing the above symbolic link? Clearly I don't want this extra stuff in my source directory, but it is required to build my client binary, shall I create it as a temp link for building the client then just remove it when done? or shall I create a directory to host the generate .so library and its links and leave everything there until I do "make install" to install them into other specified directories? Will be cool to now what is the standard way of doing this.

Or maybe the way how I generate libraries is incorrect? shall I just generate libtest.so (as actual library, not a link) to link my executable, then rename the library and create those links when doing ``make install''?

any input will be appreciated. :)

A: 

Certainly don't generate libtest.so as an actual link. Typically installing the shared library development files installs the .h files and creates a symbolic link libtest.so as part of some install script you have to write.

If you're not installing the development files, but only using the library in your build process of your binary, you just create the symbolik link from your makefile.

There's not that much of a standard here, some prefer to build artifacts to a separate build directory, some don't care if it's built in the source directory. I'd build to a separate directory though, and keep the source directory clean of any .o/.so/executable files.

You might find useful information here

nos
+1  A: 

My suggestion is to use libtool which handles situations like this.

kazanaki
+1 Using libtool will make it easier when you eventually decide to port it from Linux to something else - libtool handles all the platform-dependent issues of shared libraries.
Chris Lutz