On Sun, Mar 31, 2013 at 1:13 PM, Florin Iucha <florin at iucha.net> wrote: > On Sat, Mar 30, 2013 at 09:53:04PM +0000, Brian Wood wrote: > > Up till now I've just been building a static library. > > Now I want to also create a shared library. > > I'm trying to figure out how to compile the files > > without the fpic option for the static library and > > then add fpic and recompile the files for the shared > > library. I'd like to do this from one makefile. > > Why is that a requirement? Can that one master makefile call two > other makefiles, one that produces the static library and the other > that produces the shared libary? Or it might be even the same slave > makefile, that is called with different arguments (to insert fpic on > the compiler command line, for instance). > > Clearly you need to generate object files in two separate directories, > or you need to name them differently. > Multiple Makefiles not strictly needed though that can work. I think multiple targets in the makefile would maybe be more handy. all: static shared static: Compile source files with static flags - object files as .o link with static flags (generate the .a or whatever) shared: Compile source files with shared flags - object files as .so? Link with shared flags - generate the .so I was going to do an experiment to see if you could compile with source files with -fPIC and then link statically. While addresses have to be position independent in a shared object and statically linked code does not need to be position independent, I'm not sure that implies addresses in a static lib CAN'T be position independent. It's been awhile since I've built something from source. I think I'm remembering for most libraries I built, asking for shared and static libs resulted in all object files being compiled with flags appropriate for shared libs and then two separate links at the end to create the .a and .so. I'd recommend downloading zlib or some other small library and configure it to compile both shared and static. Log the build and then see how they handled it. I'm guessing there's some useful stuff in their autoconf setup you could swipe? If you're not using autoconf you could look at their generated Makefiles for ideas... -Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20130331/ea8eb3dc/attachment.html>