On Tue, 17 May 2011, Tom Bishop, Wenlin Institute wrote:

>> Why can't you just put libcurl in a separate directory and build that first
>> exactly the way you want it, then you build your app and link (statically)
>> with the libcurl you just built.
>
> Because I don't know how. I'll try to learn.

It should be really easy anyway!

> It's not clear why that would be unwise. It has worked well with other
> libraries.

It is unwise mostly in the aspect that libraries typically aren't designed to
be used like that so you're going against the stream when trying. The easier
route is to use them as they're meant to, and I claim there's really not much
of a downside.

>> It includes its own headers so the macros and defines are there. Did you
>> forget to run configure first?
>
> No, that was the first thing I did. After downloading libcurl 7.21.6 on Mac
> OS 10.6.7, I did this:
>
> ./configure
> make
> sudo make install

Ok, but that wasn't what I was suggesting you should do as an alternative to
putting all sources in your app's directory. Now you're already wondering off
in a tangent that certainly is not that simply build-libcurl-in-a-subdir.

Especially not when you already have a curl and libcurl in your computer and
you install a new version at a different path...

> I figured that the newer libcurl (7.21.6) must have been installed in a
> different location from the one that came with OS X (7.19.4)

> ./configure --prefix=/usr
> make
> sudo make install

That's really daring of you, I would be slightly more conservative! =)

> Now the version was reported as 7.21.6. However, my program (by #include
> <curl/curl.h>) still appeared to be using the old curl.h here:
>
> /Developer/SDKs/MacOSX10.4u.sdk/usr/include/curl

This is unfortunately not of our fault and is entirely the choice of your
OS/software development kit vendor.

> So I deleted that entire folder, and changed

I think that wasn't a good idea. The include/curl directory as installed
should be kept together and not mix with older versions.

> I'm guessing this might be a 32-bit versus 64-bit conflict.

I don't think so. I think it is because you mixed headers from two different
libcurl releases in a way that hasn't been designed or meant to work.

> I'll study the documentation further and try to make sure I'm building a
> 32-bit libcurl (since we're currently using Carbon on OS X). We also need
> versions for MS-Windows (cross-compiled from Mac OS as well as directly
> compiled on Windows), and Linux, and WinCE; and static libraries would be
> much preferable to shared.

So just build a static version in a subdirectory and link with that. As I
suggested...

> Am I really foolish to think it would be easier (for dummies like myself) if
> we could simply add libcurl.c (or curl/lib/*.c) to our project?

Compared to running ahead, installing stuff over existing files, changing
installed files to point to other random places and use mixed versions that
aren't supported then certainly _everything else_ is probably easier. I'll
give you that.

But please rewind back again and do the build similar to this instead:

  $ ./configure --disable-shared
  $ make

There, then you can point your app to use this directory to include from and
you can link directly with lib/.libs/libcurl.a

If you insist on 'make install' I suggest you use configure --prefix to a
custom place and use that directly from your application build process.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html