If you use the autotools ( autoconf ) it will generate makefiles that link with libtool by default.  

As noted there are alternatives to make such as ant, rake. and more...  

I'd suggest trying autoconf first.  Good luck with whatever you choose.  

-Rob

Sent from my iPhone

On Apr 1, 2013, at 1:37 PM, Joel Longanecker <joel.longanecker at gmail.com> wrote:

> I can't stand Make. I started writing python scripts to build my C/C++.
> 
> Now I can make more complicated build scripts, including shell calls to dpkg for dependency management. (You can also do this in make, but it is absolutely horrible to try and do so.)
> 
> 
> On Mon, Apr 1, 2013 at 1:19 PM, Brian Wood <woodbrian77 at gmail.com> wrote:
>> 
>> Robert Nesius writes:
>> > 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.
>> 
>> Sorry, I should have added that I have it building both libraries 
>> using files that were compiled using fpic.  It seems to work fine, 
>> but I noticed that one of my executables is 1.5% bigger and 
>> another is 3.3% bigger when they are linked with the static library 
>> built from files that were compiled with fpic.  I've put a lot of work 
>> into making the executables lean and want to preserve that here.
>> (I'm not sure I need a shared library, but it seems to make some
>> sense in my "data center" where I have multiple instances of 
>> the back tier running.  The other two programs I mentioned are 
>> the middle and front tiers.  I expect to continue to build those
>> using  the static library.)
>> 
>> >
>> > 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...
>> 
>> I haven't been using autoconf.  I have a hand written makefile.   Someone 
>> suggested looking into libtool. 
>> 
>> 
>> -- 
>> Brian Wood
>> Ebenezer Enterprises - go Twins.
>> http://webEbenezer.net          (651) 251-9384
>> 
>> 
>> 
>> 
>> _______________________________________________
>> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota
>> tclug-list at mn-linux.org
>> http://mailman.mn-linux.org/mailman/listinfo/tclug-list
> 
> _______________________________________________
> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota
> tclug-list at mn-linux.org
> http://mailman.mn-linux.org/mailman/listinfo/tclug-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20130401/dea02736/attachment-0001.html>