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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: libjkjni and pcre build
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: libjkjni and pcre build
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: libjkjni and pcre build
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: libjkjni and pcre build
This account does not exist - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
