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
