libmicrohttpd
[Top][All Lists]
Advanced

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

Re: [libmicrohttpd] Antwort: Re: build error without https support


From: Christian Grothoff
Subject: Re: [libmicrohttpd] Antwort: Re: build error without https support
Date: Wed, 27 Aug 2008 16:26:40 -0600
User-agent: KMail/1.9.9

On Wednesday 27 August 2008 02:49:37 am address@hidden wrote:
> Hello Christian,
>
> I agree on your constructions of "platform.h" and "config.h".
> Only one suggestion to that:
> I am actually integrating MHD in an embedded platform running the Realtime
> OS vxWorks.

Does it work? (should we put vxWorks into the list of supported platforms)?  
If you had to make any changes to the code, would you mind sharing them so 
that we can consider integrating them into our tree?

> Here the name of the include file "config.h" is already in use for
> configuring the OS. So I would suggest
> to rename your "config.h" to (e.g.) "MHD_config.h".

Sure, no problem (done).

> This would make integration much more easy on systems that do not use the
> configuration mechanism
> "make .configure" "make install" and the generation of config files like
> linux systems normally use.

I can see that config.h might conflict, and changing it to MHD_config.h is 
trivial.  Note that this is not an installed header in either case (but 
renaming our config.h allows you to include a config.h from the OS, if 
needed).

Christian

> Thomas Martin
>
> address@hidden schrieb am 26.08.2008 17:54:00:
> > 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 determinewhat
>
> 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
> > _______________________________________________
> > libmicrohttpd mailing list
> > address@hidden
> > http://crisp.cs.du.edu/cgi-bin/mailman/listinfo/libmicrohttpd




reply via email to

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