libmicrohttpd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libmicrohttpd] build error without https support


From: Christian Grothoff
Subject: Re: [libmicrohttpd] build error without https support
Date: Tue, 26 Aug 2008 09:54:00 -0600
User-agent: KMail/1.9.9

On Tuesday 26 August 2008 09:23:42 am Sebastian Gerhardt wrote:
> Hello,
>
> MHD does not build as of REV 7631 if configured with --enable-HTTPS=no
>
>  gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../src/include
> -I../../src/daemon -I../../src/daemon/https/lgl
> -I../../src/daemon/https/x509 -I../../src/daemon/https/minitasn1
> -I../../src/daemon/https/openpgp -I../../src/daemon/https/opencdk
> -I../../src/daemon/https/tls -I../../src/daemon/https
> -I../../src/daemon/https/cfg -I -fno-strict-aliasing -g -O2 -MT
> connection.lo -MD -MP -MF .deps/connection.Tpo -c connection.c  -fPIC
> -DPIC -o .libs/connection.o
> connection.c: In function 'MHD_connection_handle_write':
> connection.c:1721: error: 'MHD_TLS_CONNECTION_INIT' undeclared (first
> use in this function)
> connection.c:1721: error: (Each undeclared identifier is reported only
> once
> connection.c:1721: error: for each function it appears in.)
> connection.c:1722: error: 'MHD_TLS_HELLO_REQUEST' undeclared (first use
> in this function)
> connection.c:1723: error: 'MHD_TLS_HANDSHAKE_FAILED' undeclared (first
> use in this function)
> connection.c:1724: error: 'MHD_TLS_HANDSHAKE_COMPLETE' undeclared (first
> use in this function)

Fixed in SVN 7632 -- thanks for pointing this out.

> I have a question, too. Since the latest beta, some type declarations in
> microhttpd.h (e.g. size_t) have been moved to other files (platform.h).

Actually, we never declared those types, we included system headers which 
declare those types.

> Could these two please be merged together in the next release? Or maybe
> the platform.h copied to the same include directory on "make install"
> and a #include "platform.h" in microhttpd.h.

I'm aware of the issue, but here is what I tried to do:

First of all,  "platform.h" needs to include "config.h" to determine what the 
platform and its capabilities are (and which system headers are needed).  
Without that, we may include headers that are not available on the given 
platform, which would be fatal.

config.h defines a ton of stuff that must not be exported 
(via #include <microhttpd.h>) to other applications, so including config.h or 
platform.h in microhttpd.h itself does not work either.  It would also be 
terrible style to include "config.h" in general since this would technically 
mean that the API of libmicrohttpd.h changes depending on the results of the 
configure-run, which we really want to avoid.  Since we need config.h for 
platform.h and must not make config.h available, we really cannot install 
platform.h (aside from the fact that the name might clash).

Here is how I intended devs would use the MHD header that lacks the system 
includes:

Simply #include the right headers that will define things like "size_t" 
and "fd_set" before #include'ing <microhttpd.h> (for the respective 
platform).  Now, "platform.h" lists most of the required system headers, so 
this file maybe a good starting point. However, you would still need to 
integrate it with your build process. So if you use autotools, you could 
generate config.h just like we do, otherwise you may choose to avoid the 
#ifdef'ing and just hardcode the right system headers for your platform.

An alternative to this would be the use of hacks like this one from curl.h:

#if defined(_AIX) || defined(__NOVELL_LIBC__) || defined(__NetBSD__) || \
    defined(__minix) || defined(__SYMBIAN32__)
#include <sys/select.h>
#endif

However, even with those one assumes that headers are 100% well-defined for a 
given system (and no detection is needed beyond automatic compiler 
#defines) -- not to mention that the list of checks could become rather 
extensive and hard to get right (there are compilers other than gcc which may 
have different #defines for the same platform ...).


I'm open for better suggestions.

Christian


reply via email to

[Prev in Thread] Current Thread [Next in Thread]