Failure to build for ARM

[galvesribeiro]

Hello!

Great work with this library! I'm trying to build it for ARM and following your README.md steps, I tried this:

cmake -DZLIB_ROOT=/mnt/c/Dev/Linux/zlib -DCMAKE_BUILD_TYPE=Release ..
make

The cmake works properly, it find my custom Zlib cross compiled to my device. However, when we call make it say that it can't find it:

guto@GUTO-SURFACE3:/mnt/c/Dev/Linux/lwan/build$ make
Scanning dependencies of target mimegen
[  2%] Creating directories for 'mimegen'
[  4%] No download step for 'mimegen'
[  7%] No patch step for 'mimegen'
[  9%] No update step for 'mimegen'
[ 11%] Performing configure step for 'mimegen'
-- The C compiler identification is GNU 5.2.0
-- Check for working C compiler: /mnt/c/Dev/Linux/toolchain/bin/arm-arm1176jzs-linux-gnueabi-gcc
-- Check for working C compiler: /mnt/c/Dev/Linux/toolchain/bin/arm-arm1176jzs-linux-gnueabi-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- The CXX compiler identification is GNU 5.2.0
-- Check for working CXX compiler: /mnt/c/Dev/Linux/toolchain/bin/arm-arm1176jzs-linux-gnueabi-g++
-- Check for working CXX compiler: /mnt/c/Dev/Linux/toolchain/bin/arm-arm1176jzs-linux-gnueabi-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:108 (message):
  Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR)
Call Stack (most recent call first):
  /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:315 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-2.8/Modules/FindZLIB.cmake:85 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:6 (find_package)

-- Configuring incomplete, errors occurred!
See also "/mnt/c/Dev/Linux/lwan/build/common/tools/src/mimegen-build/CMakeFiles/CMakeOutput.log".
make[2]: *** [common/tools/src/mimegen-stamp/mimegen-configure] Error 1
make[1]: *** [common/CMakeFiles/mimegen.dir/all] Error 2
make: *** [all] Error 2

Can someone give a hand with it?

Thank you!

[lpereira]

The mimegen binary has to run on the host -- it's used to build a table that the library will need in runtime. It has its own, separate, CMakeLists.txt, which should make the task of crosscompiling easier.

[galvesribeiro]

@lpereira sorry my noobish on that but, how can I workaround that? I'm crosscompiling to ARM...

[lpereira]

A simple workaround is to build it for your host architecture, and copy the mime-types.h file to the build directory. This should be enough to not build the mimegen program.

Another way is to read up on how to perform cross-compilation with CMake; I have never done that with Lwan specifically, so I don't know exactly what'll work.

[galvesribeiro]

@lpereira will try the first option... Where should I put the mime-types.h ? Just leave it on lwan/build ? Put it after or before the I run the `cmake´ for the cross-compilation? I really liked your lib and appreciate any help. Thanks

[lpereira]

Yeah, leave it in lwan/build. Before you run cmake for the cross-compilation. Please keep me posted if that works.

Thanks, I appreciate that.

[galvesribeiro]

@lpereira

Supports rebimboca da parafuseta

Very brazilian statement :P

Anyway, I tried to put the file there but no lucky. Same error.

Also, Reading the current state of the project I think it will not be usable for us. Lwan is an executable... We are looking for a shared lib similar to what we found on pistache.io that can abstract web APIs for us. It will be used embedded on our device to behave as a IPC. (the only reason pistache dont work is because the device don't have support to eventfd).

In all cases thank you for the prompt support, I'll keep looking for another options.

[lpereira]

It builds both a shared library and a static library, so you can use it for your purposes. However, no file descriptors other than the client connections are supported by the I/O loop in each thread.

[galvesribeiro]

I understand... Just to give you a bit of context, the reason we are looking for an HTTP/WebAPI implementation is that we want to wrap our device native APIs in a HTTP WebAPI so the web App running on our device can access hardware features from JavaScript code...

All this could be be avoided if we had a proper port of WebKit or something working on the device so JS -> Native could be done by the proper channels.

Anyway, too much off-topic for this issue. Again, thank you for your help, I guess I need to find a contractor to help us with that.

Good lucky with this nice project!

[lpereira]

No problems at all. If you're looking for a contractor, I used to work here. They're pretty good and are in Brazil as well.

I'm closing this issue. Feel free to reopen or open another one.

[galvesribeiro]

@lpereira do you have a contact there? Or you may want to do freelaces yourself. :)

[lpereira]

Send me an email and I'll forward.

[galvesribeiro]

@lpereira I did sent an email to them before you reply. They didn't replied yet :(