httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Noordhuis <i...@bnoordhuis.nl>
Subject Re: Handling APR_HAS_LARGE_FILES
Date Wed, 30 Mar 2011 14:43:39 GMT
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.

Mime
View raw message