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]> 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? >>> >>> > >
