Re: Ship curl command line tool with Mac OS X software
Date: Tue, 28 Oct 2014 12:11:22 +0100
(Resending in text-only format)
Il giorno 27/ott/2014, alle ore 23:46, Nick Zitzmann <nick_at_chronosnet.com> ha scritto:
>> On Oct 27, 2014, at 10:51 AM, Marco Baldassarre <m.baldassarre_at_gmde.it> wrote:
>> Hi there,
>> I currently rely in my Mac application on curl command line tool shipped with Mac OS X and installed by default in /usr/bin/curl.
>> Altho this approach has worked so far, I have found some inconsistencies between 7.24 and 7.30 versions of cURL regarding the use of double-quotes marks in the syntax.
>> As such, I'd like to change my approach and ship a compiled version of cURL with my software, without relying anymore on the (changing between OS versions) cURL supplied by the Mac OS X platform.
>> How can I do that? Ideally, I'd like to have a 7.30 version that I can call from /Applications/MyApp/bin/curl , and that works on Mac OS X from 10.7 to 10.10 without being dependent on any other library.
> I'm curious as to why you need the curl tool specifically. If you need to do something in curl within an OS X app, then you ought to use libcurl in your app instead of fork()/exec()-ing a curl process.
Hi Nick, and first of all thanks for your answer.
It has some function calls to execute external processes, but unfortunately no ways to include libraries. So that's why I am forced to use the command-line tool.
> Anyway, if there's a good reason that you need the curl tool specifically, then you can do this (and this will work for any other tool you want to include in your app):
> 1. Install the latest command line tools on your computer, if you haven't done so already: xcode-select --install
> 2. Download the source code from <http://curl.haxx.se/>, un-pack it, and CD into its directory from the command line
> 3. Set the global environmental variable "MACOSX_DEPLOYMENT_TARGET" to "10.7" (or whatever your version requirement is; curl will go back as far as OS X 10.5)
> 4. Make a static build: ./configure --disable-shared --with-darwinssl --enable-threaded-resolver ; make -j `sysctl -n hw.logicalcpu_max`
> (Note: OpenSSL is deprecated on OS X, but if you specifically need OpenSSL support for some reason, then omit the --with-darwinssl flag. And if you don't want TLS at all, then use --without-ssl.)
> 5. The tool will be located at ./src/curl after it's done building, so copy it into your project
> 6. You can then get the tool's path inside your app's bundle by using the CFBundle or NSBundle APIs
This worked perfectly. Many thanks for the clear instructions.
1. I had to add --disable-ldap in the configure command, because the library was not found on my system and it gave a compile error.
Not so bad, not needing LDAP at all.
2. I also had to add --without-libidn --without-zlib to the configure command.
This has been necessary because when I tried to launch the compiled binary on another machine (without any development tool installed), I got this error:
dyld: Library not loaded: /opt/local/lib/libidn.11.dylib
Referenced from: /Users/robertomaggio/Downloads/curl.mac/10.10/curl
Reason: image not found
Trace/BPT trap: 5
I then ran the command:
otool -L curl
/opt/local/lib/libidn.11.dylib (compatibility version 18.0.0, current version 18.9.0)
/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)
/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 55471.14.18)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 855.17.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
See first two lines? The folder /opt/local/lib is not present on the target machine (a "vanilla" OS X 10.10).
I *think* I do not need neither IDN nor zlib support, but just in case, would it be possible to ship those libraries as well together with the compiled "curl" binary? I tried to supply a path to the libraries in a way that it would be relative, but I could not succeed. In a Windows environment, I am used to supply all relevant libraries (.dll) in the same folder as the compiled binary (.exe), and that would work. I am trying to understand if I can do the same thing on OS X.
3. I have now built the tool several times with MACOSX_DEPLOYMENT_TARGET set to 10.6, 10.7, 10.8, and so on. I am going to ship all of them and call the right one depending on the OS the app is running on.
Is this the correct approach?
4. What about compiling with MACOSX_DEPLOYMENT_TARGET=10.10 on a 10.9 machine? Will the resulting binary work on 10.10 or shall I compile it on a 10.10 machine ? (I suppose it is true for backward compatibility, but I am not sure how it would know how to compile for a newer target).
Again, thanks so much for your help
> Nick Zitzmann
> List admin: http://cool.haxx.se/list/listinfo/curl-users
> FAQ: http://curl.haxx.se/docs/faq.html
> Etiquette: http://curl.haxx.se/mail/etiquette.html
List admin: http://cool.haxx.se/list/listinfo/curl-users
Received on 2014-10-28