cURL / Mailing Lists / curl-library / Single Mail


Re: Anybody successfully bundled libcurl "dylib" (on Mac OS X)?

From: Daniel Stenberg <>
Date: Thu, 13 Sep 2001 10:37:09 +0200 (MET DST)

On Wed, 12 Sep 2001, Dan Wood wrote:

> I'm at my wit's end figuring something out, so maybe there is somebody
> here who has been down a similar path. I don't know if this is a Mac
> OSX/Darwin-specific issue, or one that would apply to other UNIXes out
> there....
> I have built an application that uses libcurl. Things work just fine
> when it links to the libcurl that I've configured, make'd, and installed
> into /usr/local/lib.
> However, I want to package libcurl into my application so that others can
> use it without the command line. (Mac users are picky that way for some
> reason.)
> The trick, as I understand it, is to get a version of the libcurl.dylib
> file to think that it is installed not in /usr/local/lib, but in my
> application's bundle. There's a "magic" path that you indicate, which
> would be "@executable_path/../Frameworks/libcurl.dylib", which means to
> look in the Frameworks directory in the application package (which is
> also a directory.)

This is indeed a very platform specific issue. I'd suggest that you take this
question to a Mac OS X forum. This problem must be a generic problem with
libraries and nothing in particular that affects libcurl only or specificly.

Most unix-like operating systems feature package formats that let you specify
all the magic stuff and build an install package from the existing files in
your system. I've never heard anyone else having this kind of problems you

> Anyhow, I just don't understand the intracacies of the "ld" flags and the
> configuration and makefiles to figure this out. (I'm an applications
> developer, not a linker expert!) So far I think I've figured out to use
> /usr/bin/libtool to make a new copy of libcurl.dylib that is "installed"
> in that special path.

Why do that? Why not install libcurl in the standard path, if it isn't
already there of course? And why relink anything, if you distribute a binary
package, then the already linked binary libcurl will be fine to just copy.

(In fact, libcurl will even come *included* in (the upcoming?) Mac OS X

> Has anybody been down this road before?

We have binary packages for curl on more than 20 platforms. I've never heard
anyone having this problem before.

> Is there an alternative to getting this to work properly? (And, of
> course, still work within curl's licensing?)

curl's licensing is so liberal you can practically do most of everything
you'd ever want without having that preventing you.

> (I really hope I can figure this out ... if I can't get this to happen,
> I'm going to have to abandon libcurl and find some other approach!)

If you can't figure this out, I can't see how using a different library would
help you. It would simply give you the same problem with another name.

I hope you get the things straighened out and working the way you want!

    Daniel Stenberg -- curl groks URLs --
Received on 2001-09-13