You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Kurt Miller <tr...@apache.org> on 2004/03/10 18:33:55 UTC

libjkjni and pcre build

libjkjni is built when --with-jni is not specified at configure time.
When this happens it is not usable, so I'll be changing the build to
only build libjkjni when --with-jni is specified.

I overlooked one thing with the recent pcre changes I committed. The
functions ap_pregcomp and ap_regexec will not be available to
libjkjni.so and are left unresolved. This will be a problem for jni
inprocess mode. I have to make a change to correct this.

Two options I see are:

1) Revert to old behavior and not use ap_pregcomp and ap_regexec at
all. This is the most straightforward. If you want pcre then you must
specify it with --with-pcre.

2) Use ap_pregcomp and ap_regexec only when --with-jni is not
specified. This would behave as follows:
    a) if --with-pcre and --with-jni are not specified then use
ap_pregcomp and ap_regexec.
    b) if --with-jni is specified but -with-pcre is not, then no pcre
support.
    c) if --with-jni and --with-pcre are specified then use regcomp
and regexec.

Option two is a bit more confusing but gives more flexibility. I'm
leaning towards reverting to the old behavior. Thoughts anyone?

-Kurt


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Re: libjkjni and pcre build

Posted by Kurt Miller <tr...@apache.org>.
Hi Guenter,

Your welcome. ;-) Your email made me realize there no difference
between using the ap_pregcomp and ap_regexec functions and the regcomp
and regexec functions on platforms that use configure. So I can
simplify this a bit more and always use regcomp and regexec
when --with-pcre is specified. Netware and Windows can still use the
ap_ functions since they don't have to deal with libjkjni.

-Kurt

From: "Guenter Knauf" <ef...@gmx.net>
> Hi Kurt,
> thanks for going this way - I have no choice on NetWare since the
PCRE functions are not exported at all.
>
> Guenter.
>
> > I misstated something before. The pcre change is not a problem for
> > inprocess mode, its a problem for jni out of process mode (i.e.
> > apr.NativeSo=libjkjni.so).
>
> > I think the most reasonable solution is to work as follows:
> >  --with-pcre and no --with-jni, use apache pcre functions
> >  --with-pcre and --with-jni, use external pcre functions
> >  --with-pcre is absent, no pcre support.
>
> > So if you want pcre you will need to specify it when configuring.
You
> > will get either apache pcre or external pcre depending if you
> > specify --with-jni or not.
>
> > I'll go forward with this unless someone has a better idea.
>
> > -Kurt
>
> > From: "Kurt Miller" <tr...@apache.org>
> >> libjkjni is built when --with-jni is not specified at configure
> > time.
> >> When this happens it is not usable, so I'll be changing the build
to
> >> only build libjkjni when --with-jni is specified.
> >>
> >> I overlooked one thing with the recent pcre changes I committed.
The
> >> functions ap_pregcomp and ap_regexec will not be available to
> >> libjkjni.so and are left unresolved. This will be a problem for
jni
> >> inprocess mode. I have to make a change to correct this.
> >>
> >> Two options I see are:
> >>
> >> 1) Revert to old behavior and not use ap_pregcomp and ap_regexec
at
> >> all. This is the most straightforward. If you want pcre then you
> > must
> >> specify it with --with-pcre.
> >>
> >> 2) Use ap_pregcomp and ap_regexec only when --with-jni is not
> >> specified. This would behave as follows:
> >>     a) if --with-pcre and --with-jni are not specified then use
> >> ap_pregcomp and ap_regexec.
> >>     b) if --with-jni is specified but -with-pcre is not, then no
> > pcre
> >> support.
> >>     c) if --with-jni and --with-pcre are specified then use
regcomp
> >> and regexec.
> >>
> >> Option two is a bit more confusing but gives more flexibility.
I'm
> >> leaning towards reverting to the old behavior. Thoughts anyone?
> >>
> >> -Kurt
> >>
> >>
>
>> -------------------------------------------------------------------
-
> > -
> >> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail:
tomcat-dev-help@jakarta.apache.org
> >>
>
>
>
> --------------------------------------------------------------------
-
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
tomcat-dev-help@jakarta.apache.org
>
>
>
> --------------------------------------------------------------------
-
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Re: libjkjni and pcre build

Posted by Guenter Knauf <ef...@gmx.net>.
Hi Kurt,
thanks for going this way - I have no choice on NetWare since the PCRE functions are not exported at all.

Guenter.

> I misstated something before. The pcre change is not a problem for
> inprocess mode, its a problem for jni out of process mode (i.e.
> apr.NativeSo=libjkjni.so).

> I think the most reasonable solution is to work as follows:
>  --with-pcre and no --with-jni, use apache pcre functions
>  --with-pcre and --with-jni, use external pcre functions
>  --with-pcre is absent, no pcre support.

> So if you want pcre you will need to specify it when configuring. You
> will get either apache pcre or external pcre depending if you
> specify --with-jni or not.

> I'll go forward with this unless someone has a better idea.

> -Kurt

> From: "Kurt Miller" <tr...@apache.org>
>> libjkjni is built when --with-jni is not specified at configure
> time.
>> When this happens it is not usable, so I'll be changing the build to
>> only build libjkjni when --with-jni is specified.
>>
>> I overlooked one thing with the recent pcre changes I committed. The
>> functions ap_pregcomp and ap_regexec will not be available to
>> libjkjni.so and are left unresolved. This will be a problem for jni
>> inprocess mode. I have to make a change to correct this.
>>
>> Two options I see are:
>>
>> 1) Revert to old behavior and not use ap_pregcomp and ap_regexec at
>> all. This is the most straightforward. If you want pcre then you
> must
>> specify it with --with-pcre.
>>
>> 2) Use ap_pregcomp and ap_regexec only when --with-jni is not
>> specified. This would behave as follows:
>>     a) if --with-pcre and --with-jni are not specified then use
>> ap_pregcomp and ap_regexec.
>>     b) if --with-jni is specified but -with-pcre is not, then no
> pcre
>> support.
>>     c) if --with-jni and --with-pcre are specified then use regcomp
>> and regexec.
>>
>> Option two is a bit more confusing but gives more flexibility. I'm
>> leaning towards reverting to the old behavior. Thoughts anyone?
>>
>> -Kurt
>>
>>
>> --------------------------------------------------------------------
> -
>> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>


> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Re: libjkjni and pcre build

Posted by Kurt Miller <tr...@apache.org>.
Embarrassingly replying to myself....

I misstated something before. The pcre change is not a problem for
inprocess mode, its a problem for jni out of process mode (i.e.
apr.NativeSo=libjkjni.so).

I think the most reasonable solution is to work as follows:
 --with-pcre and no --with-jni, use apache pcre functions
 --with-pcre and --with-jni, use external pcre functions
 --with-pcre is absent, no pcre support.

So if you want pcre you will need to specify it when configuring. You
will get either apache pcre or external pcre depending if you
specify --with-jni or not.

I'll go forward with this unless someone has a better idea.

-Kurt

From: "Kurt Miller" <tr...@apache.org>
> libjkjni is built when --with-jni is not specified at configure
time.
> When this happens it is not usable, so I'll be changing the build to
> only build libjkjni when --with-jni is specified.
>
> I overlooked one thing with the recent pcre changes I committed. The
> functions ap_pregcomp and ap_regexec will not be available to
> libjkjni.so and are left unresolved. This will be a problem for jni
> inprocess mode. I have to make a change to correct this.
>
> Two options I see are:
>
> 1) Revert to old behavior and not use ap_pregcomp and ap_regexec at
> all. This is the most straightforward. If you want pcre then you
must
> specify it with --with-pcre.
>
> 2) Use ap_pregcomp and ap_regexec only when --with-jni is not
> specified. This would behave as follows:
>     a) if --with-pcre and --with-jni are not specified then use
> ap_pregcomp and ap_regexec.
>     b) if --with-jni is specified but -with-pcre is not, then no
pcre
> support.
>     c) if --with-jni and --with-pcre are specified then use regcomp
> and regexec.
>
> Option two is a bit more confusing but gives more flexibility. I'm
> leaning towards reverting to the old behavior. Thoughts anyone?
>
> -Kurt
>
>
> --------------------------------------------------------------------
-
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org