Thanks Kenneth & Christian,
The port of my program using microhttpd now works as it should. So, now
we have at least 2 ports to 32 bit Arm-Linux devices running microhttpd.
In hindsight, my problems were of my own making and no shortcoming of
microhttpd.
Thanks for your help and support.
BobF
On 15-02-27 01:25 PM, Kenneth Mastro wrote:
I doubt this will be of much help, but I have cross-compiled
microhttpd (0.9.39) on a 64-bit Linux machine to run on a 32-bit ARM
(running a buildroot/busybox-based Linux OS). I created a reasonably
sophisticated content-management system to serve up files, dynamically
generate content, and accept/store file uploads. I run and work with
it every day with no problems.
My point is - it's definitely possible to do.
I didn't compile it on the ARM itself, though. I do it in a 64-bit
Linux VM (Ubuntu 12.04 LTS) running on x86 (host OS is Windows 7).
When running 'configure' for cross-compiling, I export several
environment variables first, and specify a couple configure options.
E.g., something like this in a bash script in the root mhd directory:
---------------
CMAKE_C_COMPILER="<path to gcc cross compiler>"
export CMAKE_C_COMPILER
CC="<path to gcc cross compiler>"
export CC
CMAKE_CXX_COMPILER="<path to g++ cross compiler>"
export CMAKE_CXX_COMPILER
CXX="<path to g++ cross compiler>"
export CXX
./configure --prefix="<path where I want it installed so other code
can link against it>" --host=arm-linux
---------------
Then, just run that script instead of a raw 'configure', followed by a
'make' and 'make install'
Again - I doubt this will be of much help, and setting up the
cross-compiler toolchain will probably be a pain if you don't already
have it. The suggestion to try cross-compiling is about all I can
offer, though. That will bypass any (unlikely) problems introduced by
gcc on your ARM device. Microhttpd (and obviously the code that uses
it) will definitely run without issue on 32-bit ARM Linux.
Ken
On Fri, Feb 27, 2015 at 3:57 PM, Bob Furber <[email protected]
<mailto:[email protected]>> wrote:
Thanks Christian, but, while it appears to be a 32/64 bit issue, I
am not aware of having encountered AC_SYS_LARGEFILE.
microhttpd was installed on the 64 bit LinuxPC with sudo apt-get
install libmicrohttpd-dev , so I am unaware of any special
configurations during installation.
microhttpd was installed on the 32 bit Arm-Linux platform by
downloading the latest libmicrohttpd (libmicrohttpd-0.9.39.tar.gz
<http://ftp.gnu.org/gnu/libmicrohttpd/libmicrohttpd-0.9.39.tar.gz>) from
http://ftp.gnu.org/gnu/libmicrohttpd/, expanding it and blindly
following the configure, make, make install recipe. T hen copied
libmicrohttpd.a and microhttpd.h back to the LinuxPC where they
could be accessed by the cross-compiler. Again, I never came
across AC_SYS_LARGEFILE.
I grepped my LinuxPC for AC_SYS_LARGEFILE, without success.
Neither am I any wiser after googling AC_SYS_LARGEFILE.
I am at a loss as to how to address the possible off_t issue. The
only place I can find it is a parameter in microhttpd.h >
MHD_create_response_from_fd_at_offset() and a "Be careful! `off_t`
may have been compiled to be a 64-bit variable for MHD" warning.
Where would this have occurred? On the Arm-Linux device, following
the configure, make, make install recipe? If so, how could I
correct this?
I should mention that I am dealing with relatively small files ( <
1MB).
I wonder if anyone could suggest some questions, avenues or
experiments that may shed more light on how to un-stick microhttpd
transmit response queue or how to feed it appropriately?
On 15-02-27 12:25 AM, Christian Grothoff wrote:
Maybe you have an off_t 32-bit/64-bit confusion in your code
(did you
build your main C application with AC_SYS_LARGEFILE?). If
that is the
case, it might be that the "content-size" returned by your
server is
larger than what the callback is able/willing to provide.
Then, when the
server dies and closes the TCP connection, the HTTP client will
interpret that as the 'end of response' and ignore
content-size, which
would explain your observation.
I would suggest looking at the network traffic with wireshark,
and my
guess is that the HTTP server will have delivered the full
response and
the client is just waiting for more.
Happy hacking!
Christian
On 02/27/2015 05:10 AM, Bob Furber wrote:
I have a microhttpd based server program (mhdServer ) that
happily
serves files and more, when run on a 64-bit LinuxPC and is
accessed
through requests such as http://localhost:8080/filename.html.
However, porting this program to a remote 32-bit Arm-Linux
platform is
proving to be a challenge: It ALMOST WORKS:
* It replies with a “404 File not found” response to
requests for
non-existing files ..as it should
But, requests for existing files do not get the
anticipated reply:
* Client hangs waiting for requested web page files
* However, the web page is displayed by the client as soon
as the
mhdServer program is terminated!!
Examination of the mhdServer program with a remote
debugger indicates that:
* All client requests are being received
* The requested files are indeed located and fopen'ed
* MHD_create_response_from_callback() returns MHD_YES (1)
* MHD_queue_response() returns 1, indicating success ..yet
the client
keeps waiting patiently for its response ..which only
arrives upon
mhdServer's dying breath
I have been banging my head against this for days. Can
anyone suggest
any tests that might shed light on this strange behaviour?
