httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ignaz Birnstingl <ign...@gmail.com>
Subject Re: Handling APR_HAS_LARGE_FILES
Date Thu, 31 Mar 2011 12:48:34 GMT
2011/3/30 Ben Noordhuis <info@bnoordhuis.nl>:
> On Wed, Mar 30, 2011 at 16:25, Ignaz Birnstingl <ignazb@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

Mime
View raw message