Re: apr_off_t mismatch (Apache Users)

i am trying to ask this again:

i supply an apache 2.2 module to my customers. naturally, i need to build my module for each OS, cpu architecture & bit scheme. So, if my customer has Apache 2.2 on solaris sparc 32 bit - that's what i need to build.

however, from what i just discovered, there's another factor - LFS support. My module needs to be compiled with the LFS enabled or disabled - according to the specific apache of the specific customer. The problem is that i can't know what LFS support the apache was compiled with.

This really shouts "bug" to me, but i would really like to know - who's bug and how to fix it. for example, if the packages of apache 2.2.0 with APR 1.2.2 on sunfreeware.com have a bug that was later fixed - then i can tell my customer to upgrade to a later version.

???

On Mon, Nov 21, 2011 at 11:44 PM, Asaf Dalet <asaf.dalet@xxxxxxxxx> wrote:

this means that apache modules for 2.2.0 32 bits, on solaris 9 are not compatible across differemt ./configure options.
which actually means that if i want to check if my module will run on a given apache - i cannot do it (there's no way to know a priori the size of apr_off_t which apache was compiled with). am i right?

by any chance, does anyone know what are the ./configure options that control the size of apr_off_t, (if there are any)?

thanks
asaf

On Mon, Nov 21, 2011 at 7:23 PM, William A. Rowe Jr. <wrowe@xxxxxxxxxxxxx> wrote:

On 11/21/2011 9:48 AM, Asaf Dalet wrote:

Hi all,
some interesting news:
I downloaded apr-1.2.2-sol9-sparc-local from sunfreeware.com <http://sunfreeware.com> and

installed it.
the file apr/include/apr-1/apr.h contains this line:
typedef long apr_off_t;

does this mean apr 1.2.2 does not support LFS or is it some bug in this precompiled APR?
appreciate any comment

It means either 1) the builder deliberately forced this behavior
through options to ./configure, or 2) apr fails to detect that
LFS is available in the builder's environment. I suspect 1.