* Bill Hoffman <[email protected]> [Thu, 01 Apr 2010 12:01:35
-0400]:
> 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 curlbuild.h.in 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. */
#undef CURL_PULL_WS2TCPIP_H
#ifdef CURL_PULL_WS2TCPIP_H
# ifndef WIN32_LEAN_AND_MEAN
# define WIN32_LEAN_AND_MEAN
# endif
# include <windows.h>
# include <winsock2.h>
# include <ws2tcpip.h>
#endif
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
is,
> 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
could
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.
Look:
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
was
included, since they can't co-exist without problems */
#include <winsock2.h>
#include <ws2tcpip.h>
#endif
#else
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
where
> I can check the build).
>
> I admit that my way of setting CURL_PULL_SYS_TYPES_H is a bit
aggressive,
> 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
we
> 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
compilation
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
evening
(but my Internet conneciton is down for a while, so I will be able to
reply
only tomorrow).
> 1. If CMake is used to build curl in-source, curlbuild.h is not
renewed
> 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
that
the resulting curlbuild.h is not in any dependency list of any target,
unless you add it into the list of sources...
Hmmm...
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: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
