On Wed, Mar 30, 2011 at 16:25, Ignaz Birnstingl <[email protected]> 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.
