cURL / Mailing Lists / curl-library / Single Mail


Re: CMake build patch - updated version.

From: tetetest tetetest <>
Date: Fri, 02 Apr 2010 12:10:52 +0400

* Bill Hoffman <> [Thu, 01 Apr 2010 12:01:35

> > I met the issue when I tried to add CURL_PULL_WS32TCPIP_H into
> curlbuild.h.
> > The problem is that it includes <winsock2.h>.
> >
> OK, why did you add CURL_PULL_WS32TCPIP_H ?

I took as a known-good template. It has a section that
includes winsock2.h and ws32tcpip.h when CURL_PULL_WS32TCPIP_H
was defined:

/* Configure process defines this to 1 when it finds out that system */
/* header file ws2tcpip.h must be included by the external interface. */
# ifndef WIN32_LEAN_AND_MEAN
# define WIN32_LEAN_AND_MEAN
# endif
# include <windows.h>
# include <winsock2.h>
# include <ws2tcpip.h>

So I added this piece into curlbuild.h.cmake and it caused problems
with VS2008.

After consulting the other "known-good" example of curlbuild.h - the
distributed curlbuild.h.dist - I found that socklen_t is 'int' there,
and there are no attempts to include <winsock2.h>. So, in my
patch I did the same.

Perhaps I should have explained this more thoroughly in my post.

> > If you include the files the other way round, it works. The problem
> > you cannot guarantee the order of #includes.
> >
> > Anyway, there is no problem with socklen_t in my patch.
> >
> Not now, but if windows or some compiler ever changes socklen_t it
> break. Seems much safer to use the system define if there is one.

This is exactly what I thought when trying to add
CURL_PULL_WS2TCPIP_H into curlbuild.h. Alas,
it is not as straightforward as it sounds.

1. You cannot use 'socklen_t' unless you have included <winsock2.h>
    which defines it.
2. You cannot include <winsock2.h> after the application has
    included <winsock.h>. They do not live together well. By the
   way, curl has met this problem before; see curl/curl.h:

#if defined(WIN32) && !defined(_WIN32_WCE) && !defined(__GNUC__) && \
  !defined(__CYGWIN__) || defined(__MINGW32__)
#if !(defined(_WINSOCKAPI_) || defined(_WINSOCK_H))
/* The check above prevents the winsock2 inclusion if winsock.h already
   included, since they can't co-exist without problems */
#include <winsock2.h>
#include <ws2tcpip.h>

So, for now we cannot use socklen_t safely.

> > Yes, without including <sys/types.h> you cannot use socklen_t on
> > OpenSolaris.
> > On Linuxes or OpenBSD, you need not include it (at least on those
> > I can check the build).
> >
> > I admit that my way of setting CURL_PULL_SYS_TYPES_H is a bit
> > but it doesn't cause problems. I hope it fixes more than it breaks.
> >
> > Of course, adding a new test for it would be the best solution. But
> > can do it later.
> It would be helpful for me to see the problem before fixing it.

Hmmm... I am telling this from memory: on OpenSolaris, I got a
error in curlbuild.h for this line:

/* Data type definition of curl_socklen_t. */
typedef CURL_TYPEOF_CURL_SOCKLEN_T curl_socklen_t;

The error message said something like "socklen_t does not name a type".
If you need an exact message, I can reproduce the error today in the
(but my Internet conneciton is down for a while, so I will be able to
only tomorrow).

> > 1. If CMake is used to build curl in-source, curlbuild.h is not
> > because it
> > already comes with the distibution. This causes problems on OSes
> > that are not handled with the distributed curlbuild.h.
> CMake should overwrite the file because it will see there are changes
> right?

Not quite.
CMake command CONFIGURE_FILE() does not overwrite existing files.
This is not documented, but it is the way CMake works.

Besides, this command does not imply any dependency tracking. I mean
the resulting curlbuild.h is not in any dependency list of any target,
unless you add it into the list of sources...


Another improvement idea, don't you think?

> > 2. If CMake is used to build curl out-of-source, then curl/curl.h
> > includes the wrong
> > header (again, the one that comes with the distribution). Look:
> >
> > curl/curl.h:
> > #include "curlver.h" /* libcurl version defines */
> > #include "curlbuild.h" /* libcurl build definitions !!! Note the
> > quotes around the filename */
> > #include "curlrules.h" /* libcurl rules enforcement */
> I am not seeing this, I am pretty sure my build is using the correct
> file....

Are you building from git sources or from an unpacked tgz distribution?
In git, the "non-configure" curlbuild.h is named "curlbuild.h.dist", so
it is
not included by curl.h and there are no clashes.

To check that curl.h includes the right file, you can do the following:

1. Copy curlbuild.h.dist into curlbuild.h in source tree.
2. Add an #error "Boom!" directive to curlbuild.h.

If the wrong file gets included, you will see an error.

--tetetest tetetest.

List admin:
Received on 2010-04-02