File: UsingCURLinWin32.txt

package info (click to toggle)
xmlrpc-c 1.60.05-1
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid
  • size: 8,132 kB
  • sloc: ansic: 55,332; cpp: 13,541; sh: 3,321; makefile: 2,556; perl: 593; xml: 134
file content (86 lines) | stat: -rw-r--r-- 3,910 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
These are instructions for using the Curl HTTP client library for the XML-RPC
communication in an XML-RPC client, on Windows.  Normally, an XML-RPC client
running on Windows uses the HTTP client facilities built into Windows
(Wininet) instead.

These instructions worked at one time, but they do not appear to work with
current Xmlrpc-c code.  If you are able to update them to work with current
Xmlrpc-c code, please send the updates to the Xmlrpc-c maintainer to help the
next person.


Motivation:

Lets say you need to have a Xmlrpc-c client running as a service.  In this
situation you cannot use WinInet.  You can find details of the restriction on
the Curl website or various Microsoft KB articles.  Your alternative is to use
the Curl HTTP client library.  This document tells how to use use the Curl
library instead of the default Wininet as your client XML transport mechanism.

Overview:

The default projects in Xmlrpc-c create standalone executables that do not
require other DLLs.  Therefore, we need to create static link libraries for
libcurl.  Once we create the link libraries, we add them (plus the requisite
curl headers) into the Xmlrpc-c project.  Finally, we configure the build to
build the curl transport and build client libraries that use it.  Finally, we
build and test the project.


BUILD THE CURL LIBRARY
----------------------

Download the Curl source code.  Run the buildconf.bat to generate some
additional files.  This builds a 'dummy' hugehelp.c, but it can also be built
using the src\mkhelp.pl Perl script. You may have to build your own VCPROJ
file for CURL, if you want to use MSVC.

To build all the CURL library variations, use

  > nmake /nologo vc-all 

but note this will use the /MD[d] DLL runtime. Only by adding
RTCFGLIB=static to each of the makefile commands will /MT[d] be
used.

Essentially, for building the static Debug or Release CURL libraries, it is
all the sources in the curl\lib folder. Make sure you choose /MT and /MTd for
the runtime, and build both using the name 'libcurl.lib'.


BUILD XMLRPC-C, LINK WITH CURL
------------------------------

From the step above, you have Debug\libcurl.lib and Release\libcurl.lib.

After running xmlrpc-c\Windows\configurewin32.bat, start Visual Studio.

In the File View, in the 'xmlrpc' project, in the properties of
xmlrpc_curl_transport.c, change "Exclude file from build" from "yes" to "no",
for Debug and Release.  ==>BUT NOTE: in current Xmlrpc-c, this is broken -
there is no 'xmlrpc' project and no xmlrpc_curl_transport.c in any projects.
You need to add it.  What you need to do is apparently to get
xmlrpc_curl_transport.c, curltransaction.c, curlmulti.c into the
libxmlrpc_client library built by the libxmlrpc_client project.

In the 'Header Files' section, open the "transport_config.h" file,
and change MUST_BUILD_CURL_CLIENT to 1, and the XMLRPC_DEFAULT_TRANSPORT
to "curl", if you want.

As usual, for each of the "client" projects, and 'rpctest', in the properties,
Linker section, you can add the library libcurl.lib on the Input tab, and the
relative path to the library in the General tab to something like -
..\..\curl\Debug and ..\..\curl\Release (or wherever you placed the static
Curl libraries you built if you didn't follow recommendations above).

Or you can adjust the Windows/curlink.h, to directly point to your respective
Debug and Release static Curl libraries.

Now, Xmlrpc-c should build using the Curl transport.

Note, for the final linking, all libraries must be linked the same.  A mixture
of /MD and /MT will give big linkage problems.  Any one project built with the
alternate library will show many items defined more than once.  And of course,
you also cannot mix Debug with Release. That is /MDd with /MD, nor /MTd with
/MT.  Otherwise, there will be unresolved debug items.