ESP8266 Community Forum

- Mon Feb 02, 2015 4:08 am #8756 First up thanks Sprite_tm for the awesome work on this.

I seem to be having an annoying problem and no luck trying to compile the esp-httpd source. I am using the esp-open-sdk on OS X and havent had any trouble compiling my own code or the MQTT library. But when ever I try to compile esp-httpd i get the following errors.

Code: Select allCC user/auth.c
In file included from /esptools/esp-open-sdk/sdk/include/os_type.h:10:0,
                 from /esptools/esp-open-sdk/sdk/include/user_interface.h:9,
                 from user/auth.c:17:
/esptools/esp-open-sdk/sdk/include/ets_sys.h:14:1: error: unknown type name 'uint32_t'
 typedef uint32_t ETSSignal;
 ^
/esptools/esp-open-sdk/sdk/include/ets_sys.h:15:1: error: unknown type name 'uint32_t'
 typedef uint32_t ETSParam;
 ^
/esptools/esp-open-sdk/sdk/include/ets_sys.h:27:1: error: unknown type name 'uint32_t'
 typedef uint32_t ETSHandle;
 ^
/esptools/esp-open-sdk/sdk/include/ets_sys.h:32:5: error: unknown type name 'uint32_t'
     uint32_t              timer_expire;
     ^
/esptools/esp-open-sdk/sdk/include/ets_sys.h:33:5: error: unknown type name 'uint32_t'
     uint32_t              timer_period;
     ^

I assume I have some form of problem with the Makefile, but for the life of me I cant work it out. All the paths look correct and the Libs all look fine.

Any one got any ideas?

- Mon Feb 02, 2015 5:34 am #8758 Bymartonmiklos: Thanks for the patch I'll see if I can include it into the esphttpd mainline. I don't like the fact that there's no fallback for webbrowsers somehow not supporting gzipped content, but if it's optional, it should be just fine.

ByIgorTr: The SDK allows you to put os_printf messages to the 2nd uart. That way, the first should be free to do whatever you want. Re point 2: You mean AP mode, right? Yes, you can do that with a timer, but you might want to consider what you want if e.g. an access point drifts in and out of reach...

Bykenn: If I ever get to Toronto, I'll contact you

- Mon Feb 02, 2015 6:27 am #8761 Ok I think I narrowed it down a little more.

I should have mentioned I am using SDK 0.9.5 not sure if thats the cause. But I discovered that the c_types.h in the SDK has the typedef for uint32_t commented out and seems to be relying on including the default C stdint.h. However this doesnt work as a dummy stdint.h is included in the esp-httpd includes folder.

I noticed the SDK have a c_types.h.orig file which has the commenting removed. If I use this file I now get a little further. But get a new error.

Code: Select allCC user/httpd.c
user/httpd.c: In function 'httpdFindConnData':
user/httpd.c:97:2: error: implicit declaration of function 'os_printf_plus' [-Werror=implicit-function-declaration]
  os_printf("FindConnData: Huh? Couldn't find connection for %p\n", arg);

I am not sure if this is simply because the code base doesn't work against the 0.9.5 SDK or some environment problem on my end.

- Mon Feb 02, 2015 12:11 pm #8786

Bymartonmiklos: Thanks for the patch I'll see if I can include it into the esphttpd mainline. I don't like the fact that there's no fallback for webbrowsers somehow not supporting gzipped content, but if it's optional, it should be just fine.

The GZIP compression is very common nowadays, all the mainstream browsers supports.
If we can believe to 3rd parties the GZIP support is present from the following versions:
[*]IE support began with version 4
[*]Mozilla support since at least 1998
[*]FF launched with support in place
[*]Opera support began with version 5.12
[*]Safari had reports of buggy support only in early versions (2003)
[*]Chrome launched with support in place
[*]JAWS support began around 2005
[*]K-Meleon support since at least 2002, version 0.6
[*]Lynx support since version 2.6
[*]Camino support at least since version 0.6

I can add a static 'fallback' html message if the client's does not sends GZIP in the "Accept-Encoding" header when GZIP-ing is enabled.