httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ignaz Birnstingl <>
Subject Re: Handling APR_HAS_LARGE_FILES
Date Mon, 04 Apr 2011 14:26:00 GMT
2011/3/31 Ignaz Birnstingl <>:
> 2011/3/30 Ben Noordhuis <>:
>> On Wed, Mar 30, 2011 at 16:25, Ignaz Birnstingl <> 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
>>> 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


View raw message