Closed fischermario closed 8 years ago
Nice!
I imagined that mimegen becoming a native program rather than a Python script would be a problem for cross-compiling. Thanks for fixing this.
As for the mtune parameter, is there any way to detect if it's not going to work with a particular processor family, or is that more of a cross-compilation issue?
If the stuff you're building is open source, send me a link once Lwan is part of it so I can link to it from the readme file.
I'll test the patch as soon as I'm in front of a computer.
As for the mtune parameter, is there any way to detect if it's not going to work with a particular processor family, or is that more of a cross-compilation issue?
You are right. It is better to check whether the compiler supports this particular parameter or not.
The following patch assumes that you have already applied the former: mtune-detection.patch.txt
If the stuff you're building is open source, send me a link once Lwan is part of it so I can link to it from the readme file.
You are giving me too much credit ;-) My tool is just in its infancy. Right now I am playing around with Lwan, getting used to it, reading the example code. I already hit some walls. Lwan is a great piece of software, but it is in dire need of a proper documentation.
Nice, I'll use the new patch as well.
As for hitting walls: please don't hesitate to either open issues or send me emails. That'll help me to know what to focus whenever I start writing the documentation.
I wanted to use lwan to create a small footprint REST API for a PLC. Unfortunately I came across a few obstacles when trying to cross-compile lwan using GCC 4.8 for the target system (ARMv7/Cortex-A8 based):
[ 50%] Building C object common/hash.c.o common/hash.c: In function 'get_random_unsigned': common/hash.c:74:32: error: 'O_CLOEXEC' undeclared (first use in this function)
There is a simple fix for that (references: GitHub bugreport, blog post).I have attached a patch to deal with the issues described above: lwan-crosscompile.patch.txt