libtool or ar & ranlib

Moderator
Posts: 3,574
Joined: 2003.06
Post: #1
I finally figured out how to use *make* well enough to do some dirty deeds for me on the Mac (woohoo!), and now I'm trying to get things going on Linux and Windows. First stab is at Linux.

I was using libtool to create a static library on OS X because that's what Xcode was doing, which seems to work fine. Then I go over to Linux and it chokes on my libtool command saying "libtool: unrecognized option `-o'". Looking at them, it seems like libtool on OS X and libtool on Linux are two completely different programs.

My question is, should I just use ar + ranlib instead? Is there any particular reason to prefer libtool on OS X over ar + ranlib for making static libraries? It'd be easier to use the same programs on all platforms, so I'm thinking ar + ranlib might be easiest. Am I going in the right direction?
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
The best way to make static libraries is, of course, not to Rasp

They are nearly as large a cause of problems as dynamic libraries, IME...

But if you're going to do so, I see no reason to avoid ar+ranlib (and is ranlib even necessary any more?)

(I think libtool on Linux is called glibtool on Mac OS X; no idea what Mac OS X's libtool does...)
Quote this message in a reply
Moderator
Posts: 3,574
Joined: 2003.06
Post: #3
(Nov 18, 2010 06:29 PM)OneSadCookie Wrote:  The best way to make static libraries is, of course, not to Rasp

The two reasons I am using the static lib approach:
1) Managing boatloads of files between different projects in Xcode turned out to be a PITA, so I dropped back to static lib for my pile o' junk. This reason will be invalid if I continue to use make though, since the management can be controlled explicitly by me instead of dealing with Xcode's idiosyncrasies.
2) The ability to have my code undisclosed if I need to share functionality with a customer when sub-contracting. This isn't normally a problem, but I've bumped into a few issues with this, so having it lib-ready can make life easier at times.

Now that you mention it, with make and TextMate I can easily have it both ways. As long as my lib code is off in its own directory, where it should be, I can simply have both project folders right there, with a single makefile grabbing all sources from both automatically. Additionally, if I need the lib code built on its own, there's already a Makefile for that in the lib's directory. I'm still new to the make thing, so I hadn't thought about that until just now Rasp

(Nov 18, 2010 06:29 PM)OneSadCookie Wrote:  and is ranlib even necessary any more?

That's a good question. I was just assuming it was since I've seen it used for other libraries.

I have no real understanding of what libtool does on OS X, except that it links my library together for me. I was just copying Xcode's output for it, with the assumption that Apple preferred it for whatever reason. It's certainly simple to use: libtool -o myLib.a -static myObject.o

I can't say I have any real understanding of ar either, except that it accomplishes the same thing.

Thanks for the input. I'll go ahead and use ar for simplicity then, since there doesn't appear to be any reason not to.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #4
One thing to consider rather than a static library, if you really need the functionality, is ld -r. That takes a bunch of object files, links them to each other, and creates one large object file. That is then really easy to link, without many if any of the pitfalls of static or dynamic libraries, and unlike a static library, it actually reduces linking time of the client.
Quote this message in a reply
Moderator
Posts: 3,574
Joined: 2003.06
Post: #5
That's an interesting idea. I'll have to play around with it.
Followup: Yes, it appears that libtool on Linux is indeed glibtool on OS X. I get essentially the same output when doing "glibtool --help" on OS X as "libtool --help" on Linux.
Quote this message in a reply
Post Reply