2011/3/31 Ignaz Birnstingl <ign...@gmail.com>: > 2011/3/30 Ben Noordhuis <i...@bnoordhuis.nl>: >> On Wed, Mar 30, 2011 at 16:25, Ignaz Birnstingl <ign...@gmail.com> wrote: >>> we are trying to develop a proprietary (i.e. closed-source, binary-shipped) >>> Apache module and have run into troubles with binary incompatibilities >>> because of APR_HAS_LARGE_FILES being either 0 or 1. I have only found >>> http://osdir.com/ml/apache.apr.devel/2003-05/msg00028.html but this does not >>> exactly describe our problem. >>> The problem is that depending on APR_HAS_LARGE_FILES the sizes and offsets >>> of structs (e.g. request_rec) change, breaking binary compatibility. Now we >>> could compile the module twice - once with large file support and once >>> without large file support but this leads to yet more binaries we would have >>> to ship (32/64bit, Apache2.0/2.2, LFS=0/LFS=1). Besides, I guess most >>> customers do not know/care if their httpd was compiled with LFS or without. >>> >>> So my question: How do you handle these kinds of problems? (Are there any >>> proprietary Apache modules out there? ;-)) Are there some best practices or >>> is there something I am missing? Is there a way to find out at run-time if >>> httpd was compiled with LFS or without? >> >> If you have to ship a binary blob, you are probably best off shipping >> a module for each supported platform and supply some glue source code >> that loads the appropriate module at runtime, akin to what the NVIDIA >> Linux driver does. >> >> But if you are going to support a multitude of platforms and >> architectures, you really should reconsider your 'binary only' policy. >> I assure you support is going to be a royal pain, not to mention the >> irate customers. This is the voice of experience speaking. >> > > Thank you for the hint - I guess we will have to develop something > like a mod_stable_abi which offers a stable binary interface > (get_uri_from_request(void *request_rec), ... *sigh*), loads our blob > at run-time and which can be compiled with apxs (or statically if > mod_so is missing). > > As for shipping the source: Compiling our module is not very easy (as > it is developed in C++ and incorporates different libraries, including > a static version of APR 1.3.9) and definitely not possible with apxs. > I don't think it would be any easier for our customers to compile it > themselves besides the obvious issue that not every web server > administrator has the necessary build environment installed and we do > not want to support all build environments (compilers, linkers) out > there. > > -- > Ignaz >
Just to clarify: I confused the Windows and Unix header files when choosing the title of this discussion. What I meant was that apr_off_t gets typedef'ed to either off64_t, off_t or long. This caused the binary incompatibility at our module (we built it with apr_off_t=off64_t while on another Linux box httpd was compiled with apr_off_t=long). -- Ignaz
