You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by Stas Bekman <st...@stason.org> on 2004/05/06 01:39:05 UTC
[mp2 patch] getting APR to work w/o modperl
OK, I did some code reshuffling and with a few workarounds got APR::Table,
APR::UUID, APR::Pool and APR::PerlIO work outside httpd. I haven't tested
other modules yet. It's a big patch but it really does two things:
1) splits:
modperl_util.c => modperl_common_util.c
modperl_log.c => modperl_common_log.c
the common files contain the minimal things needed for APR to work w/o httpd.
(notice I haven't tested all the APR:: modules yet).
I'm not sure whether I've chosen the best name when using "common", may be I
should have called it apr. But if you look at the code, modperl_log.h includes
modperl_common_log.h (so it's sort of inheritance) where common is the base
[hc]. The only confusing part is that we don't want to have everything that
it's not including ap_ modperl_ symbolds in those common files, in order to
keep the external libs small. So your comments are welcome.
2) moved some of the modperl_util.c functions to a new file modperl_debug.c
(it's really unrelated to this patch, I'll commit it separately)
3) APR.so now links against modperl_common_log.o modperl_common_util.o
modperl_error.o. think of APR.so as mod_perl.so which bootstraps the rest.
I'll probably make all APR:: modules load APR.pm internally, so one doesn't
need to remember to load APR, to use APR::Table for example.
Here is the patch (you will need to do a complete rebuild). Oh and I didn't
run the source scan for those on win32. But you should be able to do it on
your own now. I'm mainly looking for the comments now. And commit the scan
when everybody is happy with this change.
Index: Apache-Test/lib/Apache/TestRun.pm
===================================================================
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.166
diff -u -u -r1.166 TestRun.pm
--- Apache-Test/lib/Apache/TestRun.pm 16 Apr 2004 20:29:23 -0000 1.166
+++ Apache-Test/lib/Apache/TestRun.pm 5 May 2004 23:28:56 -0000
@@ -643,7 +643,7 @@
}
close $sh;
- $original_command = "ulimit -c unlimited; $original_command";
+ $original_command = "ulimit -c unlimited; PERL_DL_NONLAZY=1
$original_command";
warning "setting ulimit to allow core files\n$original_command";
exec $original_command;
die "exec $original_command has failed"; # shouldn't be reached
Index: lib/ModPerl/Code.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/Code.pm,v
retrieving revision 1.121
diff -u -u -r1.121 Code.pm
--- lib/ModPerl/Code.pm 4 May 2004 06:10:37 -0000 1.121
+++ lib/ModPerl/Code.pm 5 May 2004 23:28:56 -0000
@@ -641,7 +641,8 @@
my @c_src_names = qw(interp tipool log config cmd options callback handler
gtop util io io_apache filter bucket mgv pcw global env
cgi perl perl_global perl_pp sys module svptr_table
- const constants apache_compat error);
+ const constants apache_compat error debug
+ common_util common_log);
my @h_src_names = qw(perl_unembed);
my @g_c_names = map { "modperl_$_" } qw(hooks directives flags xsinit);
my @c_names = ('mod_perl', (map "modperl_$_", @c_src_names));
@@ -652,7 +653,8 @@
my @g_h_names = map { "modperl_$_" } qw(hooks directives flags trace
largefiles);
my @h_names = (@c_names, map { "modperl_$_" } @h_src_names,
- qw(types time apache_includes perl_includes));
+ qw(types time apache_includes perl_includes apr_includes
+ common_includes));
sub h_files { [map { "$_.h" } @h_names, @g_h_names] }
sub clean_files {
Index: src/modules/perl/mod_perl.h
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.h,v
retrieving revision 1.65
diff -u -u -r1.65 mod_perl.h
--- src/modules/perl/mod_perl.h 4 May 2004 06:10:37 -0000 1.65
+++ src/modules/perl/mod_perl.h 5 May 2004 23:28:56 -0000
@@ -17,7 +17,7 @@
#define MOD_PERL_H
#include "modperl_apache_includes.h"
-#include "modperl_perl_includes.h"
+#include "modperl_common_includes.h"
#include "modperl_apache_compat.h"
#ifdef WIN32
@@ -91,6 +91,7 @@
#include "modperl_perl.h"
#include "modperl_svptr_table.h"
#include "modperl_module.h"
+#include "modperl_debug.h"
int modperl_init_vhost(server_rec *s, apr_pool_t *p,
server_rec *base_server);
Index: src/modules/perl/modperl_apache_includes.h
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_apache_includes.h,v
retrieving revision 1.28
diff -u -u -r1.28 modperl_apache_includes.h
--- src/modules/perl/modperl_apache_includes.h 4 Mar 2004 06:01:06 -0000 1.28
+++ src/modules/perl/modperl_apache_includes.h 5 May 2004 23:28:56 -0000
@@ -34,18 +34,6 @@
#include "http_vhost.h"
#include "ap_mpm.h"
-#include "apr_version.h"
-#include "apr_poll.h"
-#include "apr_lib.h"
-#include "apr_strings.h"
-#include "apr_uri.h"
-#include "apr_date.h"
-#include "apr_buckets.h"
-#include "apr_time.h"
-#include "apr_network_io.h"
-#include "apr_general.h"
-#include "apr_uuid.h"
-#include "apr_env.h"
#include "util_filter.h"
#include "util_script.h"
Index: src/modules/perl/modperl_cmd.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v
retrieving revision 1.58
diff -u -u -r1.58 modperl_cmd.c
--- src/modules/perl/modperl_cmd.c 4 Mar 2004 06:01:07 -0000 1.58
+++ src/modules/perl/modperl_cmd.c 5 May 2004 23:28:56 -0000
@@ -153,7 +153,7 @@
MP_CMD_SRV_DECLARE(trace)
{
MP_CMD_SRV_CHECK;
- modperl_trace_level_set(parms->server, arg);
+ modperl_trace_level_set_apache(parms->server, arg);
return NULL;
}
Index: src/modules/perl/modperl_config.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_config.c,v
retrieving revision 1.78
diff -u -u -r1.78 modperl_config.c
--- src/modules/perl/modperl_config.c 4 Mar 2004 06:01:07 -0000 1.78
+++ src/modules/perl/modperl_config.c 5 May 2004 23:28:57 -0000
@@ -268,7 +268,7 @@
* PerlTrace. This place is the earliest point in mod_perl
* configuration parsing, when we have the server object
*/
- modperl_trace_level_set(s, NULL);
+ modperl_trace_level_set_apache(s, NULL);
/* Must store the global server record as early as possible,
* because if mod_perl happens to be started from within a
Index: src/modules/perl/modperl_error.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_error.c,v
retrieving revision 1.1
diff -u -u -r1.1 modperl_error.c
--- src/modules/perl/modperl_error.c 4 May 2004 06:03:52 -0000 1.1
+++ src/modules/perl/modperl_error.c 5 May 2004 23:28:57 -0000
@@ -55,7 +55,10 @@
HV *data;
/* XXX: it'd be nice to arrange for it to load early */
- modperl_require_module(aTHX_ "APR::Error", TRUE);
+ Perl_require_pv(aTHX_ "APR/Error.pm");
+ if (SvTRUE(ERRSV)) {
+ Perl_croak(aTHX_ "%s", SvPV_nolen(ERRSV));
+ }
stash = gv_stashpvn("APR::Error", 10, FALSE);
data = newHV();
Index: src/modules/perl/modperl_gtop.h
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_gtop.h,v
retrieving revision 1.6
diff -u -u -r1.6 modperl_gtop.h
--- src/modules/perl/modperl_gtop.h 27 Apr 2004 00:27:38 -0000 1.6
+++ src/modules/perl/modperl_gtop.h 5 May 2004 23:28:57 -0000
@@ -21,7 +21,7 @@
#endif
#ifdef MP_USE_GTOP
-
+#define __GLIBTOP_ERROR_H__
#include <glibtop.h>
#include <glibtop/open.h>
#include <glibtop/close.h>
Index: src/modules/perl/modperl_log.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_log.c,v
retrieving revision 1.11
diff -u -u -r1.11 modperl_log.c
--- src/modules/perl/modperl_log.c 4 Mar 2004 06:01:07 -0000 1.11
+++ src/modules/perl/modperl_log.c 5 May 2004 23:28:57 -0000
@@ -13,81 +13,4 @@
* limitations under the License.
*/
-#include "modperl_apache_includes.h"
-#include "apr_lib.h"
-#include "modperl_trace.h"
#include "modperl_log.h"
-
-#undef getenv /* from XSUB.h */
-
-static apr_file_t *logfile = NULL;
-
-#ifdef WIN32
-static unsigned long debug_level = 0;
-#else
-unsigned long MP_debug_level = 0;
-#define debug_level MP_debug_level
-#endif
-
-unsigned long modperl_debug_level(void)
-{
- return debug_level;
-}
-
-void modperl_trace_logfile_set(apr_file_t *logfile_new)
-{
- logfile = logfile_new;
-}
-
-void modperl_trace(const char *func, const char *fmt, ...)
-{
- char vstr[8192];
- apr_size_t vstr_len = 0;
- va_list args;
-
- if (!logfile) {
- return;
- }
-
- if (func) {
- apr_file_printf(logfile, "%s: ", func);
- }
-
- va_start(args, fmt);
- vstr_len = apr_vsnprintf(vstr, sizeof(vstr), fmt, args);
- va_end(args);
-
- apr_file_write(logfile, vstr, &vstr_len);
- apr_file_printf(logfile, "\n");
-}
-
-void modperl_trace_level_set(server_rec *s, const char *level)
-{
- if (!level) {
- if (!(level = getenv("MOD_PERL_TRACE"))) {
- return;
- }
- }
- debug_level = 0x0;
-
- if (strcasecmp(level, "all") == 0) {
- debug_level = 0xffffffff;
- }
- else if (apr_isalpha(level[0])) {
- static char debopts[] = MP_TRACE_OPTS;
- char *d;
-
- for (; *level && (d = strchr(debopts, *level)); level++) {
- debug_level |= 1 << (d - debopts);
- }
- }
- else {
- debug_level = atoi(level);
- }
-
- debug_level |= 0x80000000;
-
- modperl_trace_logfile_set(s->error_log);
-
- MP_TRACE_any_do(MP_TRACE_dump_flags());
-}
Index: src/modules/perl/modperl_log.h
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_log.h,v
retrieving revision 1.13
diff -u -u -r1.13 modperl_log.h
--- src/modules/perl/modperl_log.h 4 Mar 2004 06:01:07 -0000 1.13
+++ src/modules/perl/modperl_log.h 5 May 2004 23:28:57 -0000
@@ -16,47 +16,11 @@
#ifndef MODPERL_LOG_H
#define MODPERL_LOG_H
-#define MP_STRINGIFY(n) MP_STRINGIFY_HELPER(n)
-#define MP_STRINGIFY_HELPER(n) #n
+#include "modperl_common_log.h"
+#include "modperl_apache_includes.h"
-#ifdef MP_TRACE
-# if defined(__GNUC__)
-# if (__GNUC__ > 2)
-# define MP_FUNC __func__
-# else
-# define MP_FUNC __FUNCTION__
-# endif
-# else
-# define MP_FUNC __FILE__ ":" MP_STRINGIFY(__LINE__)
-# endif
-#else
-# define MP_FUNC NULL
-#endif
-
-#include "modperl_trace.h"
-
-#ifdef _PTHREAD_H
-#define modperl_thread_self() pthread_self()
-#else
-#define modperl_thread_self() 0
-#endif
-
-#define MP_TIDF \
-(unsigned long)modperl_thread_self()
-
-void modperl_trace_logfile_set(apr_file_t *logfile_new);
-
-unsigned long modperl_debug_level(void);
-
-#ifdef WIN32
-#define MP_debug_level modperl_debug_level()
-#else
-extern unsigned long MP_debug_level;
-#endif
-
-void modperl_trace(const char *func, const char *fmt, ...);
-
-void modperl_trace_level_set(server_rec *s, const char *level);
+#define modperl_trace_level_set_apache(s, level) \
+ modperl_trace_level_set(s->error_log, level);
#define modperl_log_warn(s,msg) \
ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s, "%s", msg)
Index: src/modules/perl/modperl_util.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_util.c,v
retrieving revision 1.67
diff -u -u -r1.67 modperl_util.c
--- src/modules/perl/modperl_util.c 4 May 2004 06:16:46 -0000 1.67
+++ src/modules/perl/modperl_util.c 5 May 2004 23:28:57 -0000
@@ -290,26 +290,6 @@
return status;
}
-char *modperl_server_desc(server_rec *s, apr_pool_t *p)
-{
- return apr_psprintf(p, "%s:%u", s->server_hostname, s->port);
-}
-
-/* used in debug traces */
-MP_INLINE char *modperl_pid_tid(apr_pool_t *p)
-{
- return apr_psprintf(p, "%lu"
-#if APR_HAS_THREADS
- "/%lu"
-#endif /* APR_HAS_THREADS */
- , (unsigned long)getpid()
-#if APR_HAS_THREADS
- , (unsigned long)apr_os_thread_current()
-#endif /* APR_HAS_THREADS */
- );
-}
-
-
#define dl_librefs "DynaLoader::dl_librefs"
#define dl_modules "DynaLoader::dl_modules"
@@ -402,54 +382,6 @@
return uri;
}
-MP_INLINE SV *modperl_hash_tie(pTHX_
- const char *classname,
- SV *tsv, void *p)
-{
- SV *hv = (SV*)newHV();
- SV *rsv = sv_newmortal();
-
- sv_setref_pv(rsv, classname, p);
- sv_magic(hv, rsv, PERL_MAGIC_tied, Nullch, 0);
-
- return SvREFCNT_inc(sv_bless(sv_2mortal(newRV_noinc(hv)),
- gv_stashpv(classname, TRUE)));
-}
-
-MP_INLINE void *modperl_hash_tied_object(pTHX_
- const char *classname,
- SV *tsv)
-{
- if (sv_derived_from(tsv, classname)) {
- if (SVt_PVHV == SvTYPE(SvRV(tsv))) {
- SV *hv = SvRV(tsv);
- MAGIC *mg;
-
- if (SvMAGICAL(hv)) {
- if ((mg = mg_find(hv, PERL_MAGIC_tied))) {
- return (void *)MgObjIV(mg);
- }
- else {
- Perl_warn(aTHX_ "Not a tied hash: (magic=%c)", mg);
- }
- }
- else {
- Perl_warn(aTHX_ "SV is not tied");
- }
- }
- else {
- return (void *)SvObjIV(tsv);
- }
- }
- else {
- Perl_croak(aTHX_
- "argument is not a blessed reference "
- "(expecting an %s derived object)", classname);
- }
-
- return NULL;
-}
-
MP_INLINE void modperl_perl_av_push_elts_ref(pTHX_ AV *dst, AV *src)
{
I32 i, j, src_fill = AvFILLp(src), dst_fill = AvFILLp(dst);
@@ -890,51 +822,3 @@
return text;
}
-
-#ifdef MP_TRACE
-
-/* XXX: internal debug function, a candidate for modperl_debug.c */
-/* any non-false value for MOD_PERL_TRACE/PerlTrace enables this function */
-void modperl_apr_table_dump(pTHX_ apr_table_t *table, char *name)
-{
- int i;
- const apr_array_header_t *array;
- apr_table_entry_t *elts;
-
- array = apr_table_elts(table);
- elts = (apr_table_entry_t *)array->elts;
- modperl_trace(MP_FUNC, "Contents of table %s", name);
- for (i = 0; i < array->nelts; i++) {
- if (!elts[i].key || !elts[i].val) {
- continue;
- }
- modperl_trace(MP_FUNC, "%s => %s", elts[i].key, elts[i].val);
- }
-}
-
-/* XXX: internal debug function, a candidate for modperl_debug.c */
-void modperl_perl_modglobal_dump(pTHX)
-{
- HV *hv = PL_modglobal;
- AV *val;
- char *key;
- I32 klen;
- hv_iterinit(hv);
-
- MP_TRACE_g(MP_FUNC, "|-------- PL_modglobal --------");
-#ifdef USE_ITHREADS
- MP_TRACE_g(MP_FUNC, "| perl 0x%lx", (unsigned long)aTHX);
-#endif
- MP_TRACE_g(MP_FUNC, "| PL_modglobal 0x%lx",
- (unsigned long)PL_modglobal);
-
- while ((val = (AV*)hv_iternextsv(hv, &key, &klen))) {
- MP_TRACE_g(MP_FUNC, "| %s => 0x%lx", key, val);
- }
-
- MP_TRACE_g(MP_FUNC, "|-------- PL_modglobal --------\n");
-
-}
-
-
-#endif
Index: src/modules/perl/modperl_util.h
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_util.h,v
retrieving revision 1.56
diff -u -u -r1.56 modperl_util.h
--- src/modules/perl/modperl_util.h 4 May 2004 06:19:11 -0000 1.56
+++ src/modules/perl/modperl_util.h 5 May 2004 23:28:57 -0000
@@ -16,55 +16,7 @@
#ifndef MODPERL_UTIL_H
#define MODPERL_UTIL_H
-#ifdef MP_DEBUG
-#define MP_INLINE
-#else
-#define MP_INLINE APR_INLINE
-#endif
-
-#ifdef WIN32
-# define MP_FUNC_T(name) (_stdcall *name)
-/* XXX: not all functions get inlined
- * so its unclear what to and not to include in the .def files
- */
-# undef MP_INLINE
-# define MP_INLINE
-#else
-# define MP_FUNC_T(name) (*name)
-#endif
-
-#define MP_SSTRLEN(string) (sizeof(string)-1)
-
-#ifndef strcaseEQ
-# define strcaseEQ(s1,s2) (!strcasecmp(s1,s2))
-#endif
-#ifndef strncaseEQ
-# define strncaseEQ(s1,s2,l) (!strncasecmp(s1,s2,l))
-#endif
-
-#ifndef SvCLASS
-#define SvCLASS(o) HvNAME(SvSTASH(SvRV(o)))
-#endif
-
-#define SvObjIV(o) SvIV((SV*)SvRV(o))
-#define MgObjIV(m) SvIV((SV*)SvRV(m->mg_obj))
-
-#define MP_SvGROW(sv, len) \
- (void)SvUPGRADE(sv, SVt_PV); \
- SvGROW(sv, len+1)
-
-#define MP_SvCUR_set(sv, len) \
- SvCUR_set(sv, len); \
- *SvEND(sv) = '\0'; \
- SvPOK_only(sv)
-
-#define MP_magical_untie(sv, mg_flags) \
- mg_flags = SvMAGICAL((SV*)sv); \
- SvMAGICAL_off((SV*)sv)
-
-#define MP_magical_tie(sv, mg_flags) \
- SvFLAGS((SV*)sv) |= mg_flags
-
+#include "modperl_common_util.h"
/* XXX: this should be removed */
#define MP_FAILURE_CROAK(rc_run) do { \
@@ -109,10 +61,6 @@
int modperl_require_module(pTHX_ const char *pv, int logfailure);
int modperl_require_file(pTHX_ const char *pv, int logfailure);
-char *modperl_server_desc(server_rec *s, apr_pool_t *p);
-
-MP_INLINE char *modperl_pid_tid(apr_pool_t *p);
-
void modperl_xs_dl_handles_clear(pTHX);
void **modperl_xs_dl_handles_get(pTHX);
@@ -123,14 +71,6 @@
MP_INLINE modperl_uri_t *modperl_uri_new(apr_pool_t *p);
-/* tie %hash */
-MP_INLINE SV *modperl_hash_tie(pTHX_ const char *classname,
- SV *tsv, void *p);
-
-/* tied %hash */
-MP_INLINE void *modperl_hash_tied_object(pTHX_ const char *classname,
- SV *tsv);
-
MP_INLINE void modperl_perl_av_push_elts_ref(pTHX_ AV *dst, AV *src);
HE *modperl_perl_hv_fetch_he(pTHX_ HV *hv,
@@ -180,14 +120,5 @@
* @return string of original source code
*/
char *modperl_coderef2text(pTHX_ apr_pool_t *p, CV *cv);
-
-#ifdef MP_TRACE
-
-void modperl_apr_table_dump(pTHX_ apr_table_t *table, char *name);
-
-/* dump the contents of PL_modglobal */
-void modperl_perl_modglobal_dump(pTHX);
-
-#endif
#endif /* MODPERL_UTIL_H */
Index: t/apr-ext/perlio.t
===================================================================
RCS file: /home/cvs/modperl-2.0/t/apr-ext/perlio.t,v
retrieving revision 1.4
diff -u -u -r1.4 perlio.t
--- t/apr-ext/perlio.t 28 Aug 2003 01:59:28 -0000 1.4
+++ t/apr-ext/perlio.t 5 May 2004 23:28:57 -0000
@@ -13,11 +13,7 @@
use Apache::TestUtil;
use Apache::Build ();
-# XXX: skip for now until the dependency on mod_perl symbols is resolved
-# see STATUS for more info
-# to see the problems run:
-# env PERL_DL_NONLAZY=1 t/TEST -v apr-ext/perlio'
-plan tests => 1, under_construction;
+plan tests => 1;
use Fcntl ();
use File::Spec::Functions qw(catfile);
Index: xs/APR/Makefile.PL
===================================================================
RCS file: /home/cvs/modperl-2.0/xs/APR/Makefile.PL,v
retrieving revision 1.3
diff -u -u -r1.3 Makefile.PL
--- xs/APR/Makefile.PL 22 Mar 2003 07:21:37 -0000 1.3
+++ xs/APR/Makefile.PL 5 May 2004 23:28:57 -0000
@@ -2,6 +2,6 @@
use ModPerl::BuildMM ();
ModPerl::BuildMM::WriteMakefile(
- NAME => "APR",
+ NAME => "APR_build",
VERSION => '0.01'
);
Index: xs/APR/APR/APR.xs
===================================================================
RCS file: /home/cvs/modperl-2.0/xs/APR/APR/APR.xs,v
retrieving revision 1.10
diff -u -u -r1.10 APR.xs
--- xs/APR/APR/APR.xs 4 Mar 2004 06:01:09 -0000 1.10
+++ xs/APR/APR/APR.xs 5 May 2004 23:28:57 -0000
@@ -15,6 +15,12 @@
#include "mod_perl.h"
+/* XXX: provide the missing symbol for APR::Pool as a tmp workaround */
+#ifndef modperl_interp_unselect
+apr_status_t modperl_interp_unselect(void *data);
+apr_status_t modperl_interp_unselect(void *data) { return APR_SUCCESS; }
+#endif
+
#ifdef MP_HAVE_APR_LIBS
# define APR_initialize apr_initialize
# define APR_terminate apr_terminate
Index: xs/APR/APR/Makefile.PL
===================================================================
RCS file: /home/cvs/modperl-2.0/xs/APR/APR/Makefile.PL,v
retrieving revision 1.19
diff -u -u -r1.19 Makefile.PL
--- xs/APR/APR/Makefile.PL 3 Jan 2004 01:17:33 -0000 1.19
+++ xs/APR/APR/Makefile.PL 5 May 2004 23:28:57 -0000
@@ -54,4 +54,32 @@
$args{LIBS} = [$libs] if $libs;
+my $srcdir = '../../../src/modules/perl';
+
+# link the following into APR.so so other APR:: modules can be used
+# outside of httpd
+my @names = map { "modperl_$_" } (qw(error),
+ map { "common_$_" } qw(util log));
+my(@obj, @clean, %src);
+for (@names) {
+ push @obj, join '.', $_, 'o';
+ my $cfile = join '.', $_, 'c';
+ push @clean, $cfile;
+ $src{$cfile} = "$srcdir/$cfile";
+}
+
+$args{OBJECT} = "APR.o @obj";
+$args{clean} = { FILES => "@clean" };
+
ModPerl::BuildMM::WriteMakefile(%args);
+
+sub MY::postamble {
+ my $self = shift;
+ my $string = $self->ModPerl::BuildMM::MY::postamble;
+
+ $string .= join '', map {
+ "$_: $src{$_}\n\t\$(CP) $src{$_} .\n";
+ } keys %src;
+
+ return $string;
+}
Index: xs/Apache/Makefile.PL
===================================================================
RCS file: /home/cvs/modperl-2.0/xs/Apache/Makefile.PL,v
retrieving revision 1.3
diff -u -u -r1.3 Makefile.PL
--- xs/Apache/Makefile.PL 22 Mar 2003 07:21:37 -0000 1.3
+++ xs/Apache/Makefile.PL 5 May 2004 23:28:57 -0000
@@ -2,6 +2,6 @@
use ModPerl::BuildMM ();
ModPerl::BuildMM::WriteMakefile(
- NAME => "Apache",
+ NAME => "Apache_build",
VERSION => '0.01'
);
--- /dev/null 1969-12-31 16:00:00.000000000 -0800
+++ src/modules/perl/modperl_apr_includes.h 2004-05-05 12:28:38.000000000 -0700
@@ -0,0 +1,38 @@
+/* Copyright 2001-2004 The Apache Software Foundation
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#ifndef MODPERL_APR_INCLUDES_H
+#define MODPERL_APR_INCLUDES_H
+
+/* header files for APR */
+
+#ifndef CORE_PRIVATE
+#define CORE_PRIVATE
+#endif
+
+#include "apr_version.h"
+#include "apr_poll.h"
+#include "apr_lib.h"
+#include "apr_strings.h"
+#include "apr_uri.h"
+#include "apr_date.h"
+#include "apr_buckets.h"
+#include "apr_time.h"
+#include "apr_network_io.h"
+#include "apr_general.h"
+#include "apr_uuid.h"
+#include "apr_env.h"
+
+#endif /* MODPERL_APR_INCLUDES_H */
--- /dev/null 1969-12-31 16:00:00.000000000 -0800
+++ src/modules/perl/modperl_common_debug.c 2004-05-05 12:40:01.000000000 -0700
@@ -0,0 +1,19 @@
+/* Copyright 2000-2004 The Apache Software Foundation
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+/* This file must not contain any symbols from apache/mod_perl
+ * (apr and perl are OK) */
+#include "modperl_common_includes.h"
+
--- /dev/null 1969-12-31 16:00:00.000000000 -0800
+++ src/modules/perl/modperl_common_debug.h 2004-05-05 12:40:17.000000000 -0700
@@ -0,0 +1,20 @@
+/* Copyright 2000-2004 The Apache Software Foundation
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#ifndef MODPERL_COMMON_DEBUG_H
+#define MODPERL_COMMON_DEBUG_H
+
+
+#endif /* MODPERL_COMMON_DEBUG_H */
--- /dev/null 1969-12-31 16:00:00.000000000 -0800
+++ src/modules/perl/modperl_common_includes.h 2004-05-05 12:30:17.000000000 -0700
@@ -0,0 +1,24 @@
+/* Copyright 2001-2004 The Apache Software Foundation
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#ifndef MODPERL_COMMON_INCLUDES_H
+#define MODPERL_COMMON_INCLUDES_H
+
+/* header files which are independet of Apache/mod_perl */
+
+#include "modperl_apr_includes.h"
+#include "modperl_perl_includes.h"
+
+#endif /* MODPERL_COMMON_INCLUDES_H */
--- /dev/null 1969-12-31 16:00:00.000000000 -0800
+++ src/modules/perl/modperl_common_log.c 2004-05-05 15:34:18.936976547 -0700
@@ -0,0 +1,91 @@
+/* Copyright 2000-2004 The Apache Software Foundation
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include "modperl_common_includes.h"
+#include "modperl_common_log.h"
+
+#undef getenv /* from XSUB.h */
+
+static apr_file_t *logfile = NULL;
+
+#ifdef WIN32
+static unsigned long debug_level = 0;
+#else
+unsigned long MP_debug_level = 0;
+#define debug_level MP_debug_level
+#endif
+
+unsigned long modperl_debug_level(void)
+{
+ return debug_level;
+}
+
+void modperl_trace_logfile_set(apr_file_t *logfile_new)
+{
+ logfile = logfile_new;
+}
+
+void modperl_trace(const char *func, const char *fmt, ...)
+{
+ char vstr[8192];
+ apr_size_t vstr_len = 0;
+ va_list args;
+
+ if (!logfile) {
+ return;
+ }
+
+ if (func) {
+ apr_file_printf(logfile, "%s: ", func);
+ }
+
+ va_start(args, fmt);
+ vstr_len = apr_vsnprintf(vstr, sizeof(vstr), fmt, args);
+ va_end(args);
+
+ apr_file_write(logfile, vstr, &vstr_len);
+ apr_file_printf(logfile, "\n");
+}
+
+void modperl_trace_level_set(apr_file_t *logfile, const char *level)
+{
+ if (!level) {
+ if (!(level = getenv("MOD_PERL_TRACE"))) {
+ return;
+ }
+ }
+ debug_level = 0x0;
+
+ if (strcasecmp(level, "all") == 0) {
+ debug_level = 0xffffffff;
+ }
+ else if (apr_isalpha(level[0])) {
+ static char debopts[] = MP_TRACE_OPTS;
+ char *d;
+
+ for (; *level && (d = strchr(debopts, *level)); level++) {
+ debug_level |= 1 << (d - debopts);
+ }
+ }
+ else {
+ debug_level = atoi(level);
+ }
+
+ debug_level |= 0x80000000;
+
+ modperl_trace_logfile_set(logfile);
+
+ MP_TRACE_any_do(MP_TRACE_dump_flags());
+}
--- /dev/null 1969-12-31 16:00:00.000000000 -0800
+++ src/modules/perl/modperl_common_log.h 2004-05-05 15:20:40.327461074 -0700
@@ -0,0 +1,63 @@
+/* Copyright 2000-2004 The Apache Software Foundation
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#ifndef MODPERL_COMMON_LOG_H
+#define MODPERL_COMMON_LOG_H
+
+#define MP_STRINGIFY(n) MP_STRINGIFY_HELPER(n)
+#define MP_STRINGIFY_HELPER(n) #n
+
+#ifdef MP_TRACE
+# if defined(__GNUC__)
+# if (__GNUC__ > 2)
+# define MP_FUNC __func__
+# else
+# define MP_FUNC __FUNCTION__
+# endif
+# else
+# define MP_FUNC __FILE__ ":" MP_STRINGIFY(__LINE__)
+# endif
+#else
+# define MP_FUNC NULL
+#endif
+
+#include "modperl_apr_includes.h"
+#include "apr_lib.h"
+#include "modperl_trace.h"
+
+#ifdef _PTHREAD_H
+#define modperl_thread_self() pthread_self()
+#else
+#define modperl_thread_self() 0
+#endif
+
+#define MP_TIDF \
+(unsigned long)modperl_thread_self()
+
+void modperl_trace_logfile_set(apr_file_t *logfile_new);
+
+unsigned long modperl_debug_level(void);
+
+#ifdef WIN32
+#define MP_debug_level modperl_debug_level()
+#else
+extern unsigned long MP_debug_level;
+#endif
+
+void modperl_trace(const char *func, const char *fmt, ...);
+
+void modperl_trace_level_set(apr_file_t *logfile, const char *level);
+
+#endif /* MODPERL_COMMON_LOG_H */
--- /dev/null 1969-12-31 16:00:00.000000000 -0800
+++ src/modules/perl/modperl_common_util.c 2004-05-05 13:05:50.000000000 -0700
@@ -0,0 +1,72 @@
+/* Copyright 2000-2004 The Apache Software Foundation
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+/* This file must not contain any symbols from apache/mod_perl (apr
+ * and perl are OK). Also try to keep all the mod_perl specific
+ * functions (even if they don't contain symbols from apache/mod_perl
+ * on in modperl_util.c, unless we want them elsewhere. That is
+ * needed in order to keep the libraries used outside mod_perl
+ * small */
+
+#include "modperl_common_util.h"
+
+MP_INLINE SV *modperl_hash_tie(pTHX_
+ const char *classname,
+ SV *tsv, void *p)
+{
+ SV *hv = (SV*)newHV();
+ SV *rsv = sv_newmortal();
+
+ sv_setref_pv(rsv, classname, p);
+ sv_magic(hv, rsv, PERL_MAGIC_tied, Nullch, 0);
+
+ return SvREFCNT_inc(sv_bless(sv_2mortal(newRV_noinc(hv)),
+ gv_stashpv(classname, TRUE)));
+}
+
+MP_INLINE void *modperl_hash_tied_object(pTHX_
+ const char *classname,
+ SV *tsv)
+{
+ if (sv_derived_from(tsv, classname)) {
+ if (SVt_PVHV == SvTYPE(SvRV(tsv))) {
+ SV *hv = SvRV(tsv);
+ MAGIC *mg;
+
+ if (SvMAGICAL(hv)) {
+ if ((mg = mg_find(hv, PERL_MAGIC_tied))) {
+ return (void *)MgObjIV(mg);
+ }
+ else {
+ Perl_warn(aTHX_ "Not a tied hash: (magic=%c)", mg);
+ }
+ }
+ else {
+ Perl_warn(aTHX_ "SV is not tied");
+ }
+ }
+ else {
+ return (void *)SvObjIV(tsv);
+ }
+ }
+ else {
+ Perl_croak(aTHX_
+ "argument is not a blessed reference "
+ "(expecting an %s derived object)", classname);
+ }
+
+ return NULL;
+}
+
--- /dev/null 1969-12-31 16:00:00.000000000 -0800
+++ src/modules/perl/modperl_common_util.h 2004-05-05 13:17:06.000000000 -0700
@@ -0,0 +1,81 @@
+
+/* Copyright 2000-2004 The Apache Software Foundation
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include "modperl_common_includes.h"
+
+#ifndef MODPERL_COMMON_UTIL_H
+#define MODPERL_COMMON_UTIL_H
+
+#ifdef MP_DEBUG
+#define MP_INLINE
+#else
+#define MP_INLINE APR_INLINE
+#endif
+
+#ifdef WIN32
+# define MP_FUNC_T(name) (_stdcall *name)
+/* XXX: not all functions get inlined
+ * so its unclear what to and not to include in the .def files
+ */
+# undef MP_INLINE
+# define MP_INLINE
+#else
+# define MP_FUNC_T(name) (*name)
+#endif
+
+
+#define MP_SSTRLEN(string) (sizeof(string)-1)
+
+#ifndef strcaseEQ
+# define strcaseEQ(s1,s2) (!strcasecmp(s1,s2))
+#endif
+#ifndef strncaseEQ
+# define strncaseEQ(s1,s2,l) (!strncasecmp(s1,s2,l))
+#endif
+
+#ifndef SvCLASS
+#define SvCLASS(o) HvNAME(SvSTASH(SvRV(o)))
+#endif
+
+#define SvObjIV(o) SvIV((SV*)SvRV(o))
+#define MgObjIV(m) SvIV((SV*)SvRV(m->mg_obj))
+
+#define MP_SvGROW(sv, len) \
+ (void)SvUPGRADE(sv, SVt_PV); \
+ SvGROW(sv, len+1)
+
+#define MP_SvCUR_set(sv, len) \
+ SvCUR_set(sv, len); \
+ *SvEND(sv) = '\0'; \
+ SvPOK_only(sv)
+
+#define MP_magical_untie(sv, mg_flags) \
+ mg_flags = SvMAGICAL((SV*)sv); \
+ SvMAGICAL_off((SV*)sv)
+
+#define MP_magical_tie(sv, mg_flags) \
+ SvFLAGS((SV*)sv) |= mg_flags
+
+
+/* tie %hash */
+MP_INLINE SV *modperl_hash_tie(pTHX_ const char *classname,
+ SV *tsv, void *p);
+
+/* tied %hash */
+MP_INLINE void *modperl_hash_tied_object(pTHX_ const char *classname,
+ SV *tsv);
+#endif /* MODPERL_COMMON_UTIL_H */
+
--- /dev/null 1969-12-31 16:00:00.000000000 -0800
+++ src/modules/perl/modperl_debug.c 2004-05-05 13:19:43.000000000 -0700
@@ -0,0 +1,81 @@
+/* Copyright 2000-2004 The Apache Software Foundation
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include "mod_perl.h"
+
+char *modperl_server_desc(server_rec *s, apr_pool_t *p)
+{
+ return apr_psprintf(p, "%s:%u", s->server_hostname, s->port);
+}
+
+/* used in debug traces */
+MP_INLINE char *modperl_pid_tid(apr_pool_t *p)
+{
+ return apr_psprintf(p, "%lu"
+#if APR_HAS_THREADS
+ "/%lu"
+#endif /* APR_HAS_THREADS */
+ , (unsigned long)getpid()
+#if APR_HAS_THREADS
+ , (unsigned long)apr_os_thread_current()
+#endif /* APR_HAS_THREADS */
+ );
+}
+
+#ifdef MP_TRACE
+/* any non-false value for MOD_PERL_TRACE/PerlTrace enables this function */
+void modperl_apr_table_dump(pTHX_ apr_table_t *table, char *name)
+{
+ int i;
+ const apr_array_header_t *array;
+ apr_table_entry_t *elts;
+
+ array = apr_table_elts(table);
+ elts = (apr_table_entry_t *)array->elts;
+ modperl_trace(MP_FUNC, "Contents of table %s", name);
+ for (i = 0; i < array->nelts; i++) {
+ if (!elts[i].key || !elts[i].val) {
+ continue;
+ }
+ modperl_trace(MP_FUNC, "%s => %s", elts[i].key, elts[i].val);
+ }
+}
+#endif
+
+#ifdef MP_TRACE
+void modperl_perl_modglobal_dump(pTHX)
+{
+ HV *hv = PL_modglobal;
+ AV *val;
+ char *key;
+ I32 klen;
+ hv_iterinit(hv);
+
+ MP_TRACE_g(MP_FUNC, "|-------- PL_modglobal --------");
+#ifdef USE_ITHREADS
+ MP_TRACE_g(MP_FUNC, "| perl 0x%lx", (unsigned long)aTHX);
+#endif
+ MP_TRACE_g(MP_FUNC, "| PL_modglobal 0x%lx",
+ (unsigned long)PL_modglobal);
+
+ while ((val = (AV*)hv_iternextsv(hv, &key, &klen))) {
+ MP_TRACE_g(MP_FUNC, "| %s => 0x%lx", key, val);
+ }
+
+ MP_TRACE_g(MP_FUNC, "|-------- PL_modglobal --------\n");
+
+}
+#endif
+
--- /dev/null 1969-12-31 16:00:00.000000000 -0800
+++ src/modules/perl/modperl_debug.h 2004-05-05 13:05:13.000000000 -0700
@@ -0,0 +1,30 @@
+/* Copyright 2000-2004 The Apache Software Foundation
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#ifndef MODPERL_DEBUG_H
+#define MODPERL_DEBUG_H
+
+#include "mod_perl.h"
+
+char *modperl_server_desc(server_rec *s, apr_pool_t *p);
+MP_INLINE char *modperl_pid_tid(apr_pool_t *p);
+
+#ifdef MP_TRACE
+void modperl_apr_table_dump(pTHX_ apr_table_t *table, char *name);
+/* dump the contents of PL_modglobal */
+void modperl_perl_modglobal_dump(pTHX);
+#endif
+
+#endif /* MODPERL_DEBUG_H */
--- /dev/null 1969-12-31 16:00:00.000000000 -0800
+++ t/apr-ext/table.t 2004-05-05 16:25:40.287570443 -0700
@@ -0,0 +1,15 @@
+use Apache::Test;
+
+use blib;
+use Apache2;
+
+plan tests => 1;
+
+require APR;
+require APR::Table;
+require APR::Pool;
+
+my $p = APR::Pool->new;
+
+my $table = APR::Table::make($p, 2);
+ok ref $table eq 'APR::Table';
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
[...]
>>>- build APR first, so APR::* can link against it (the
>>>default action is to build APR::* first);
>>
>>Really? Is it specific to win32? On linux with the current
>>cvs, I can run 'make -j' which builds things in parallel
>>and I was getting APR/*.so getting build while
>>src/modules/perl/mod_perl.so was still not built. But I
>>don't see problem with arranging what you did.
>
>
> Without building APR first, APR::* dies at the link stage
> about references to unknown symbols. I couldn't see the
> nmake equivalent to 'make -j', but I'll look - this must
> be a common problem.
OK, it's probably like that at the current cvs, you just didn't see that since
you didn't try to build in parallel (which speeds things up when you are on a
SMP platform and not uni-processor).
>>>- add
>>> blib/arch/Apache2/auto/APR/
>>>to the PATH, so APR.dll can be found (perhaps APR.dll
>>>[APR.so] should be installed to $APACHE2/lib or
>>>$APACHE2/bin, as appropriate?)
>>
>>That's not good. The whole idea was not to create a
>>library which will need to be searched by the loader. The
>>ideas was to have a plain .so which will live under perl's
>>lib, and loading any APR/Foo.pm will first load APR.so,
>>and then APR/Foo.so. So yes, there is a need to change the
>>autogenerated APR/*.pm files, but you shouldn't need to
>>mess with PATH or anything that has to do with system-wide
>>loader.
>>
>>If we were to create a separate .so (read: win32/dll),
>>that would be mod_perl_common.so since all these things in
>>modperl_common.* have nothing to do with apr. But we want
>>to avoid to impose that added enormous complexity on our
>>users.
>
>
> This fiddling with the PATH was just to get the tests
> working (one could also use a LoadFile "...APR.dll"
> directive to accomplish the same thing). There's probably
> some internal way to do that within APR::*, along the
> lines of loading APR.so within APR/Foo.so, so that users
> don't have to be bothered.
APR/Foo.pm should arrange to load APR.pm, before it bootstraps APR/Foo.so.
Then you don't need to LoadFile.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
[...]
>>>- build APR first, so APR::* can link against it (the
>>>default action is to build APR::* first);
>>
>>Really? Is it specific to win32? On linux with the current
>>cvs, I can run 'make -j' which builds things in parallel
>>and I was getting APR/*.so getting build while
>>src/modules/perl/mod_perl.so was still not built. But I
>>don't see problem with arranging what you did.
>
>
> Without building APR first, APR::* dies at the link stage
> about references to unknown symbols. I couldn't see the
> nmake equivalent to 'make -j', but I'll look - this must
> be a common problem.
OK, it's probably like that at the current cvs, you just didn't see that since
you didn't try to build in parallel (which speeds things up when you are on a
SMP platform and not uni-processor).
>>>- add
>>> blib/arch/Apache2/auto/APR/
>>>to the PATH, so APR.dll can be found (perhaps APR.dll
>>>[APR.so] should be installed to $APACHE2/lib or
>>>$APACHE2/bin, as appropriate?)
>>
>>That's not good. The whole idea was not to create a
>>library which will need to be searched by the loader. The
>>ideas was to have a plain .so which will live under perl's
>>lib, and loading any APR/Foo.pm will first load APR.so,
>>and then APR/Foo.so. So yes, there is a need to change the
>>autogenerated APR/*.pm files, but you shouldn't need to
>>mess with PATH or anything that has to do with system-wide
>>loader.
>>
>>If we were to create a separate .so (read: win32/dll),
>>that would be mod_perl_common.so since all these things in
>>modperl_common.* have nothing to do with apr. But we want
>>to avoid to impose that added enormous complexity on our
>>users.
>
>
> This fiddling with the PATH was just to get the tests
> working (one could also use a LoadFile "...APR.dll"
> directive to accomplish the same thing). There's probably
> some internal way to do that within APR::*, along the
> lines of loading APR.so within APR/Foo.so, so that users
> don't have to be bothered.
APR/Foo.pm should arrange to load APR.pm, before it bootstraps APR/Foo.so.
Then you don't need to LoadFile.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 18 May 2004, Stas Bekman wrote:
> Randy Kobes wrote:
> > On Mon, 17 May 2004, Stas Bekman wrote:
> > [ ... ]
> >
> >>Randy Kobes wrote:
> >>
> >>>I'll try it for Windows and see how much is involved; if
> >>>this works as expected, it should just involve changing
> >>>how things are compiled, as well as the order (APR.so coming
> >>>first). But one of the joys of working with Windows is
> >>>that things are never as expected ;)
> >
> >
> > I've now tried it on Windows, and in particular the
> > (patched) apr-ext tests pass. This though was manual;
>
> Great!
>
> > I'll next try to get things built automatically. But
> > just for information, what was required was
> > - adjust xs/APR/APR/APR.def to include
> > modperl_interp_unselect
> > modperl_hash_tie
> > modperl_hash_tied_object
> > modperl_perl_gensym
> > modperl_error_strerror
> > in the list of exported symbols
>
> We ought to automate that. I think you've missed symbols,
> like tracing functions, since you didn't build with
> tracing enabled or because the APR/Foo.o's that my patch
> tests don't use tracing. We should probably look at the
> the apache/apr DECLARE macros. Alternatively it can be a
> common group of files modperl_common_*.c but it'll be hard
> to extract those symbol names. Another approach is to
> split the tables/ModPerl/Functions.pm (which I think
> that's how .def is generated now). May be the function
> names should have a different prefix than /modperl_/. In
> which case it'll be clear that they are common ones.
No doubt I did miss some symbols - this was just a quick
thing to see in particular if the apr-ext tests worked.
I'll look at the Functions.pm - you're right that this
is used to generate the .def file now.
> > - build APR first, so APR::* can link against it (the
> > default action is to build APR::* first);
>
> Really? Is it specific to win32? On linux with the current
> cvs, I can run 'make -j' which builds things in parallel
> and I was getting APR/*.so getting build while
> src/modules/perl/mod_perl.so was still not built. But I
> don't see problem with arranging what you did.
Without building APR first, APR::* dies at the link stage
about references to unknown symbols. I couldn't see the
nmake equivalent to 'make -j', but I'll look - this must
be a common problem.
> > - adjust the Makefiles in APR::* to link to
> > blib/arch/Apache2/auto/APR/APR.lib
> > before linking to src/modules/perl/mod_perl.lib
>
> Good.
>
> > - add
> > blib/arch/Apache2/auto/APR/
> > to the PATH, so APR.dll can be found (perhaps APR.dll
> > [APR.so] should be installed to $APACHE2/lib or
> > $APACHE2/bin, as appropriate?)
>
> That's not good. The whole idea was not to create a
> library which will need to be searched by the loader. The
> ideas was to have a plain .so which will live under perl's
> lib, and loading any APR/Foo.pm will first load APR.so,
> and then APR/Foo.so. So yes, there is a need to change the
> autogenerated APR/*.pm files, but you shouldn't need to
> mess with PATH or anything that has to do with system-wide
> loader.
>
> If we were to create a separate .so (read: win32/dll),
> that would be mod_perl_common.so since all these things in
> modperl_common.* have nothing to do with apr. But we want
> to avoid to impose that added enormous complexity on our
> users.
This fiddling with the PATH was just to get the tests
working (one could also use a LoadFile "...APR.dll"
directive to accomplish the same thing). There's probably
some internal way to do that within APR::*, along the
lines of loading APR.so within APR/Foo.so, so that users
don't have to be bothered.
> > In any case, no source code changes were needed - I think
> > all the above can be done within the Makefile generation.
>
> It's fine to change the source if it's needed :)
>
> Good work, Randy!
Thanks :)
--
best regards,
randy
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 18 May 2004, Stas Bekman wrote:
> Randy Kobes wrote:
> > On Mon, 17 May 2004, Stas Bekman wrote:
> > [ ... ]
> >
> >>Randy Kobes wrote:
> >>
> >>>I'll try it for Windows and see how much is involved; if
> >>>this works as expected, it should just involve changing
> >>>how things are compiled, as well as the order (APR.so coming
> >>>first). But one of the joys of working with Windows is
> >>>that things are never as expected ;)
> >
> >
> > I've now tried it on Windows, and in particular the
> > (patched) apr-ext tests pass. This though was manual;
>
> Great!
>
> > I'll next try to get things built automatically. But
> > just for information, what was required was
> > - adjust xs/APR/APR/APR.def to include
> > modperl_interp_unselect
> > modperl_hash_tie
> > modperl_hash_tied_object
> > modperl_perl_gensym
> > modperl_error_strerror
> > in the list of exported symbols
>
> We ought to automate that. I think you've missed symbols,
> like tracing functions, since you didn't build with
> tracing enabled or because the APR/Foo.o's that my patch
> tests don't use tracing. We should probably look at the
> the apache/apr DECLARE macros. Alternatively it can be a
> common group of files modperl_common_*.c but it'll be hard
> to extract those symbol names. Another approach is to
> split the tables/ModPerl/Functions.pm (which I think
> that's how .def is generated now). May be the function
> names should have a different prefix than /modperl_/. In
> which case it'll be clear that they are common ones.
No doubt I did miss some symbols - this was just a quick
thing to see in particular if the apr-ext tests worked.
I'll look at the Functions.pm - you're right that this
is used to generate the .def file now.
> > - build APR first, so APR::* can link against it (the
> > default action is to build APR::* first);
>
> Really? Is it specific to win32? On linux with the current
> cvs, I can run 'make -j' which builds things in parallel
> and I was getting APR/*.so getting build while
> src/modules/perl/mod_perl.so was still not built. But I
> don't see problem with arranging what you did.
Without building APR first, APR::* dies at the link stage
about references to unknown symbols. I couldn't see the
nmake equivalent to 'make -j', but I'll look - this must
be a common problem.
> > - adjust the Makefiles in APR::* to link to
> > blib/arch/Apache2/auto/APR/APR.lib
> > before linking to src/modules/perl/mod_perl.lib
>
> Good.
>
> > - add
> > blib/arch/Apache2/auto/APR/
> > to the PATH, so APR.dll can be found (perhaps APR.dll
> > [APR.so] should be installed to $APACHE2/lib or
> > $APACHE2/bin, as appropriate?)
>
> That's not good. The whole idea was not to create a
> library which will need to be searched by the loader. The
> ideas was to have a plain .so which will live under perl's
> lib, and loading any APR/Foo.pm will first load APR.so,
> and then APR/Foo.so. So yes, there is a need to change the
> autogenerated APR/*.pm files, but you shouldn't need to
> mess with PATH or anything that has to do with system-wide
> loader.
>
> If we were to create a separate .so (read: win32/dll),
> that would be mod_perl_common.so since all these things in
> modperl_common.* have nothing to do with apr. But we want
> to avoid to impose that added enormous complexity on our
> users.
This fiddling with the PATH was just to get the tests
working (one could also use a LoadFile "...APR.dll"
directive to accomplish the same thing). There's probably
some internal way to do that within APR::*, along the
lines of loading APR.so within APR/Foo.so, so that users
don't have to be bothered.
> > In any case, no source code changes were needed - I think
> > all the above can be done within the Makefile generation.
>
> It's fine to change the source if it's needed :)
>
> Good work, Randy!
Thanks :)
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Mon, 17 May 2004, Stas Bekman wrote:
> [ ... ]
>
>>Randy Kobes wrote:
>>
>>>I'll try it for Windows and see how much is involved; if
>>>this works as expected, it should just involve changing
>>>how things are compiled, as well as the order (APR.so coming
>>>first). But one of the joys of working with Windows is
>>>that things are never as expected ;)
>
>
> I've now tried it on Windows, and in particular the
> (patched) apr-ext tests pass. This though was manual;
Great!
> I'll next try to get things built automatically. But
> just for information, what was required was
> - adjust xs/APR/APR/APR.def to include
> modperl_interp_unselect
> modperl_hash_tie
> modperl_hash_tied_object
> modperl_perl_gensym
> modperl_error_strerror
> in the list of exported symbols
We ought to automate that. I think you've missed symbols, like tracing
functions, since you didn't build with tracing enabled or because the
APR/Foo.o's that my patch tests don't use tracing. We should probably look at
the the apache/apr DECLARE macros. Alternatively it can be a common group of
files modperl_common_*.c but it'll be hard to extract those symbol names.
Another approach is to split the tables/ModPerl/Functions.pm (which I think
that's how .def is generated now). May be the function names should have a
different prefix than /modperl_/. In which case it'll be clear that they are
common ones.
> - build APR first, so APR::* can link against it (the
> default action is to build APR::* first);
Really? Is it specific to win32? On linux with the current cvs, I can run
'make -j' which builds things in parallel and I was getting APR/*.so getting
build while src/modules/perl/mod_perl.so was still not built. But I don't see
problem with arranging what you did.
> - adjust the Makefiles in APR::* to link to
> blib/arch/Apache2/auto/APR/APR.lib
> before linking to src/modules/perl/mod_perl.lib
Good.
> - add
> blib/arch/Apache2/auto/APR/
> to the PATH, so APR.dll can be found (perhaps APR.dll
> [APR.so] should be installed to $APACHE2/lib or
> $APACHE2/bin, as appropriate?)
That's not good. The whole idea was not to create a library which will need to
be searched by the loader. The ideas was to have a plain .so which will live
under perl's lib, and loading any APR/Foo.pm will first load APR.so, and then
APR/Foo.so. So yes, there is a need to change the autogenerated APR/*.pm
files, but you shouldn't need to mess with PATH or anything that has to do
with system-wide loader.
If we were to create a separate .so (read: win32/dll), that would be
mod_perl_common.so since all these things in modperl_common.* have nothing to
do with apr. But we want to avoid to impose that added enormous complexity on
our users.
> In any case, no source code changes were needed - I think
> all the above can be done within the Makefile generation.
It's fine to change the source if it's needed :)
Good work, Randy!
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Mon, 17 May 2004, Stas Bekman wrote:
> [ ... ]
>
>>Randy Kobes wrote:
>>
>>>I'll try it for Windows and see how much is involved; if
>>>this works as expected, it should just involve changing
>>>how things are compiled, as well as the order (APR.so coming
>>>first). But one of the joys of working with Windows is
>>>that things are never as expected ;)
>
>
> I've now tried it on Windows, and in particular the
> (patched) apr-ext tests pass. This though was manual;
Great!
> I'll next try to get things built automatically. But
> just for information, what was required was
> - adjust xs/APR/APR/APR.def to include
> modperl_interp_unselect
> modperl_hash_tie
> modperl_hash_tied_object
> modperl_perl_gensym
> modperl_error_strerror
> in the list of exported symbols
We ought to automate that. I think you've missed symbols, like tracing
functions, since you didn't build with tracing enabled or because the
APR/Foo.o's that my patch tests don't use tracing. We should probably look at
the the apache/apr DECLARE macros. Alternatively it can be a common group of
files modperl_common_*.c but it'll be hard to extract those symbol names.
Another approach is to split the tables/ModPerl/Functions.pm (which I think
that's how .def is generated now). May be the function names should have a
different prefix than /modperl_/. In which case it'll be clear that they are
common ones.
> - build APR first, so APR::* can link against it (the
> default action is to build APR::* first);
Really? Is it specific to win32? On linux with the current cvs, I can run
'make -j' which builds things in parallel and I was getting APR/*.so getting
build while src/modules/perl/mod_perl.so was still not built. But I don't see
problem with arranging what you did.
> - adjust the Makefiles in APR::* to link to
> blib/arch/Apache2/auto/APR/APR.lib
> before linking to src/modules/perl/mod_perl.lib
Good.
> - add
> blib/arch/Apache2/auto/APR/
> to the PATH, so APR.dll can be found (perhaps APR.dll
> [APR.so] should be installed to $APACHE2/lib or
> $APACHE2/bin, as appropriate?)
That's not good. The whole idea was not to create a library which will need to
be searched by the loader. The ideas was to have a plain .so which will live
under perl's lib, and loading any APR/Foo.pm will first load APR.so, and then
APR/Foo.so. So yes, there is a need to change the autogenerated APR/*.pm
files, but you shouldn't need to mess with PATH or anything that has to do
with system-wide loader.
If we were to create a separate .so (read: win32/dll), that would be
mod_perl_common.so since all these things in modperl_common.* have nothing to
do with apr. But we want to avoid to impose that added enormous complexity on
our users.
> In any case, no source code changes were needed - I think
> all the above can be done within the Makefile generation.
It's fine to change the source if it's needed :)
Good work, Randy!
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 17 May 2004, Stas Bekman wrote:
[ ... ]
> Randy Kobes wrote:
> >
> > I'll try it for Windows and see how much is involved; if
> > this works as expected, it should just involve changing
> > how things are compiled, as well as the order (APR.so coming
> > first). But one of the joys of working with Windows is
> > that things are never as expected ;)
I've now tried it on Windows, and in particular the
(patched) apr-ext tests pass. This though was manual;
I'll next try to get things built automatically. But
just for information, what was required was
- adjust xs/APR/APR/APR.def to include
modperl_interp_unselect
modperl_hash_tie
modperl_hash_tied_object
modperl_perl_gensym
modperl_error_strerror
in the list of exported symbols
- build APR first, so APR::* can link against it (the
default action is to build APR::* first);
- adjust the Makefiles in APR::* to link to
blib/arch/Apache2/auto/APR/APR.lib
before linking to src/modules/perl/mod_perl.lib
- add
blib/arch/Apache2/auto/APR/
to the PATH, so APR.dll can be found (perhaps APR.dll
[APR.so] should be installed to $APACHE2/lib or
$APACHE2/bin, as appropriate?)
In any case, no source code changes were needed - I think
all the above can be done within the Makefile generation.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 17 May 2004, Stas Bekman wrote:
[ ... ]
> Randy Kobes wrote:
> >
> > I'll try it for Windows and see how much is involved; if
> > this works as expected, it should just involve changing
> > how things are compiled, as well as the order (APR.so coming
> > first). But one of the joys of working with Windows is
> > that things are never as expected ;)
I've now tried it on Windows, and in particular the
(patched) apr-ext tests pass. This though was manual;
I'll next try to get things built automatically. But
just for information, what was required was
- adjust xs/APR/APR/APR.def to include
modperl_interp_unselect
modperl_hash_tie
modperl_hash_tied_object
modperl_perl_gensym
modperl_error_strerror
in the list of exported symbols
- build APR first, so APR::* can link against it (the
default action is to build APR::* first);
- adjust the Makefiles in APR::* to link to
blib/arch/Apache2/auto/APR/APR.lib
before linking to src/modules/perl/mod_perl.lib
- add
blib/arch/Apache2/auto/APR/
to the PATH, so APR.dll can be found (perhaps APR.dll
[APR.so] should be installed to $APACHE2/lib or
$APACHE2/bin, as appropriate?)
In any case, no source code changes were needed - I think
all the above can be done within the Makefile generation.
--
best regards,
randy
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Sun, 16 May 2004, Stas Bekman wrote:
>
>
>>>I'm not sure at the moment, but here's the test case
>>>I used with VC++ (I'll try it tomorrow on linux).
>>
>>[test case snipped]
>>
>>That's neat, Randy. If it works on linux I suggest that we
>>post it to the apr-dev list and ask for an advice there.
>>After all we try to solve the problem for APR interface,
>>so it shouldn't be offtopic. And I'm sure folks there will
>>give us a definitive yes, no, and may be some extra
>>advice.
>
>
> Hi Stas,
> I've tried the example on linux (gcc 3.2.2), and it
> seems to work the same. Just to be explicit, how I compiled
> things are as follows:
>
> export LD_LIBRARY_PATH=$HOME
> gcc -c -fPIC a.c
> gcc -shared -fPIC -o libmya.so a.o
> gcc -c -fPIC b.c
> gcc -shared -fPIC -o libmyb.so b.o
> gcc -c -fPIC c.c
>
> Then tried making libmyc.so in two ways:
> 1) gcc -shared -fPIC -o libmyc.so -L$HOME -lmya -lmyb
> 2) gcc -shared -fPIC -o libmyc.so -L$HOME -lmyb -lmya
>
> and compiling the testit application as
> gcc -o testit testit.c -L$HOME -lmyc
>
> Using the 1st way of making libmyc.so (-lmya -lmyb), testit
> outputs
>
> Hello from a
> Hello again from b
>
> whereas the 2nd way of making libmyc.so (-lmyb -lmya) yields
>
> Hello from b
> Hello again from b
Excellent! Good work, Randy!
> One apparent difference between Windows and linux is that,
> in the 2nd way of compiling libmyc.so (-lmyb -lmya, where
> both required symbols come from libmyb.so), on Linux
> libmya.so still needs to be available, whereas on Windows
> it doesn't.
That should be fine, since APR/Foo.o will be linked against APR.so only.
>>If everything else failing, it seems like we have a happy solution for
>>windows. But ideally I'd like to see one solution for all platforms if
>>such is possible. Do you think it's worth the try? I guess you will see
>>first how hard is it going to be to make the special case for windows. If
>>there is not too much mess, we may just do it for windows.
>
>
> I'll try it for Windows and see how much is involved; if
> this works as expected, it should just involve changing
> how things are compiled, as well as the order (APR.so coming
> first). But one of the joys of working with Windows is
> that things are never as expected ;)
:)
>>But I keep on mentioning AIX, which also wants a similar
>>to .def file (.exp I think), so it probably will have the
>>same issues.
>
>
> I don't have access to an AIX machine, but it looks like
> it would be similar to Windows, and much of the special
> handling seems to be already in place as far as link
> options, etc. go.
Yes, the only change that will be needed is that .exp handling, similar to
windows's .def.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Sun, 16 May 2004, Stas Bekman wrote:
>
>
>>>I'm not sure at the moment, but here's the test case
>>>I used with VC++ (I'll try it tomorrow on linux).
>>
>>[test case snipped]
>>
>>That's neat, Randy. If it works on linux I suggest that we
>>post it to the apr-dev list and ask for an advice there.
>>After all we try to solve the problem for APR interface,
>>so it shouldn't be offtopic. And I'm sure folks there will
>>give us a definitive yes, no, and may be some extra
>>advice.
>
>
> Hi Stas,
> I've tried the example on linux (gcc 3.2.2), and it
> seems to work the same. Just to be explicit, how I compiled
> things are as follows:
>
> export LD_LIBRARY_PATH=$HOME
> gcc -c -fPIC a.c
> gcc -shared -fPIC -o libmya.so a.o
> gcc -c -fPIC b.c
> gcc -shared -fPIC -o libmyb.so b.o
> gcc -c -fPIC c.c
>
> Then tried making libmyc.so in two ways:
> 1) gcc -shared -fPIC -o libmyc.so -L$HOME -lmya -lmyb
> 2) gcc -shared -fPIC -o libmyc.so -L$HOME -lmyb -lmya
>
> and compiling the testit application as
> gcc -o testit testit.c -L$HOME -lmyc
>
> Using the 1st way of making libmyc.so (-lmya -lmyb), testit
> outputs
>
> Hello from a
> Hello again from b
>
> whereas the 2nd way of making libmyc.so (-lmyb -lmya) yields
>
> Hello from b
> Hello again from b
Excellent! Good work, Randy!
> One apparent difference between Windows and linux is that,
> in the 2nd way of compiling libmyc.so (-lmyb -lmya, where
> both required symbols come from libmyb.so), on Linux
> libmya.so still needs to be available, whereas on Windows
> it doesn't.
That should be fine, since APR/Foo.o will be linked against APR.so only.
>>If everything else failing, it seems like we have a happy solution for
>>windows. But ideally I'd like to see one solution for all platforms if
>>such is possible. Do you think it's worth the try? I guess you will see
>>first how hard is it going to be to make the special case for windows. If
>>there is not too much mess, we may just do it for windows.
>
>
> I'll try it for Windows and see how much is involved; if
> this works as expected, it should just involve changing
> how things are compiled, as well as the order (APR.so coming
> first). But one of the joys of working with Windows is
> that things are never as expected ;)
:)
>>But I keep on mentioning AIX, which also wants a similar
>>to .def file (.exp I think), so it probably will have the
>>same issues.
>
>
> I don't have access to an AIX machine, but it looks like
> it would be similar to Windows, and much of the special
> handling seems to be already in place as far as link
> options, etc. go.
Yes, the only change that will be needed is that .exp handling, similar to
windows's .def.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sun, 16 May 2004, Stas Bekman wrote:
> > I'm not sure at the moment, but here's the test case
> > I used with VC++ (I'll try it tomorrow on linux).
> [test case snipped]
>
> That's neat, Randy. If it works on linux I suggest that we
> post it to the apr-dev list and ask for an advice there.
> After all we try to solve the problem for APR interface,
> so it shouldn't be offtopic. And I'm sure folks there will
> give us a definitive yes, no, and may be some extra
> advice.
Hi Stas,
I've tried the example on linux (gcc 3.2.2), and it
seems to work the same. Just to be explicit, how I compiled
things are as follows:
export LD_LIBRARY_PATH=$HOME
gcc -c -fPIC a.c
gcc -shared -fPIC -o libmya.so a.o
gcc -c -fPIC b.c
gcc -shared -fPIC -o libmyb.so b.o
gcc -c -fPIC c.c
Then tried making libmyc.so in two ways:
1) gcc -shared -fPIC -o libmyc.so -L$HOME -lmya -lmyb
2) gcc -shared -fPIC -o libmyc.so -L$HOME -lmyb -lmya
and compiling the testit application as
gcc -o testit testit.c -L$HOME -lmyc
Using the 1st way of making libmyc.so (-lmya -lmyb), testit
outputs
Hello from a
Hello again from b
whereas the 2nd way of making libmyc.so (-lmyb -lmya) yields
Hello from b
Hello again from b
One apparent difference between Windows and linux is that,
in the 2nd way of compiling libmyc.so (-lmyb -lmya, where
both required symbols come from libmyb.so), on Linux
libmya.so still needs to be available, whereas on Windows
it doesn't.
> If everything else failing, it seems like we have a happy solution for
> windows. But ideally I'd like to see one solution for all platforms if
> such is possible. Do you think it's worth the try? I guess you will see
> first how hard is it going to be to make the special case for windows. If
> there is not too much mess, we may just do it for windows.
I'll try it for Windows and see how much is involved; if
this works as expected, it should just involve changing
how things are compiled, as well as the order (APR.so coming
first). But one of the joys of working with Windows is
that things are never as expected ;)
> But I keep on mentioning AIX, which also wants a similar
> to .def file (.exp I think), so it probably will have the
> same issues.
I don't have access to an AIX machine, but it looks like
it would be similar to Windows, and much of the special
handling seems to be already in place as far as link
options, etc. go.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sun, 16 May 2004, Stas Bekman wrote:
> > I'm not sure at the moment, but here's the test case
> > I used with VC++ (I'll try it tomorrow on linux).
> [test case snipped]
>
> That's neat, Randy. If it works on linux I suggest that we
> post it to the apr-dev list and ask for an advice there.
> After all we try to solve the problem for APR interface,
> so it shouldn't be offtopic. And I'm sure folks there will
> give us a definitive yes, no, and may be some extra
> advice.
Hi Stas,
I've tried the example on linux (gcc 3.2.2), and it
seems to work the same. Just to be explicit, how I compiled
things are as follows:
export LD_LIBRARY_PATH=$HOME
gcc -c -fPIC a.c
gcc -shared -fPIC -o libmya.so a.o
gcc -c -fPIC b.c
gcc -shared -fPIC -o libmyb.so b.o
gcc -c -fPIC c.c
Then tried making libmyc.so in two ways:
1) gcc -shared -fPIC -o libmyc.so -L$HOME -lmya -lmyb
2) gcc -shared -fPIC -o libmyc.so -L$HOME -lmyb -lmya
and compiling the testit application as
gcc -o testit testit.c -L$HOME -lmyc
Using the 1st way of making libmyc.so (-lmya -lmyb), testit
outputs
Hello from a
Hello again from b
whereas the 2nd way of making libmyc.so (-lmyb -lmya) yields
Hello from b
Hello again from b
One apparent difference between Windows and linux is that,
in the 2nd way of compiling libmyc.so (-lmyb -lmya, where
both required symbols come from libmyb.so), on Linux
libmya.so still needs to be available, whereas on Windows
it doesn't.
> If everything else failing, it seems like we have a happy solution for
> windows. But ideally I'd like to see one solution for all platforms if
> such is possible. Do you think it's worth the try? I guess you will see
> first how hard is it going to be to make the special case for windows. If
> there is not too much mess, we may just do it for windows.
I'll try it for Windows and see how much is involved; if
this works as expected, it should just involve changing
how things are compiled, as well as the order (APR.so coming
first). But one of the joys of working with Windows is
that things are never as expected ;)
> But I keep on mentioning AIX, which also wants a similar
> to .def file (.exp I think), so it probably will have the
> same issues.
I don't have access to an AIX machine, but it looks like
it would be similar to Windows, and much of the special
handling seems to be already in place as far as link
options, etc. go.
--
best regards,
randy
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
> I'm not sure at the moment, but here's the test case
> I used with VC++ (I'll try it tomorrow on linux).
[test case snipped]
That's neat, Randy. If it works on linux I suggest that we post it to the
apr-dev list and ask for an advice there. After all we try to solve the
problem for APR interface, so it shouldn't be offtopic. And I'm sure folks
there will give us a definitive yes, no, and may be some extra advice.
If everything else failing, it seems like we have a happy solution for
windows. But ideally I'd like to see one solution for all platforms if
such is possible. Do you think it's worth the try? I guess you will see
first how hard is it going to be to make the special case for windows. If
there is not too much mess, we may just do it for windows.
But I keep on mentioning AIX, which also wants a similar to .def file
(.exp I think), so it probably will have the same issues.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
> I'm not sure at the moment, but here's the test case
> I used with VC++ (I'll try it tomorrow on linux).
[test case snipped]
That's neat, Randy. If it works on linux I suggest that we post it to the
apr-dev list and ask for an advice there. After all we try to solve the
problem for APR interface, so it shouldn't be offtopic. And I'm sure folks
there will give us a definitive yes, no, and may be some extra advice.
If everything else failing, it seems like we have a happy solution for
windows. But ideally I'd like to see one solution for all platforms if
such is possible. Do you think it's worth the try? I guess you will see
first how hard is it going to be to make the special case for windows. If
there is not too much mess, we may just do it for windows.
But I keep on mentioning AIX, which also wants a similar to .def file
(.exp I think), so it probably will have the same issues.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sun, 16 May 2004, Stas Bekman wrote:
[ ... ]
> That's excellent. So you link APR/Foo.so against APR.so
> which contains the minimal amount of modperl_xxx.o in it
> which is already provided by my patch (you only need to
> arrange linking against APR.lib instead of mod_perl.lib).
> APR/Foo.pm then must make sure that APR.pm (and so APR.so)
> are loaded before it loads its own APR/Foo.so. But this
> could be done later, for now let's say that we do it
> manually, by doing
>
> PerlModule APR
>
> immediately after
>
> LoadModule mod_perl.so
>
> Now the question is, whether the same could work for all
> other platforms. I was sure that's it's not possible to
> load two objects with the same symbols, but I could be
> wrong. Do you know whether this is true for all platforms?
I'm not sure at the moment, but here's the test case
I used with VC++ (I'll try it tomorrow on linux).
First build a.dll that exports a symbol testit():
==================================================
#include "a.h"
#include <stdio.h>
void testit(void) {
printf("Hello from a\n");
}
=================================================
which is compiled as
cl -c a.c
link -dll a.obj ... -def:a.def -out:a.dll
Then build b.dll that exports two symbols, testit()
and testit_again():
=================================================
// file b.c
#include "b.h"
#include <stdio.h>
void testit(void) {
printf("Hello from b\n");
}
void testit_again(void) {
printf("Hello again from b\n");
}
=================================================
which is compiled as
cl -c b.c
link -dll b.obj ... -def:b.def -out:b.dll
Now build a 3rd dll c.dll that exports printit()
and imports testit() and testit_again():
=================================================
// file c.c
#include "c.h"
#include "a.h"
#include "b.h"
void printit(void) {
testit();
testit_again();
}
=================================================
which is compiled as
cl -c c.c
but linked in one of two ways:
1) link -dll c.obj a.lib b.lib ... -def:c.def -out:c.dll
1) link -dll c.obj b.lib a.lib ... -def:c.def -out:c.dll
An application testit.c is then built which is linked
against c.lib:
================================================
// file testit.c
#include "c.h"
int main(void) {
printit();
return 0;
}
===============================================
cl testit.c c.lib
If c.lib is built the 1st way (a.lib b.lib), then
testit outputs
Hello from a
Hello again from b
and requires c.dll, a.dll, and b.dll to be available. Thus,
even though both a.dll and b.dll both contain testit(), and
both dlls get loaded in the application, c.dll uses the
testit() from a.dll, since it was specified first at link
time.
On the other hand, if c.lib is built the 2nd way (b.lib
a.lib), then testit outputs
Hello from b
Hello again from b
and requires c.dll and b.dll to be available. In this
case all symbols get resolved by b.dll, as it was
specified first at link time, and so a.dll is ignored.
--
best regards,
randy
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sun, 16 May 2004, Stas Bekman wrote:
[ ... ]
> That's excellent. So you link APR/Foo.so against APR.so
> which contains the minimal amount of modperl_xxx.o in it
> which is already provided by my patch (you only need to
> arrange linking against APR.lib instead of mod_perl.lib).
> APR/Foo.pm then must make sure that APR.pm (and so APR.so)
> are loaded before it loads its own APR/Foo.so. But this
> could be done later, for now let's say that we do it
> manually, by doing
>
> PerlModule APR
>
> immediately after
>
> LoadModule mod_perl.so
>
> Now the question is, whether the same could work for all
> other platforms. I was sure that's it's not possible to
> load two objects with the same symbols, but I could be
> wrong. Do you know whether this is true for all platforms?
I'm not sure at the moment, but here's the test case
I used with VC++ (I'll try it tomorrow on linux).
First build a.dll that exports a symbol testit():
==================================================
#include "a.h"
#include <stdio.h>
void testit(void) {
printf("Hello from a\n");
}
=================================================
which is compiled as
cl -c a.c
link -dll a.obj ... -def:a.def -out:a.dll
Then build b.dll that exports two symbols, testit()
and testit_again():
=================================================
// file b.c
#include "b.h"
#include <stdio.h>
void testit(void) {
printf("Hello from b\n");
}
void testit_again(void) {
printf("Hello again from b\n");
}
=================================================
which is compiled as
cl -c b.c
link -dll b.obj ... -def:b.def -out:b.dll
Now build a 3rd dll c.dll that exports printit()
and imports testit() and testit_again():
=================================================
// file c.c
#include "c.h"
#include "a.h"
#include "b.h"
void printit(void) {
testit();
testit_again();
}
=================================================
which is compiled as
cl -c c.c
but linked in one of two ways:
1) link -dll c.obj a.lib b.lib ... -def:c.def -out:c.dll
1) link -dll c.obj b.lib a.lib ... -def:c.def -out:c.dll
An application testit.c is then built which is linked
against c.lib:
================================================
// file testit.c
#include "c.h"
int main(void) {
printit();
return 0;
}
===============================================
cl testit.c c.lib
If c.lib is built the 1st way (a.lib b.lib), then
testit outputs
Hello from a
Hello again from b
and requires c.dll, a.dll, and b.dll to be available. Thus,
even though both a.dll and b.dll both contain testit(), and
both dlls get loaded in the application, c.dll uses the
testit() from a.dll, since it was specified first at link
time.
On the other hand, if c.lib is built the 2nd way (b.lib
a.lib), then testit outputs
Hello from b
Hello again from b
and requires c.dll and b.dll to be available. In this
case all symbols get resolved by b.dll, as it was
specified first at link time, and so a.dll is ignored.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
[...]
>>I'm not sure how can you go with the latter idea. I mean,
>>I'll work perfectly fine without mod_perl. But how is it
>>going to work under mod_perl, when both mod_perl.so and
>>APR.so will have the same symbols, and according to your
>>suggestion, both will be loaded (since APR/Foo.so will be
>>linked against APR.so).
>
>
> In this approach I don't there's a problem on Windows with
> linking against libraries with the same symbols; depending
> on the order of the libraries in the link command, VC++
> will resolve the symbols not found in the object files in
> the 1st library file it finds that has them (which then
> registers the corresponding .so, if it's a shared library),
> so any identical symbols in a later library used in the link
> command are ignored. Thus, you could in principle build
> an application linked against two dlls that have the
> same symbols in them and there shouldn't be a conflict,
> as the application knows, from how it was linked, which
> dll each symbol comes from.
That's excellent. So you link APR/Foo.so against APR.so which contains the
minimal amount of modperl_xxx.o in it which is already provided by my patch
(you only need to arrange linking against APR.lib instead of mod_perl.lib).
APR/Foo.pm then must make sure that APR.pm (and so APR.so) are loaded before
it loads its own APR/Foo.so. But this could be done later, for now let's say
that we do it manually, by doing
PerlModule APR
immediately after
LoadModule mod_perl.so
Now the question is, whether the same could work for all other platforms. I
was sure that's it's not possible to load two objects with the same symbols,
but I could be wrong. Do you know whether this is true for all platforms?
> However, this also means that no symbols can be resolved
> through mod_perl.lib, as this would require loading
> mod_perl.so (unless one used the -delayload link option,
> to load the dll only if a symbol is invoked).
That's perfectly fine.
>>It would have worked perfectly if
>>we could also link mod_perl.so against APR.so and not
>>include those symbols in mod_perl.so. Which is probably
>>the best solution possible. The problem is that the loaded
>>will somehow have to find APR.so when trying to load
>>mod_perl.so. This could have been done by installing
>>APR.so along with libapr.so I suppose.
>>In that case we will have APR a totally autonomous systems and mod_perl
>>will use it. May be it makes perfect sense, but I haven't thought of the
>>implications for users.
>>
>>
>>>It should be relatively straightforward to do the latter (as
>>>long as APR.so is built before APR::*). However, with the
>>>former, there'd be problems building the individual APR::*
>>>modules first, to be used as components in building APR.so,
>>>for the same reason that exists now - to build APR::*, one
>>>has to specify the library where the symbols are found, and
>>>one can't specify a library (APR.so) that hasn't been built
>>>yet.
>>
>>But I was talking about building .o objects, not shared
>>libs. and linking those .o objects with APR.so. Will that
>>be a problem too? AFAIK you never need to provide
>>information about shared libs, during compilation time. Is
>>that different on windows?
>
>
> No, you're right - resolving all symbols only is required at
> link time, so this could be done by just compiling (with -c)
> the APR::* files to build the object files, and skip
> building the associated APR::* dlls, as is done now.
>
> I think things are becoming clearer to me - thanks.
> It looks like most of this can be done by fiddling
> with the compiling/linking commands, without the need
> (hopefully) of any source code modifications. I'll
> try it and see.
Correct. I think your suggestion at the top is much better that dumping all .o
into APR.so. If it works for every platform then we are gold.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
[...]
>>I'm not sure how can you go with the latter idea. I mean,
>>I'll work perfectly fine without mod_perl. But how is it
>>going to work under mod_perl, when both mod_perl.so and
>>APR.so will have the same symbols, and according to your
>>suggestion, both will be loaded (since APR/Foo.so will be
>>linked against APR.so).
>
>
> In this approach I don't there's a problem on Windows with
> linking against libraries with the same symbols; depending
> on the order of the libraries in the link command, VC++
> will resolve the symbols not found in the object files in
> the 1st library file it finds that has them (which then
> registers the corresponding .so, if it's a shared library),
> so any identical symbols in a later library used in the link
> command are ignored. Thus, you could in principle build
> an application linked against two dlls that have the
> same symbols in them and there shouldn't be a conflict,
> as the application knows, from how it was linked, which
> dll each symbol comes from.
That's excellent. So you link APR/Foo.so against APR.so which contains the
minimal amount of modperl_xxx.o in it which is already provided by my patch
(you only need to arrange linking against APR.lib instead of mod_perl.lib).
APR/Foo.pm then must make sure that APR.pm (and so APR.so) are loaded before
it loads its own APR/Foo.so. But this could be done later, for now let's say
that we do it manually, by doing
PerlModule APR
immediately after
LoadModule mod_perl.so
Now the question is, whether the same could work for all other platforms. I
was sure that's it's not possible to load two objects with the same symbols,
but I could be wrong. Do you know whether this is true for all platforms?
> However, this also means that no symbols can be resolved
> through mod_perl.lib, as this would require loading
> mod_perl.so (unless one used the -delayload link option,
> to load the dll only if a symbol is invoked).
That's perfectly fine.
>>It would have worked perfectly if
>>we could also link mod_perl.so against APR.so and not
>>include those symbols in mod_perl.so. Which is probably
>>the best solution possible. The problem is that the loaded
>>will somehow have to find APR.so when trying to load
>>mod_perl.so. This could have been done by installing
>>APR.so along with libapr.so I suppose.
>>In that case we will have APR a totally autonomous systems and mod_perl
>>will use it. May be it makes perfect sense, but I haven't thought of the
>>implications for users.
>>
>>
>>>It should be relatively straightforward to do the latter (as
>>>long as APR.so is built before APR::*). However, with the
>>>former, there'd be problems building the individual APR::*
>>>modules first, to be used as components in building APR.so,
>>>for the same reason that exists now - to build APR::*, one
>>>has to specify the library where the symbols are found, and
>>>one can't specify a library (APR.so) that hasn't been built
>>>yet.
>>
>>But I was talking about building .o objects, not shared
>>libs. and linking those .o objects with APR.so. Will that
>>be a problem too? AFAIK you never need to provide
>>information about shared libs, during compilation time. Is
>>that different on windows?
>
>
> No, you're right - resolving all symbols only is required at
> link time, so this could be done by just compiling (with -c)
> the APR::* files to build the object files, and skip
> building the associated APR::* dlls, as is done now.
>
> I think things are becoming clearer to me - thanks.
> It looks like most of this can be done by fiddling
> with the compiling/linking commands, without the need
> (hopefully) of any source code modifications. I'll
> try it and see.
Correct. I think your suggestion at the top is much better that dumping all .o
into APR.so. If it works for every platform then we are gold.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sun, 16 May 2004, Stas Bekman wrote:
> On Sun, 16 May 2004, Randy Kobes wrote:
[ .. ]
> Well, I don't want to destabilize the tree, we should make
> a new release pretty soon. I think while you are playing
> with various solutions you could just check the cvs tree
> for the day I've posted my second patch and it should
> apply just fine. Your work is going to be in the
> xs/APR/APR area, not really touching anything else. If you
> think it's a problem I'll then try to post an up-to-date
> patch, but it may quickly become out-of-date in a few
> days.
Sounds good ...
> > > I guess all you need to do is to change
> > > xs/APR/APR/Makefile.PL to collect all .o files from under
> > > xs/APR and a few selected src/modules/perl/modperl_xxx.o
> > > and link them statically with APR.so if under win32. (and
> > > may be some other platforms too (aix comes to mind)).
> >
> > Just so I understand correctly, in this approach we'll have
> > one (big) APR.so that has collected all the functionality of
> > the individual APR::* modules (as well as the old APR.so
> > itself and selected symbols from modperl_xxx.o)? Or does APR
> > stay essentially the same (with the added symbols from
> > selected modperl_xxx.o), and then one links each APR::* with
> > APR.so?
>
> I was talking about the former, where APR.so will include all
> objects in Wrap/APR/*/.o (not .so) and some
> of src/modules/perl/modperl_xxx.o.
OK, that makes sense ...
> I'm not sure how can you go with the latter idea. I mean,
> I'll work perfectly fine without mod_perl. But how is it
> going to work under mod_perl, when both mod_perl.so and
> APR.so will have the same symbols, and according to your
> suggestion, both will be loaded (since APR/Foo.so will be
> linked against APR.so).
In this approach I don't there's a problem on Windows with
linking against libraries with the same symbols; depending
on the order of the libraries in the link command, VC++
will resolve the symbols not found in the object files in
the 1st library file it finds that has them (which then
registers the corresponding .so, if it's a shared library),
so any identical symbols in a later library used in the link
command are ignored. Thus, you could in principle build
an application linked against two dlls that have the
same symbols in them and there shouldn't be a conflict,
as the application knows, from how it was linked, which
dll each symbol comes from.
However, this also means that no symbols can be resolved
through mod_perl.lib, as this would require loading
mod_perl.so (unless one used the -delayload link option,
to load the dll only if a symbol is invoked).
> It would have worked perfectly if
> we could also link mod_perl.so against APR.so and not
> include those symbols in mod_perl.so. Which is probably
> the best solution possible. The problem is that the loaded
> will somehow have to find APR.so when trying to load
> mod_perl.so. This could have been done by installing
> APR.so along with libapr.so I suppose.
> In that case we will have APR a totally autonomous systems and mod_perl
> will use it. May be it makes perfect sense, but I haven't thought of the
> implications for users.
>
> > It should be relatively straightforward to do the latter (as
> > long as APR.so is built before APR::*). However, with the
> > former, there'd be problems building the individual APR::*
> > modules first, to be used as components in building APR.so,
> > for the same reason that exists now - to build APR::*, one
> > has to specify the library where the symbols are found, and
> > one can't specify a library (APR.so) that hasn't been built
> > yet.
>
> But I was talking about building .o objects, not shared
> libs. and linking those .o objects with APR.so. Will that
> be a problem too? AFAIK you never need to provide
> information about shared libs, during compilation time. Is
> that different on windows?
No, you're right - resolving all symbols only is required at
link time, so this could be done by just compiling (with -c)
the APR::* files to build the object files, and skip
building the associated APR::* dlls, as is done now.
I think things are becoming clearer to me - thanks.
It looks like most of this can be done by fiddling
with the compiling/linking commands, without the need
(hopefully) of any source code modifications. I'll
try it and see.
--
best regards,
randy
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sun, 16 May 2004, Stas Bekman wrote:
> On Sun, 16 May 2004, Randy Kobes wrote:
[ .. ]
> Well, I don't want to destabilize the tree, we should make
> a new release pretty soon. I think while you are playing
> with various solutions you could just check the cvs tree
> for the day I've posted my second patch and it should
> apply just fine. Your work is going to be in the
> xs/APR/APR area, not really touching anything else. If you
> think it's a problem I'll then try to post an up-to-date
> patch, but it may quickly become out-of-date in a few
> days.
Sounds good ...
> > > I guess all you need to do is to change
> > > xs/APR/APR/Makefile.PL to collect all .o files from under
> > > xs/APR and a few selected src/modules/perl/modperl_xxx.o
> > > and link them statically with APR.so if under win32. (and
> > > may be some other platforms too (aix comes to mind)).
> >
> > Just so I understand correctly, in this approach we'll have
> > one (big) APR.so that has collected all the functionality of
> > the individual APR::* modules (as well as the old APR.so
> > itself and selected symbols from modperl_xxx.o)? Or does APR
> > stay essentially the same (with the added symbols from
> > selected modperl_xxx.o), and then one links each APR::* with
> > APR.so?
>
> I was talking about the former, where APR.so will include all
> objects in Wrap/APR/*/.o (not .so) and some
> of src/modules/perl/modperl_xxx.o.
OK, that makes sense ...
> I'm not sure how can you go with the latter idea. I mean,
> I'll work perfectly fine without mod_perl. But how is it
> going to work under mod_perl, when both mod_perl.so and
> APR.so will have the same symbols, and according to your
> suggestion, both will be loaded (since APR/Foo.so will be
> linked against APR.so).
In this approach I don't there's a problem on Windows with
linking against libraries with the same symbols; depending
on the order of the libraries in the link command, VC++
will resolve the symbols not found in the object files in
the 1st library file it finds that has them (which then
registers the corresponding .so, if it's a shared library),
so any identical symbols in a later library used in the link
command are ignored. Thus, you could in principle build
an application linked against two dlls that have the
same symbols in them and there shouldn't be a conflict,
as the application knows, from how it was linked, which
dll each symbol comes from.
However, this also means that no symbols can be resolved
through mod_perl.lib, as this would require loading
mod_perl.so (unless one used the -delayload link option,
to load the dll only if a symbol is invoked).
> It would have worked perfectly if
> we could also link mod_perl.so against APR.so and not
> include those symbols in mod_perl.so. Which is probably
> the best solution possible. The problem is that the loaded
> will somehow have to find APR.so when trying to load
> mod_perl.so. This could have been done by installing
> APR.so along with libapr.so I suppose.
> In that case we will have APR a totally autonomous systems and mod_perl
> will use it. May be it makes perfect sense, but I haven't thought of the
> implications for users.
>
> > It should be relatively straightforward to do the latter (as
> > long as APR.so is built before APR::*). However, with the
> > former, there'd be problems building the individual APR::*
> > modules first, to be used as components in building APR.so,
> > for the same reason that exists now - to build APR::*, one
> > has to specify the library where the symbols are found, and
> > one can't specify a library (APR.so) that hasn't been built
> > yet.
>
> But I was talking about building .o objects, not shared
> libs. and linking those .o objects with APR.so. Will that
> be a problem too? AFAIK you never need to provide
> information about shared libs, during compilation time. Is
> that different on windows?
No, you're right - resolving all symbols only is required at
link time, so this could be done by just compiling (with -c)
the APR::* files to build the object files, and skip
building the associated APR::* dlls, as is done now.
I think things are becoming clearer to me - thanks.
It looks like most of this can be done by fiddling
with the compiling/linking commands, without the need
(hopefully) of any source code modifications. I'll
try it and see.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
On Sun, 16 May 2004, Randy Kobes wrote:
> On Sat, 15 May 2004, Stas Bekman wrote:
>
> > Randy Kobes wrote:
> > > On Mon, 10 May 2004, Stas Bekman wrote:
> > >
> > >>How about a quick workaround as follows: For windows only,
> > >>link APR.so statically with all APR/Foo.o and the required
> > >>modperl_foo.o and arrange for the bootstrap not to call it
> > >>for windows if APR.so is loaded?
> > >
> > >
> > > That sounds good ...
> >
> > So can you try to tackle that? I guess my latest patch
> > won't apply against the current cvs and I'll need to
> > re-sync it and resolve collisions.
>
> I'll give it a go ... So as I'll be current, could you
> re-sync it, if it's not too difficult? Alternatively,
> if the patch is OK on others (apart from Win32, and
> perhaps aix), is it ready to apply, and we'll work
> from there?
Well, I don't want to destabilize the tree, we should make a new release
pretty soon. I think while you are playing with various solutions you
could just check the cvs tree for the day I've posted my second patch and
it should apply just fine. Your work is going to be in the xs/APR/APR
area, not really touching anything else. If you think it's a problem I'll
then try to post an up-to-date patch, but it may quickly become
out-of-date in a few days.
> > I guess all you need to do is to change
> > xs/APR/APR/Makefile.PL to collect all .o files from under
> > xs/APR and a few selected src/modules/perl/modperl_xxx.o
> > and link them statically with APR.so if under win32. (and
> > may be some other platforms too (aix comes to mind)).
>
> Just so I understand correctly, in this approach we'll have
> one (big) APR.so that has collected all the functionality of
> the individual APR::* modules (as well as the old APR.so
> itself and selected symbols from modperl_xxx.o)? Or does APR
> stay essentially the same (with the added symbols from
> selected modperl_xxx.o), and then one links each APR::* with
> APR.so?
I was talking about the former, where APR.so will include all
objects in Wrap/APR/*/.o (not .so) and some
of src/modules/perl/modperl_xxx.o.
I'm not sure how can you go with the latter idea. I mean, I'll work
perfectly fine without mod_perl. But how is it going to work under
mod_perl, when both mod_perl.so and APR.so will have the same symbols, and
according to your suggestion, both will be loaded (since APR/Foo.so will
be linked against APR.so). It would have worked perfectly if we could also
link mod_perl.so against APR.so and not include those symbols in
mod_perl.so. Which is probably the best solution possible. The problem is
that the loaded will somehow have to find APR.so when trying to load
mod_perl.so. This could have been done by installing APR.so along with
libapr.so I suppose.
In that case we will have APR a totally autonomous systems and mod_perl
will use it. May be it makes perfect sense, but I haven't thought of the
implications for users.
> It should be relatively straightforward to do the latter (as
> long as APR.so is built before APR::*). However, with the
> former, there'd be problems building the individual APR::*
> modules first, to be used as components in building APR.so,
> for the same reason that exists now - to build APR::*, one
> has to specify the library where the symbols are found, and
> one can't specify a library (APR.so) that hasn't been built
> yet.
But I was talking about building .o objects, not shared libs. and linking
those .o objects with APR.so. Will that be a problem too? AFAIK you never
need to provide information about shared libs, during compilation time. Is
that different on windows?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
On Sun, 16 May 2004, Randy Kobes wrote:
> On Sat, 15 May 2004, Stas Bekman wrote:
>
> > Randy Kobes wrote:
> > > On Mon, 10 May 2004, Stas Bekman wrote:
> > >
> > >>How about a quick workaround as follows: For windows only,
> > >>link APR.so statically with all APR/Foo.o and the required
> > >>modperl_foo.o and arrange for the bootstrap not to call it
> > >>for windows if APR.so is loaded?
> > >
> > >
> > > That sounds good ...
> >
> > So can you try to tackle that? I guess my latest patch
> > won't apply against the current cvs and I'll need to
> > re-sync it and resolve collisions.
>
> I'll give it a go ... So as I'll be current, could you
> re-sync it, if it's not too difficult? Alternatively,
> if the patch is OK on others (apart from Win32, and
> perhaps aix), is it ready to apply, and we'll work
> from there?
Well, I don't want to destabilize the tree, we should make a new release
pretty soon. I think while you are playing with various solutions you
could just check the cvs tree for the day I've posted my second patch and
it should apply just fine. Your work is going to be in the xs/APR/APR
area, not really touching anything else. If you think it's a problem I'll
then try to post an up-to-date patch, but it may quickly become
out-of-date in a few days.
> > I guess all you need to do is to change
> > xs/APR/APR/Makefile.PL to collect all .o files from under
> > xs/APR and a few selected src/modules/perl/modperl_xxx.o
> > and link them statically with APR.so if under win32. (and
> > may be some other platforms too (aix comes to mind)).
>
> Just so I understand correctly, in this approach we'll have
> one (big) APR.so that has collected all the functionality of
> the individual APR::* modules (as well as the old APR.so
> itself and selected symbols from modperl_xxx.o)? Or does APR
> stay essentially the same (with the added symbols from
> selected modperl_xxx.o), and then one links each APR::* with
> APR.so?
I was talking about the former, where APR.so will include all
objects in Wrap/APR/*/.o (not .so) and some
of src/modules/perl/modperl_xxx.o.
I'm not sure how can you go with the latter idea. I mean, I'll work
perfectly fine without mod_perl. But how is it going to work under
mod_perl, when both mod_perl.so and APR.so will have the same symbols, and
according to your suggestion, both will be loaded (since APR/Foo.so will
be linked against APR.so). It would have worked perfectly if we could also
link mod_perl.so against APR.so and not include those symbols in
mod_perl.so. Which is probably the best solution possible. The problem is
that the loaded will somehow have to find APR.so when trying to load
mod_perl.so. This could have been done by installing APR.so along with
libapr.so I suppose.
In that case we will have APR a totally autonomous systems and mod_perl
will use it. May be it makes perfect sense, but I haven't thought of the
implications for users.
> It should be relatively straightforward to do the latter (as
> long as APR.so is built before APR::*). However, with the
> former, there'd be problems building the individual APR::*
> modules first, to be used as components in building APR.so,
> for the same reason that exists now - to build APR::*, one
> has to specify the library where the symbols are found, and
> one can't specify a library (APR.so) that hasn't been built
> yet.
But I was talking about building .o objects, not shared libs. and linking
those .o objects with APR.so. Will that be a problem too? AFAIK you never
need to provide information about shared libs, during compilation time. Is
that different on windows?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sat, 15 May 2004, Stas Bekman wrote:
> Randy Kobes wrote:
> > On Mon, 10 May 2004, Stas Bekman wrote:
> >
> >>How about a quick workaround as follows: For windows only,
> >>link APR.so statically with all APR/Foo.o and the required
> >>modperl_foo.o and arrange for the bootstrap not to call it
> >>for windows if APR.so is loaded?
> >
> >
> > That sounds good ...
>
> So can you try to tackle that? I guess my latest patch
> won't apply against the current cvs and I'll need to
> re-sync it and resolve collisions.
I'll give it a go ... So as I'll be current, could you
re-sync it, if it's not too difficult? Alternatively,
if the patch is OK on others (apart from Win32, and
perhaps aix), is it ready to apply, and we'll work
from there?
> I guess all you need to do is to change
> xs/APR/APR/Makefile.PL to collect all .o files from under
> xs/APR and a few selected src/modules/perl/modperl_xxx.o
> and link them statically with APR.so if under win32. (and
> may be some other platforms too (aix comes to mind)).
Just so I understand correctly, in this approach we'll have
one (big) APR.so that has collected all the functionality of
the individual APR::* modules (as well as the old APR.so
itself and selected symbols from modperl_xxx.o)? Or does APR
stay essentially the same (with the added symbols from
selected modperl_xxx.o), and then one links each APR::* with
APR.so?
It should be relatively straightforward to do the latter (as
long as APR.so is built before APR::*). However, with the
former, there'd be problems building the individual APR::*
modules first, to be used as components in building APR.so,
for the same reason that exists now - to build APR::*, one
has to specify the library where the symbols are found, and
one can't specify a library (APR.so) that hasn't been built
yet. This could be resolved in some cases by linking APR::*
against the relevant modperl_xxx.o files; however, for those
that require some functionality within APR.so itself, there
might be a problem ...
> > The only alternative I was able
> > to come up with is to use LoadLibrary/GetProcAddress
> > to set a function pointer to that of a function
> > within a dll. I tried to cut this down to the
> > minimal needed, and came up with something along
> > the lines of, generically,
> >
> > typdef ... /* delare the function pointers */
> >
> > HINSTANCE hlib;
> > if (GetProcAddresses(&hlib, "Some.dll",
> > &fn_1, "func_1",
> > &fn_2, "func_2",
> > ...) {
> > /* the functions are available */
> > }
> > if (hlib != NULL) FreeLibrary(hlib);
> >
> > where GetProcAddresses() is a simple (generic) routine that
> > associates, from Some.dll, func_1, func_2, ... with fn_1,
> > fn_2, ... So, in this approach, for each APR::* as
> > appropriate, necessary function pointers must be declared,
> > GetProcAddresses() is invoked, and finally, if necessary,
> > FreeLibrary() called at the end.
> >
> > However, I don't have enough experience with the build
> > system to compare if the above would be easier or harder to
> > set up and maintain, compared to linking against the
> > appropriate .so files.
>
> The biggest problem I see here, is that we won't be able
> to test whether things still work on windows, every time
> we change or add something. So I'd prefer not to use it.
> If this can be done automatically, without touching the
> existing code, then i guess it's OK. But I'm not quite
> sure this is possible.
That's certainly a concern ... If this is ever
attempted, I think some (most?) of it could be
done somewhat automatically, but maybe it'd be
better to explore the above approach first.
--
best regards,
randy
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sat, 15 May 2004, Stas Bekman wrote:
> Randy Kobes wrote:
> > On Mon, 10 May 2004, Stas Bekman wrote:
> >
> >>How about a quick workaround as follows: For windows only,
> >>link APR.so statically with all APR/Foo.o and the required
> >>modperl_foo.o and arrange for the bootstrap not to call it
> >>for windows if APR.so is loaded?
> >
> >
> > That sounds good ...
>
> So can you try to tackle that? I guess my latest patch
> won't apply against the current cvs and I'll need to
> re-sync it and resolve collisions.
I'll give it a go ... So as I'll be current, could you
re-sync it, if it's not too difficult? Alternatively,
if the patch is OK on others (apart from Win32, and
perhaps aix), is it ready to apply, and we'll work
from there?
> I guess all you need to do is to change
> xs/APR/APR/Makefile.PL to collect all .o files from under
> xs/APR and a few selected src/modules/perl/modperl_xxx.o
> and link them statically with APR.so if under win32. (and
> may be some other platforms too (aix comes to mind)).
Just so I understand correctly, in this approach we'll have
one (big) APR.so that has collected all the functionality of
the individual APR::* modules (as well as the old APR.so
itself and selected symbols from modperl_xxx.o)? Or does APR
stay essentially the same (with the added symbols from
selected modperl_xxx.o), and then one links each APR::* with
APR.so?
It should be relatively straightforward to do the latter (as
long as APR.so is built before APR::*). However, with the
former, there'd be problems building the individual APR::*
modules first, to be used as components in building APR.so,
for the same reason that exists now - to build APR::*, one
has to specify the library where the symbols are found, and
one can't specify a library (APR.so) that hasn't been built
yet. This could be resolved in some cases by linking APR::*
against the relevant modperl_xxx.o files; however, for those
that require some functionality within APR.so itself, there
might be a problem ...
> > The only alternative I was able
> > to come up with is to use LoadLibrary/GetProcAddress
> > to set a function pointer to that of a function
> > within a dll. I tried to cut this down to the
> > minimal needed, and came up with something along
> > the lines of, generically,
> >
> > typdef ... /* delare the function pointers */
> >
> > HINSTANCE hlib;
> > if (GetProcAddresses(&hlib, "Some.dll",
> > &fn_1, "func_1",
> > &fn_2, "func_2",
> > ...) {
> > /* the functions are available */
> > }
> > if (hlib != NULL) FreeLibrary(hlib);
> >
> > where GetProcAddresses() is a simple (generic) routine that
> > associates, from Some.dll, func_1, func_2, ... with fn_1,
> > fn_2, ... So, in this approach, for each APR::* as
> > appropriate, necessary function pointers must be declared,
> > GetProcAddresses() is invoked, and finally, if necessary,
> > FreeLibrary() called at the end.
> >
> > However, I don't have enough experience with the build
> > system to compare if the above would be easier or harder to
> > set up and maintain, compared to linking against the
> > appropriate .so files.
>
> The biggest problem I see here, is that we won't be able
> to test whether things still work on windows, every time
> we change or add something. So I'd prefer not to use it.
> If this can be done automatically, without touching the
> existing code, then i guess it's OK. But I'm not quite
> sure this is possible.
That's certainly a concern ... If this is ever
attempted, I think some (most?) of it could be
done somewhat automatically, but maybe it'd be
better to explore the above approach first.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Mon, 10 May 2004, Stas Bekman wrote:
>
>
>>How about a quick workaround as follows: For windows only,
>>link APR.so statically with all APR/Foo.o and the required
>>modperl_foo.o and arrange for the bootstrap not to call it
>>for windows if APR.so is loaded?
>
>
> That sounds good ...
So can you try to tackle that? I guess my latest patch won't apply against the
current cvs and I'll need to re-sync it and resolve collisions.
I guess all you need to do is to change xs/APR/APR/Makefile.PL to collect all
.o files from under xs/APR and a few selected src/modules/perl/modperl_xxx.o
and link them statically with APR.so if under win32. (and may be some other
platforms too (aix comes to mind)).
> The only alternative I was able
> to come up with is to use LoadLibrary/GetProcAddress
> to set a function pointer to that of a function
> within a dll. I tried to cut this down to the
> minimal needed, and came up with something along
> the lines of, generically,
>
> typdef ... /* delare the function pointers */
>
> HINSTANCE hlib;
> if (GetProcAddresses(&hlib, "Some.dll",
> &fn_1, "func_1",
> &fn_2, "func_2",
> ...) {
> /* the functions are available */
> }
> if (hlib != NULL) FreeLibrary(hlib);
>
> where GetProcAddresses() is a simple (generic) routine that
> associates, from Some.dll, func_1, func_2, ... with fn_1,
> fn_2, ... So, in this approach, for each APR::* as
> appropriate, necessary function pointers must be declared,
> GetProcAddresses() is invoked, and finally, if necessary,
> FreeLibrary() called at the end.
>
> However, I don't have enough experience with the build
> system to compare if the above would be easier or harder to
> set up and maintain, compared to linking against the
> appropriate .so files.
The biggest problem I see here, is that we won't be able to test whether
things still work on windows, every time we change or add something. So I'd
prefer not to use it. If this can be done automatically, without touching the
existing code, then i guess it's OK. But I'm not quite sure this is possible.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Mon, 10 May 2004, Stas Bekman wrote:
>
>
>>How about a quick workaround as follows: For windows only,
>>link APR.so statically with all APR/Foo.o and the required
>>modperl_foo.o and arrange for the bootstrap not to call it
>>for windows if APR.so is loaded?
>
>
> That sounds good ...
So can you try to tackle that? I guess my latest patch won't apply against the
current cvs and I'll need to re-sync it and resolve collisions.
I guess all you need to do is to change xs/APR/APR/Makefile.PL to collect all
.o files from under xs/APR and a few selected src/modules/perl/modperl_xxx.o
and link them statically with APR.so if under win32. (and may be some other
platforms too (aix comes to mind)).
> The only alternative I was able
> to come up with is to use LoadLibrary/GetProcAddress
> to set a function pointer to that of a function
> within a dll. I tried to cut this down to the
> minimal needed, and came up with something along
> the lines of, generically,
>
> typdef ... /* delare the function pointers */
>
> HINSTANCE hlib;
> if (GetProcAddresses(&hlib, "Some.dll",
> &fn_1, "func_1",
> &fn_2, "func_2",
> ...) {
> /* the functions are available */
> }
> if (hlib != NULL) FreeLibrary(hlib);
>
> where GetProcAddresses() is a simple (generic) routine that
> associates, from Some.dll, func_1, func_2, ... with fn_1,
> fn_2, ... So, in this approach, for each APR::* as
> appropriate, necessary function pointers must be declared,
> GetProcAddresses() is invoked, and finally, if necessary,
> FreeLibrary() called at the end.
>
> However, I don't have enough experience with the build
> system to compare if the above would be easier or harder to
> set up and maintain, compared to linking against the
> appropriate .so files.
The biggest problem I see here, is that we won't be able to test whether
things still work on windows, every time we change or add something. So I'd
prefer not to use it. If this can be done automatically, without touching the
existing code, then i guess it's OK. But I'm not quite sure this is possible.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
> [...]
>
>
>>I guess all you need to do is to change xs/APR/APR/Makefile.PL to
>>collect all .o files from under xs/APR and a few selected
>>src/modules/perl/modperl_xxx.o and link them statically with APR.so if
>>under win32. (and may be some other platforms too (aix comes to mind)).
>
>
> Before we get into all that, I would like to know why APR::Pool has
> any interaction with modperl's thread-pools. I really don't understand
> why pool cleanup needs to decrement a tipool refcount [*]; why doesn't
> this introduce all kind of refcount-related bugs when mp2 users start
> creating/destroying their own subpools?
>
> If there's a design flaw here, then fixing the design flaw may
> allow us to avoid such platform-specific linking hacks.
>
> [*] ie, all the "#idef USE_ITHREADS" code in APR__Pool.h
The reason it is there is not in a design flow, but the fact that when you
register a cleanup handler, you no longer have control over when it's going to
be run. What you have to ensure is that if you use a pool of interpreters, and
you take one of them to register the cleanup handler, you must not release it
until that cleanup handler has been run. Why? Because it passes SV which is
allocated and lives inside that interpreter, and that SV could be absolutely
anything (huge object). When the cleanup callback is run, you must have that
same interpreter to run it, or things will go boom.
Granted you could try to freeze the SV recursively via Storable and handle
over a frozen struct, and then thaw it before running with any other
interpreter, but it'll be much slower. ALso if you pass an anon code ref,
it'll have to be B::Deparse'd as we do now for all other handlers, which you
want to avoid too.
Second, this issue is really not the reason we are doing what we are doing. If
you look at my patch (in this thread), I simply hacked that in xs/APR/APR/APR.xs:
/* XXX: provide the missing symbol for APR::Pool as a tmp workaround */
#ifndef modperl_interp_unselect
apr_status_t modperl_interp_unselect(void *data);
apr_status_t modperl_interp_unselect(void *data) { return APR_SUCCESS; }
#endif
and there is no more problem. The multiple other dependencies on the modperl_*
files are the problem that win32 has with (and probably aix).
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
> [...]
>
>
>>I guess all you need to do is to change xs/APR/APR/Makefile.PL to
>>collect all .o files from under xs/APR and a few selected
>>src/modules/perl/modperl_xxx.o and link them statically with APR.so if
>>under win32. (and may be some other platforms too (aix comes to mind)).
>
>
> Before we get into all that, I would like to know why APR::Pool has
> any interaction with modperl's thread-pools. I really don't understand
> why pool cleanup needs to decrement a tipool refcount [*]; why doesn't
> this introduce all kind of refcount-related bugs when mp2 users start
> creating/destroying their own subpools?
>
> If there's a design flaw here, then fixing the design flaw may
> allow us to avoid such platform-specific linking hacks.
>
> [*] ie, all the "#idef USE_ITHREADS" code in APR__Pool.h
The reason it is there is not in a design flow, but the fact that when you
register a cleanup handler, you no longer have control over when it's going to
be run. What you have to ensure is that if you use a pool of interpreters, and
you take one of them to register the cleanup handler, you must not release it
until that cleanup handler has been run. Why? Because it passes SV which is
allocated and lives inside that interpreter, and that SV could be absolutely
anything (huge object). When the cleanup callback is run, you must have that
same interpreter to run it, or things will go boom.
Granted you could try to freeze the SV recursively via Storable and handle
over a frozen struct, and then thaw it before running with any other
interpreter, but it'll be much slower. ALso if you pass an anon code ref,
it'll have to be B::Deparse'd as we do now for all other handlers, which you
want to avoid too.
Second, this issue is really not the reason we are doing what we are doing. If
you look at my patch (in this thread), I simply hacked that in xs/APR/APR/APR.xs:
/* XXX: provide the missing symbol for APR::Pool as a tmp workaround */
#ifndef modperl_interp_unselect
apr_status_t modperl_interp_unselect(void *data);
apr_status_t modperl_interp_unselect(void *data) { return APR_SUCCESS; }
#endif
and there is no more problem. The multiple other dependencies on the modperl_*
files are the problem that win32 has with (and probably aix).
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> I guess all you need to do is to change xs/APR/APR/Makefile.PL to
> collect all .o files from under xs/APR and a few selected
> src/modules/perl/modperl_xxx.o and link them statically with APR.so if
> under win32. (and may be some other platforms too (aix comes to mind)).
Before we get into all that, I would like to know why APR::Pool has
any interaction with modperl's thread-pools. I really don't understand
why pool cleanup needs to decrement a tipool refcount [*]; why doesn't
this introduce all kind of refcount-related bugs when mp2 users start
creating/destroying their own subpools?
If there's a design flaw here, then fixing the design flaw may
allow us to avoid such platform-specific linking hacks.
[*] ie, all the "#idef USE_ITHREADS" code in APR__Pool.h
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 10 May 2004, Stas Bekman wrote:
> How about a quick workaround as follows: For windows only,
> link APR.so statically with all APR/Foo.o and the required
> modperl_foo.o and arrange for the bootstrap not to call it
> for windows if APR.so is loaded?
That sounds good ... The only alternative I was able
to come up with is to use LoadLibrary/GetProcAddress
to set a function pointer to that of a function
within a dll. I tried to cut this down to the
minimal needed, and came up with something along
the lines of, generically,
typdef ... /* delare the function pointers */
HINSTANCE hlib;
if (GetProcAddresses(&hlib, "Some.dll",
&fn_1, "func_1",
&fn_2, "func_2",
...) {
/* the functions are available */
}
if (hlib != NULL) FreeLibrary(hlib);
where GetProcAddresses() is a simple (generic) routine that
associates, from Some.dll, func_1, func_2, ... with fn_1,
fn_2, ... So, in this approach, for each APR::* as
appropriate, necessary function pointers must be declared,
GetProcAddresses() is invoked, and finally, if necessary,
FreeLibrary() called at the end.
However, I don't have enough experience with the build
system to compare if the above would be easier or harder to
set up and maintain, compared to linking against the
appropriate .so files.
--
best regards,
randy
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 10 May 2004, Stas Bekman wrote:
> How about a quick workaround as follows: For windows only,
> link APR.so statically with all APR/Foo.o and the required
> modperl_foo.o and arrange for the bootstrap not to call it
> for windows if APR.so is loaded?
That sounds good ... The only alternative I was able
to come up with is to use LoadLibrary/GetProcAddress
to set a function pointer to that of a function
within a dll. I tried to cut this down to the
minimal needed, and came up with something along
the lines of, generically,
typdef ... /* delare the function pointers */
HINSTANCE hlib;
if (GetProcAddresses(&hlib, "Some.dll",
&fn_1, "func_1",
&fn_2, "func_2",
...) {
/* the functions are available */
}
if (hlib != NULL) FreeLibrary(hlib);
where GetProcAddresses() is a simple (generic) routine that
associates, from Some.dll, func_1, func_2, ... with fn_1,
fn_2, ... So, in this approach, for each APR::* as
appropriate, necessary function pointers must be declared,
GetProcAddresses() is invoked, and finally, if necessary,
FreeLibrary() called at the end.
However, I don't have enough experience with the build
system to compare if the above would be easier or harder to
set up and maintain, compared to linking against the
appropriate .so files.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Sun, 9 May 2004, Stas Bekman wrote:
>
>
>>Yes, that sounds like a much better idea. There should be
>>a way to tell the application that certain symbols will be
>>resolved at run-time, and no matter who will provide them
>>(application, another library or else). On AIX the linker
>>is just as picky, but lets you shut up itself by telling
>>it that the missing symbols will be resolved at run time
>>and that it shouldn't worry about it. using the -brtl
>>option (see lib/Apache/Build.pm).
>
>
> There is a link option on VC++ 6, -delayload:some.dll, which
> delays the loading of a dll until a function inside it is
> actually called by an application. But this is used in
> situations like
> if (some_condition_is_true) {
> call_the_dll_function();
> }
> else {
> do_something_else();
> }
> where the dll may not be available on some target machine.
>
> What seems different on Windows compared to Unix, even with
> this delayload thing (which still requires you to link
> against the .lib file corresponding to the relevant .dll),
> is that when you link against a .lib file which resolves
> symbols, information about those symbols appears in the
> result which contains references to the specific dll where
> those symbols appear. What Jan suggested, in some sense, is
> to try to fool Win32 by building, eg, APR.so, in a way to
> make it go by the name of mod_perl.so, by using the same
> .def file for both (and specifying a library name). But this
> doesn't seem to quite work, at least in a simple way.
In short, no go, right?
How about a quick workaround as follows: For windows only, link APR.so
statically with all APR/Foo.o and the required modperl_foo.o and arrange for
the bootstrap not to call it for windows if APR.so is loaded?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Sun, 9 May 2004, Stas Bekman wrote:
>
>
>>Yes, that sounds like a much better idea. There should be
>>a way to tell the application that certain symbols will be
>>resolved at run-time, and no matter who will provide them
>>(application, another library or else). On AIX the linker
>>is just as picky, but lets you shut up itself by telling
>>it that the missing symbols will be resolved at run time
>>and that it shouldn't worry about it. using the -brtl
>>option (see lib/Apache/Build.pm).
>
>
> There is a link option on VC++ 6, -delayload:some.dll, which
> delays the loading of a dll until a function inside it is
> actually called by an application. But this is used in
> situations like
> if (some_condition_is_true) {
> call_the_dll_function();
> }
> else {
> do_something_else();
> }
> where the dll may not be available on some target machine.
>
> What seems different on Windows compared to Unix, even with
> this delayload thing (which still requires you to link
> against the .lib file corresponding to the relevant .dll),
> is that when you link against a .lib file which resolves
> symbols, information about those symbols appears in the
> result which contains references to the specific dll where
> those symbols appear. What Jan suggested, in some sense, is
> to try to fool Win32 by building, eg, APR.so, in a way to
> make it go by the name of mod_perl.so, by using the same
> .def file for both (and specifying a library name). But this
> doesn't seem to quite work, at least in a simple way.
In short, no go, right?
How about a quick workaround as follows: For windows only, link APR.so
statically with all APR/Foo.o and the required modperl_foo.o and arrange for
the bootstrap not to call it for windows if APR.so is loaded?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sun, 9 May 2004, Stas Bekman wrote:
> Yes, that sounds like a much better idea. There should be
> a way to tell the application that certain symbols will be
> resolved at run-time, and no matter who will provide them
> (application, another library or else). On AIX the linker
> is just as picky, but lets you shut up itself by telling
> it that the missing symbols will be resolved at run time
> and that it shouldn't worry about it. using the -brtl
> option (see lib/Apache/Build.pm).
There is a link option on VC++ 6, -delayload:some.dll, which
delays the loading of a dll until a function inside it is
actually called by an application. But this is used in
situations like
if (some_condition_is_true) {
call_the_dll_function();
}
else {
do_something_else();
}
where the dll may not be available on some target machine.
What seems different on Windows compared to Unix, even with
this delayload thing (which still requires you to link
against the .lib file corresponding to the relevant .dll),
is that when you link against a .lib file which resolves
symbols, information about those symbols appears in the
result which contains references to the specific dll where
those symbols appear. What Jan suggested, in some sense, is
to try to fool Win32 by building, eg, APR.so, in a way to
make it go by the name of mod_perl.so, by using the same
.def file for both (and specifying a library name). But this
doesn't seem to quite work, at least in a simple way.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sun, 9 May 2004, Stas Bekman wrote:
> Yes, that sounds like a much better idea. There should be
> a way to tell the application that certain symbols will be
> resolved at run-time, and no matter who will provide them
> (application, another library or else). On AIX the linker
> is just as picky, but lets you shut up itself by telling
> it that the missing symbols will be resolved at run time
> and that it shouldn't worry about it. using the -brtl
> option (see lib/Apache/Build.pm).
There is a link option on VC++ 6, -delayload:some.dll, which
delays the loading of a dll until a function inside it is
actually called by an application. But this is used in
situations like
if (some_condition_is_true) {
call_the_dll_function();
}
else {
do_something_else();
}
where the dll may not be available on some target machine.
What seems different on Windows compared to Unix, even with
this delayload thing (which still requires you to link
against the .lib file corresponding to the relevant .dll),
is that when you link against a .lib file which resolves
symbols, information about those symbols appears in the
result which contains references to the specific dll where
those symbols appear. What Jan suggested, in some sense, is
to try to fool Win32 by building, eg, APR.so, in a way to
make it go by the name of mod_perl.so, by using the same
.def file for both (and specifying a library name). But this
doesn't seem to quite work, at least in a simple way.
--
best regards,
randy
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Fri, 7 May 2004, Stas Bekman wrote:
> [ ... ]
>
>>We want mod_perl_base to be linked statically to APR.so
>>and mod_perl.so (that's what my patch does at the moment,
>>but instead it links 3 .o files). So how do we make
>>windows compiler find the symbols from the base, when
>>building APR:: objects? What we want to tell the compiler
>>that is that the symbols are in mod_perl_base.lib, but
>>they may be found in mod_perl.so or APR.so. Can we do
>>that?
>>
>>Think of APR.so as an equivalent of mod_perl.so, which
>>doesn't require httpd. So for example APR::Pool may find
>>its symbols resoved in mod_perl.so or APR.so depending on
>>which is loaded. Do you think we can arrange such a thing?
>
>
> I think it's possible using function pointers - here's an
> example (if nothing else, for the benefit of the archives :)
[...]
> Apart from the gymnastics of the implementation, does this
> approach sound worth persuing? I guess one advantage here is
> that, for Win32, one has to define just the symbols (as
> function pointers), and then try loading either APR.so or
> mod_perl.so - one doesn't (I think) have to split
> mod_perl.lib up into separate libs, according to whether or
> not ap_ symbols appear.
Thanks for the example, Randy. That sounds like an overkill to me. And a hell
of maintenance.
> I asked Jan Dubois if there was a simpler approach - he
> suggested something just involving manipulating the link
> options and what appears in the .def file, but I can't get
> it to work by just loading one of the dlls ("a" or "b" in
> the above example). I'll look at that more closely, though.
Yes, that sounds like a much better idea. There should be a way to tell the
application that certain symbols will be resolved at run-time, and no matter
who will provide them (application, another library or else). On AIX the
linker is just as picky, but lets you shut up itself by telling it that the
missing symbols will be resolved at run time and that it shouldn't worry about
it. using the -brtl option (see lib/Apache/Build.pm).
So AIX is going to have the same issue, but since now it's told to ignore
unresolved symbols at linking time, it probably will survive this change.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Fri, 7 May 2004, Stas Bekman wrote:
> [ ... ]
>
>>We want mod_perl_base to be linked statically to APR.so
>>and mod_perl.so (that's what my patch does at the moment,
>>but instead it links 3 .o files). So how do we make
>>windows compiler find the symbols from the base, when
>>building APR:: objects? What we want to tell the compiler
>>that is that the symbols are in mod_perl_base.lib, but
>>they may be found in mod_perl.so or APR.so. Can we do
>>that?
>>
>>Think of APR.so as an equivalent of mod_perl.so, which
>>doesn't require httpd. So for example APR::Pool may find
>>its symbols resoved in mod_perl.so or APR.so depending on
>>which is loaded. Do you think we can arrange such a thing?
>
>
> I think it's possible using function pointers - here's an
> example (if nothing else, for the benefit of the archives :)
[...]
> Apart from the gymnastics of the implementation, does this
> approach sound worth persuing? I guess one advantage here is
> that, for Win32, one has to define just the symbols (as
> function pointers), and then try loading either APR.so or
> mod_perl.so - one doesn't (I think) have to split
> mod_perl.lib up into separate libs, according to whether or
> not ap_ symbols appear.
Thanks for the example, Randy. That sounds like an overkill to me. And a hell
of maintenance.
> I asked Jan Dubois if there was a simpler approach - he
> suggested something just involving manipulating the link
> options and what appears in the .def file, but I can't get
> it to work by just loading one of the dlls ("a" or "b" in
> the above example). I'll look at that more closely, though.
Yes, that sounds like a much better idea. There should be a way to tell the
application that certain symbols will be resolved at run-time, and no matter
who will provide them (application, another library or else). On AIX the
linker is just as picky, but lets you shut up itself by telling it that the
missing symbols will be resolved at run time and that it shouldn't worry about
it. using the -brtl option (see lib/Apache/Build.pm).
So AIX is going to have the same issue, but since now it's told to ignore
unresolved symbols at linking time, it probably will survive this change.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 7 May 2004, Stas Bekman wrote:
[ ... ]
> We want mod_perl_base to be linked statically to APR.so
> and mod_perl.so (that's what my patch does at the moment,
> but instead it links 3 .o files). So how do we make
> windows compiler find the symbols from the base, when
> building APR:: objects? What we want to tell the compiler
> that is that the symbols are in mod_perl_base.lib, but
> they may be found in mod_perl.so or APR.so. Can we do
> that?
>
> Think of APR.so as an equivalent of mod_perl.so, which
> doesn't require httpd. So for example APR::Pool may find
> its symbols resoved in mod_perl.so or APR.so depending on
> which is loaded. Do you think we can arrange such a thing?
I think it's possible using function pointers - here's an
example (if nothing else, for the benefit of the archives :)
Suppose one has a function testit(), defined in a.c:
=================================================
// file a.c
#include "a.h"
#include <stdio.h>
void testit(void) {
printf("Bonjour");
}
================================================
with header
===============================================
// file a.h
void testit(void);
===============================================
Making up a def file a.def to define which
symbols to export:
==============================================
LIBRARY
DESCRIPTION 'The a library'
EXPORTS
testit
=============================================
one can then from a.c create a shared library a.dll:
cl -c a.c
link -dll -nodefaultlib ... a.obj -def:a.def -out:a.dll
where "..." specifies various system .lib files.
Making copies a.c -> b.c, a.h -> b.h, and a.def -> b.def,
one can then create a b.dll shared library that also
exports the testit() function.
Now create a 3rd dll c.dll that exports another
function printit(), which uses the testit() function.
If this is done as
========================================================
// file c.c
#include <windows.h>
#include "c.h"
typedef void (CALLBACK* DLLTESTIT)(void);
void printit(void) {
HINSTANCE hDLL; // Handle to DLL
DLLTESTIT testit; // Function pointer
hDLL = LoadLibrary("a");
if (hDLL != NULL) {
testit = (DLLTESTIT)GetProcAddress(hDLL,
"testit");
if (!testit) {
// handle the error
FreeLibrary(hDLL);
}
else {
// call the function
testit();
}
}
else {
hDLL = LoadLibrary("b");
if (hDLL != NULL) {
testit = (DLLTESTIT)GetProcAddress(hDLL,
"testit");
if (!testit) {
// handle the error
FreeLibrary(hDLL);
}
else {
// call the function
testit();
}
}
}
}
========================================================
with header
=======================================================
// file c.h
void printit(void);
=======================================================
and associated .def file
======================================================
LIBRARY
DESCRIPTION 'The c library'
EXPORTS
printit
======================================================
then compiling this as
cl -c c.c
link -dll -nodefaultlib ... c.obj -def:c.def -out:c.dll
will have c.dll exporting printit().
Now consider an application:
====================================================
// file printit.c
#include "c.h"
int main(void) {
printit();
return 0;
}
=====================================================
If this is compiled as
cl printit.c c.lib
then an executable printit.exe will be produced. This
executable needs c.dll to be available (for printit), as
well as one of a.dll or b.dll (for testit).
Apart from the gymnastics of the implementation, does this
approach sound worth persuing? I guess one advantage here is
that, for Win32, one has to define just the symbols (as
function pointers), and then try loading either APR.so or
mod_perl.so - one doesn't (I think) have to split
mod_perl.lib up into separate libs, according to whether or
not ap_ symbols appear.
I asked Jan Dubois if there was a simpler approach - he
suggested something just involving manipulating the link
options and what appears in the .def file, but I can't get
it to work by just loading one of the dlls ("a" or "b" in
the above example). I'll look at that more closely, though.
--
best regards,
randy
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 7 May 2004, Stas Bekman wrote:
[ ... ]
> We want mod_perl_base to be linked statically to APR.so
> and mod_perl.so (that's what my patch does at the moment,
> but instead it links 3 .o files). So how do we make
> windows compiler find the symbols from the base, when
> building APR:: objects? What we want to tell the compiler
> that is that the symbols are in mod_perl_base.lib, but
> they may be found in mod_perl.so or APR.so. Can we do
> that?
>
> Think of APR.so as an equivalent of mod_perl.so, which
> doesn't require httpd. So for example APR::Pool may find
> its symbols resoved in mod_perl.so or APR.so depending on
> which is loaded. Do you think we can arrange such a thing?
I think it's possible using function pointers - here's an
example (if nothing else, for the benefit of the archives :)
Suppose one has a function testit(), defined in a.c:
=================================================
// file a.c
#include "a.h"
#include <stdio.h>
void testit(void) {
printf("Bonjour");
}
================================================
with header
===============================================
// file a.h
void testit(void);
===============================================
Making up a def file a.def to define which
symbols to export:
==============================================
LIBRARY
DESCRIPTION 'The a library'
EXPORTS
testit
=============================================
one can then from a.c create a shared library a.dll:
cl -c a.c
link -dll -nodefaultlib ... a.obj -def:a.def -out:a.dll
where "..." specifies various system .lib files.
Making copies a.c -> b.c, a.h -> b.h, and a.def -> b.def,
one can then create a b.dll shared library that also
exports the testit() function.
Now create a 3rd dll c.dll that exports another
function printit(), which uses the testit() function.
If this is done as
========================================================
// file c.c
#include <windows.h>
#include "c.h"
typedef void (CALLBACK* DLLTESTIT)(void);
void printit(void) {
HINSTANCE hDLL; // Handle to DLL
DLLTESTIT testit; // Function pointer
hDLL = LoadLibrary("a");
if (hDLL != NULL) {
testit = (DLLTESTIT)GetProcAddress(hDLL,
"testit");
if (!testit) {
// handle the error
FreeLibrary(hDLL);
}
else {
// call the function
testit();
}
}
else {
hDLL = LoadLibrary("b");
if (hDLL != NULL) {
testit = (DLLTESTIT)GetProcAddress(hDLL,
"testit");
if (!testit) {
// handle the error
FreeLibrary(hDLL);
}
else {
// call the function
testit();
}
}
}
}
========================================================
with header
=======================================================
// file c.h
void printit(void);
=======================================================
and associated .def file
======================================================
LIBRARY
DESCRIPTION 'The c library'
EXPORTS
printit
======================================================
then compiling this as
cl -c c.c
link -dll -nodefaultlib ... c.obj -def:c.def -out:c.dll
will have c.dll exporting printit().
Now consider an application:
====================================================
// file printit.c
#include "c.h"
int main(void) {
printit();
return 0;
}
=====================================================
If this is compiled as
cl printit.c c.lib
then an executable printit.exe will be produced. This
executable needs c.dll to be available (for printit), as
well as one of a.dll or b.dll (for testit).
Apart from the gymnastics of the implementation, does this
approach sound worth persuing? I guess one advantage here is
that, for Win32, one has to define just the symbols (as
function pointers), and then try loading either APR.so or
mod_perl.so - one doesn't (I think) have to split
mod_perl.lib up into separate libs, according to whether or
not ap_ symbols appear.
I asked Jan Dubois if there was a simpler approach - he
suggested something just involving manipulating the link
options and what appears in the .def file, but I can't get
it to work by just loading one of the dlls ("a" or "b" in
the above example). I'll look at that more closely, though.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Fri, 7 May 2004, Stas Bekman wrote:
>
>
>>Stas Bekman wrote:
>>
>>>Remind me please what is mod_perl.lib? The file with symbols listing?
>>
>>and also show me the actual output where it is used during
>>linking. Thanks.
>
>
> I don't have access to my Win32 machine at the moment, but
> it's used at the link stage:
>
> cl.exe -c ... WhatEver.c
> link C:\Path\to\Apache2\lib\libapr.lib ...
> C:\Path\to\modperl-2.0\...\mod_perl.lib ...
>
> The compilations (cl.exe ...) is fine. With the link to
> mod_perl.lib in there, the symbols get resolved, but via
> mod_perl.lib, so that when you try to use the module (for
> example, in the apr-ext tests) it searches for mod_perl.so,
> and dies if that isn't in the PATH (mod_perl.so is a dll).
> If I take out mod_perl.lib in the link stage, the link
> command dies with an unknown symbol error.
OK, in which case we need to split mod_perl.so into
mod_perl_base.so and mod_perl.so, where the base part includes no ap_ symbols,
and mod_perl.so links against it. So we will have mod_perl_base.lib and
mod_perl.lib. So APR:: objects will link only against mod_perl_base.lib, the
rest will link against both .lib files. From construction point of view, this
is the simplest straightforward solution.
This solution is a big kludge, as we have to stick that _base.(so|lib)
somewhere where the system loader can find it, which sucks, since we don't do
that for any other file at the moment. But the best solution will be something
along these lines.
We want mod_perl_base to be linked statically to APR.so and mod_perl.so
(that's what my patch does at the moment, but instead it links 3 .o files). So
how do we make windows compiler find the symbols from the base, when building
APR:: objects? What we want to tell the compiler that is that the symbols are
in mod_perl_base.lib, but they may be found in mod_perl.so or APR.so. Can we
do that?
Think of APR.so as an equivalent of mod_perl.so, which doesn't require httpd.
So for example APR::Pool may find its symbols resoved in mod_perl.so or APR.so
depending on which is loaded. Do you think we can arrange such a thing?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Fri, 7 May 2004, Stas Bekman wrote:
>
>
>>Stas Bekman wrote:
>>
>>>Remind me please what is mod_perl.lib? The file with symbols listing?
>>
>>and also show me the actual output where it is used during
>>linking. Thanks.
>
>
> I don't have access to my Win32 machine at the moment, but
> it's used at the link stage:
>
> cl.exe -c ... WhatEver.c
> link C:\Path\to\Apache2\lib\libapr.lib ...
> C:\Path\to\modperl-2.0\...\mod_perl.lib ...
>
> The compilations (cl.exe ...) is fine. With the link to
> mod_perl.lib in there, the symbols get resolved, but via
> mod_perl.lib, so that when you try to use the module (for
> example, in the apr-ext tests) it searches for mod_perl.so,
> and dies if that isn't in the PATH (mod_perl.so is a dll).
> If I take out mod_perl.lib in the link stage, the link
> command dies with an unknown symbol error.
OK, in which case we need to split mod_perl.so into
mod_perl_base.so and mod_perl.so, where the base part includes no ap_ symbols,
and mod_perl.so links against it. So we will have mod_perl_base.lib and
mod_perl.lib. So APR:: objects will link only against mod_perl_base.lib, the
rest will link against both .lib files. From construction point of view, this
is the simplest straightforward solution.
This solution is a big kludge, as we have to stick that _base.(so|lib)
somewhere where the system loader can find it, which sucks, since we don't do
that for any other file at the moment. But the best solution will be something
along these lines.
We want mod_perl_base to be linked statically to APR.so and mod_perl.so
(that's what my patch does at the moment, but instead it links 3 .o files). So
how do we make windows compiler find the symbols from the base, when building
APR:: objects? What we want to tell the compiler that is that the symbols are
in mod_perl_base.lib, but they may be found in mod_perl.so or APR.so. Can we
do that?
Think of APR.so as an equivalent of mod_perl.so, which doesn't require httpd.
So for example APR::Pool may find its symbols resoved in mod_perl.so or APR.so
depending on which is loaded. Do you think we can arrange such a thing?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 7 May 2004, Stas Bekman wrote:
> Stas Bekman wrote:
> > Remind me please what is mod_perl.lib? The file with symbols listing?
>
> and also show me the actual output where it is used during
> linking. Thanks.
I don't have access to my Win32 machine at the moment, but
it's used at the link stage:
cl.exe -c ... WhatEver.c
link C:\Path\to\Apache2\lib\libapr.lib ...
C:\Path\to\modperl-2.0\...\mod_perl.lib ...
The compilations (cl.exe ...) is fine. With the link to
mod_perl.lib in there, the symbols get resolved, but via
mod_perl.lib, so that when you try to use the module (for
example, in the apr-ext tests) it searches for mod_perl.so,
and dies if that isn't in the PATH (mod_perl.so is a dll).
If I take out mod_perl.lib in the link stage, the link
command dies with an unknown symbol error.
--
best regards,
randy
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 7 May 2004, Stas Bekman wrote:
> Stas Bekman wrote:
> > Remind me please what is mod_perl.lib? The file with symbols listing?
>
> and also show me the actual output where it is used during
> linking. Thanks.
I don't have access to my Win32 machine at the moment, but
it's used at the link stage:
cl.exe -c ... WhatEver.c
link C:\Path\to\Apache2\lib\libapr.lib ...
C:\Path\to\modperl-2.0\...\mod_perl.lib ...
The compilations (cl.exe ...) is fine. With the link to
mod_perl.lib in there, the symbols get resolved, but via
mod_perl.lib, so that when you try to use the module (for
example, in the apr-ext tests) it searches for mod_perl.so,
and dies if that isn't in the PATH (mod_perl.so is a dll).
If I take out mod_perl.lib in the link stage, the link
command dies with an unknown symbol error.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Remind me please what is mod_perl.lib? The file with symbols listing?
and also show me the actual output where it is used during linking. Thanks.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Thu, 6 May 2004, Stas Bekman wrote:
> Remind me please what is mod_perl.lib? The file with
> symbols listing?
Yes, that's right - in the current context, it's used to
list the symbols that appear in mod_perl.so.
--
best regards,
randy
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Remind me please what is mod_perl.lib? The file with symbols listing?
and also show me the actual output where it is used during linking. Thanks.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Thu, 6 May 2004, Stas Bekman wrote:
> Remind me please what is mod_perl.lib? The file with
> symbols listing?
Yes, that's right - in the current context, it's used to
list the symbols that appear in mod_perl.so.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
Remind me please what is mod_perl.lib? The file with symbols listing?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
Remind me please what is mod_perl.lib? The file with symbols listing?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Thu, 6 May 2004, Stas Bekman wrote:
> Randy Kobes wrote:
> > On Wed, 5 May 2004, Stas Bekman wrote:
> >
> >>I did some more tweaks and this time generated the source
> >>scan. Here is the updated version:
> >>http://apache.org/~stas/apr-ext.patch
> >
> > Thanks for that, Stas! There's a couple of things on
> > Win32 (I'm not sure how specific they are to Win32):
> >
> > - the WriteMakefile sub of ModPerl::BuildMM includes
> > by default linking against $build->modperl_libs.
> > This results in a dependency on mod_perl.so for,
> > eg, APR::Pool. Something like this:
> > ====================================================
> > Index: BuildMM.pm
> > ===================================================================
> > RCS file: /home/cvs/modperl-2.0/lib/ModPerl/BuildMM.pm,v
> > retrieving revision 1.15
> > diff -u -r1.15 BuildMM.pm
> > --- BuildMM.pm 4 Mar 2004 06:01:06 -0000 1.15
> > +++ BuildMM.pm 7 May 2004 05:31:41 -0000
> > @@ -77,7 +77,9 @@
> > }
> > }
> >
> > - my $libs = join ' ', $build->apache_libs, $build->modperl_libs;
> > + my $outside = join '|', qw(APR::Table APR::UUID APR::Pool APR::PerlIO);
> > + my $libs = join ' ', $build->apache_libs,
> > + ($args{NAME} =~ /^$outside$/ ? '' : $build->modperl_libs);
> > my $ccflags = $build->perl_ccopts . $build->ap_ccopts;
> >
> > my @opts = (
> > ====================================================================
> > would avoid this, but ...
>
> Hmm, what kind of dependcy is that? How can I reproduce it?
>
> On linux it doesn't depend on mod_perl.so at the moment:
>
> % ldd blib/arch/Apache2/auto/APR/Pool/Pool.so
> linux-gate.so.1 => (0xffffe000)
> libc.so.6 => /lib/tls/libc.so.6 (0x4001d000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
I'm not sure how to reproduce it on linux, but on Win32,
the equivalent to ldd shows a dependency on mod_perl.so,
when mod_perl.lib is included when linking. I think this
comes about because VC++ finds the missing symbols in
mod_perl.lib, which in this case just tells it how to
get them from mod_perl.so - it doesn't know that these
will be included later in APR.
> > - Even with the above, I get some fatal errors with
> > unresolved symbols; for example, modperl_hash_tie, when
> > building APR::Table. If I understand things correctly, this
> > would get resolved at run time by loading APR, but I'm not
>
> Correct. APR.so has these symbols.
>
> > sure how to tell APR::* at build time that this will be
> > resolved later. One possibility is to do like is done for
> > APR - copy all the necessary src/modules/perl/*.[ch] files
> > to the build directory of the relevant APR::* modules, but
> > this seems like unnecessary duplication. Another possibility
> > is to perhaps just link the APR::* modules against the
> > relevant src/modules/perl/*.o object files that already have
> > been built at this point?
>
> That will explode probably explode everything. If not it'll be horribly
> inefficient, since they aren't shared objects.
>
> Did I mentioned already that windows ... :)
:)
> So, please explain to me and show what does windows do
> when building Pool.o and linking Pool.so. Thanks!
If I leave the linking in to mod_perl.lib, then Pool.o
builds fine, but requires mod_perl.so. If I take out the
linking to mod_perl.lib, then the build fails because
modperl_interp_unselect is missing. This particular problem
can be avoided by copying the workaround in APR.xs to
APR__Pool.h. However, a similar problem arises with
APR::Table - it builds OK when linked against mod_perl.lib,
but this again creates a dependency on mod_perl.so. Removing
mod_perl.lib from the link stage results in a build failure
due to modperl_hash_tied_object not being found (which is in
modperl_common_util.c, but APR::Table doesn't know that this
will come later from APR).
--
best regards, randy
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Thu, 6 May 2004, Stas Bekman wrote:
> Randy Kobes wrote:
> > On Wed, 5 May 2004, Stas Bekman wrote:
> >
> >>I did some more tweaks and this time generated the source
> >>scan. Here is the updated version:
> >>http://apache.org/~stas/apr-ext.patch
> >
> > Thanks for that, Stas! There's a couple of things on
> > Win32 (I'm not sure how specific they are to Win32):
> >
> > - the WriteMakefile sub of ModPerl::BuildMM includes
> > by default linking against $build->modperl_libs.
> > This results in a dependency on mod_perl.so for,
> > eg, APR::Pool. Something like this:
> > ====================================================
> > Index: BuildMM.pm
> > ===================================================================
> > RCS file: /home/cvs/modperl-2.0/lib/ModPerl/BuildMM.pm,v
> > retrieving revision 1.15
> > diff -u -r1.15 BuildMM.pm
> > --- BuildMM.pm 4 Mar 2004 06:01:06 -0000 1.15
> > +++ BuildMM.pm 7 May 2004 05:31:41 -0000
> > @@ -77,7 +77,9 @@
> > }
> > }
> >
> > - my $libs = join ' ', $build->apache_libs, $build->modperl_libs;
> > + my $outside = join '|', qw(APR::Table APR::UUID APR::Pool APR::PerlIO);
> > + my $libs = join ' ', $build->apache_libs,
> > + ($args{NAME} =~ /^$outside$/ ? '' : $build->modperl_libs);
> > my $ccflags = $build->perl_ccopts . $build->ap_ccopts;
> >
> > my @opts = (
> > ====================================================================
> > would avoid this, but ...
>
> Hmm, what kind of dependcy is that? How can I reproduce it?
>
> On linux it doesn't depend on mod_perl.so at the moment:
>
> % ldd blib/arch/Apache2/auto/APR/Pool/Pool.so
> linux-gate.so.1 => (0xffffe000)
> libc.so.6 => /lib/tls/libc.so.6 (0x4001d000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
I'm not sure how to reproduce it on linux, but on Win32,
the equivalent to ldd shows a dependency on mod_perl.so,
when mod_perl.lib is included when linking. I think this
comes about because VC++ finds the missing symbols in
mod_perl.lib, which in this case just tells it how to
get them from mod_perl.so - it doesn't know that these
will be included later in APR.
> > - Even with the above, I get some fatal errors with
> > unresolved symbols; for example, modperl_hash_tie, when
> > building APR::Table. If I understand things correctly, this
> > would get resolved at run time by loading APR, but I'm not
>
> Correct. APR.so has these symbols.
>
> > sure how to tell APR::* at build time that this will be
> > resolved later. One possibility is to do like is done for
> > APR - copy all the necessary src/modules/perl/*.[ch] files
> > to the build directory of the relevant APR::* modules, but
> > this seems like unnecessary duplication. Another possibility
> > is to perhaps just link the APR::* modules against the
> > relevant src/modules/perl/*.o object files that already have
> > been built at this point?
>
> That will explode probably explode everything. If not it'll be horribly
> inefficient, since they aren't shared objects.
>
> Did I mentioned already that windows ... :)
:)
> So, please explain to me and show what does windows do
> when building Pool.o and linking Pool.so. Thanks!
If I leave the linking in to mod_perl.lib, then Pool.o
builds fine, but requires mod_perl.so. If I take out the
linking to mod_perl.lib, then the build fails because
modperl_interp_unselect is missing. This particular problem
can be avoided by copying the workaround in APR.xs to
APR__Pool.h. However, a similar problem arises with
APR::Table - it builds OK when linked against mod_perl.lib,
but this again creates a dependency on mod_perl.so. Removing
mod_perl.lib from the link stage results in a build failure
due to modperl_hash_tied_object not being found (which is in
modperl_common_util.c, but APR::Table doesn't know that this
will come later from APR).
--
best regards, randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Wed, 5 May 2004, Stas Bekman wrote:
>
>
>>I did some more tweaks and this time generated the source
>>scan. Here is the updated version:
>>http://apache.org/~stas/apr-ext.patch
>
>
> Thanks for that, Stas! There's a couple of things on
> Win32 (I'm not sure how specific they are to Win32):
>
> - the WriteMakefile sub of ModPerl::BuildMM includes
> by default linking against $build->modperl_libs.
> This results in a dependency on mod_perl.so for,
> eg, APR::Pool. Something like this:
> ====================================================
> Index: BuildMM.pm
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/lib/ModPerl/BuildMM.pm,v
> retrieving revision 1.15
> diff -u -r1.15 BuildMM.pm
> --- BuildMM.pm 4 Mar 2004 06:01:06 -0000 1.15
> +++ BuildMM.pm 7 May 2004 05:31:41 -0000
> @@ -77,7 +77,9 @@
> }
> }
>
> - my $libs = join ' ', $build->apache_libs, $build->modperl_libs;
> + my $outside = join '|', qw(APR::Table APR::UUID APR::Pool APR::PerlIO);
> + my $libs = join ' ', $build->apache_libs,
> + ($args{NAME} =~ /^$outside$/ ? '' : $build->modperl_libs);
> my $ccflags = $build->perl_ccopts . $build->ap_ccopts;
>
> my @opts = (
> ====================================================================
> would avoid this, but ...
Hmm, what kind of dependcy is that? How can I reproduce it?
On linux it doesn't depend on mod_perl.so at the moment:
% ldd blib/arch/Apache2/auto/APR/Pool/Pool.so
linux-gate.so.1 => (0xffffe000)
libc.so.6 => /lib/tls/libc.so.6 (0x4001d000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
> - Even with the above, I get some fatal errors with
> unresolved symbols; for example, modperl_hash_tie, when
> building APR::Table. If I understand things correctly, this
> would get resolved at run time by loading APR, but I'm not
Correct. APR.so has these symbols.
> sure how to tell APR::* at build time that this will be
> resolved later. One possibility is to do like is done for
> APR - copy all the necessary src/modules/perl/*.[ch] files
> to the build directory of the relevant APR::* modules, but
> this seems like unnecessary duplication. Another possibility
> is to perhaps just link the APR::* modules against the
> relevant src/modules/perl/*.o object files that already have
> been built at this point?
That will explode probably explode everything. If not it'll be horribly
inefficient, since they aren't shared objects.
Did I mentioned already that windows ... :)
So, please explain to me and show what does windows do when building Pool.o
and linking Pool.so. Thanks!
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Wed, 5 May 2004, Stas Bekman wrote:
>
>
>>I did some more tweaks and this time generated the source
>>scan. Here is the updated version:
>>http://apache.org/~stas/apr-ext.patch
>
>
> Thanks for that, Stas! There's a couple of things on
> Win32 (I'm not sure how specific they are to Win32):
>
> - the WriteMakefile sub of ModPerl::BuildMM includes
> by default linking against $build->modperl_libs.
> This results in a dependency on mod_perl.so for,
> eg, APR::Pool. Something like this:
> ====================================================
> Index: BuildMM.pm
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/lib/ModPerl/BuildMM.pm,v
> retrieving revision 1.15
> diff -u -r1.15 BuildMM.pm
> --- BuildMM.pm 4 Mar 2004 06:01:06 -0000 1.15
> +++ BuildMM.pm 7 May 2004 05:31:41 -0000
> @@ -77,7 +77,9 @@
> }
> }
>
> - my $libs = join ' ', $build->apache_libs, $build->modperl_libs;
> + my $outside = join '|', qw(APR::Table APR::UUID APR::Pool APR::PerlIO);
> + my $libs = join ' ', $build->apache_libs,
> + ($args{NAME} =~ /^$outside$/ ? '' : $build->modperl_libs);
> my $ccflags = $build->perl_ccopts . $build->ap_ccopts;
>
> my @opts = (
> ====================================================================
> would avoid this, but ...
Hmm, what kind of dependcy is that? How can I reproduce it?
On linux it doesn't depend on mod_perl.so at the moment:
% ldd blib/arch/Apache2/auto/APR/Pool/Pool.so
linux-gate.so.1 => (0xffffe000)
libc.so.6 => /lib/tls/libc.so.6 (0x4001d000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
> - Even with the above, I get some fatal errors with
> unresolved symbols; for example, modperl_hash_tie, when
> building APR::Table. If I understand things correctly, this
> would get resolved at run time by loading APR, but I'm not
Correct. APR.so has these symbols.
> sure how to tell APR::* at build time that this will be
> resolved later. One possibility is to do like is done for
> APR - copy all the necessary src/modules/perl/*.[ch] files
> to the build directory of the relevant APR::* modules, but
> this seems like unnecessary duplication. Another possibility
> is to perhaps just link the APR::* modules against the
> relevant src/modules/perl/*.o object files that already have
> been built at this point?
That will explode probably explode everything. If not it'll be horribly
inefficient, since they aren't shared objects.
Did I mentioned already that windows ... :)
So, please explain to me and show what does windows do when building Pool.o
and linking Pool.so. Thanks!
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Wed, 5 May 2004, Stas Bekman wrote:
> I did some more tweaks and this time generated the source
> scan. Here is the updated version:
> http://apache.org/~stas/apr-ext.patch
Thanks for that, Stas! There's a couple of things on
Win32 (I'm not sure how specific they are to Win32):
- the WriteMakefile sub of ModPerl::BuildMM includes
by default linking against $build->modperl_libs.
This results in a dependency on mod_perl.so for,
eg, APR::Pool. Something like this:
====================================================
Index: BuildMM.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/BuildMM.pm,v
retrieving revision 1.15
diff -u -r1.15 BuildMM.pm
--- BuildMM.pm 4 Mar 2004 06:01:06 -0000 1.15
+++ BuildMM.pm 7 May 2004 05:31:41 -0000
@@ -77,7 +77,9 @@
}
}
- my $libs = join ' ', $build->apache_libs, $build->modperl_libs;
+ my $outside = join '|', qw(APR::Table APR::UUID APR::Pool APR::PerlIO);
+ my $libs = join ' ', $build->apache_libs,
+ ($args{NAME} =~ /^$outside$/ ? '' : $build->modperl_libs);
my $ccflags = $build->perl_ccopts . $build->ap_ccopts;
my @opts = (
====================================================================
would avoid this, but ...
- Even with the above, I get some fatal errors with
unresolved symbols; for example, modperl_hash_tie, when
building APR::Table. If I understand things correctly, this
would get resolved at run time by loading APR, but I'm not
sure how to tell APR::* at build time that this will be
resolved later. One possibility is to do like is done for
APR - copy all the necessary src/modules/perl/*.[ch] files
to the build directory of the relevant APR::* modules, but
this seems like unnecessary duplication. Another possibility
is to perhaps just link the APR::* modules against the
relevant src/modules/perl/*.o object files that already have
been built at this point?
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Wed, 5 May 2004, Stas Bekman wrote:
> I did some more tweaks and this time generated the source
> scan. Here is the updated version:
> http://apache.org/~stas/apr-ext.patch
Thanks for that, Stas! There's a couple of things on
Win32 (I'm not sure how specific they are to Win32):
- the WriteMakefile sub of ModPerl::BuildMM includes
by default linking against $build->modperl_libs.
This results in a dependency on mod_perl.so for,
eg, APR::Pool. Something like this:
====================================================
Index: BuildMM.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/BuildMM.pm,v
retrieving revision 1.15
diff -u -r1.15 BuildMM.pm
--- BuildMM.pm 4 Mar 2004 06:01:06 -0000 1.15
+++ BuildMM.pm 7 May 2004 05:31:41 -0000
@@ -77,7 +77,9 @@
}
}
- my $libs = join ' ', $build->apache_libs, $build->modperl_libs;
+ my $outside = join '|', qw(APR::Table APR::UUID APR::Pool APR::PerlIO);
+ my $libs = join ' ', $build->apache_libs,
+ ($args{NAME} =~ /^$outside$/ ? '' : $build->modperl_libs);
my $ccflags = $build->perl_ccopts . $build->ap_ccopts;
my @opts = (
====================================================================
would avoid this, but ...
- Even with the above, I get some fatal errors with
unresolved symbols; for example, modperl_hash_tie, when
building APR::Table. If I understand things correctly, this
would get resolved at run time by loading APR, but I'm not
sure how to tell APR::* at build time that this will be
resolved later. One possibility is to do like is done for
APR - copy all the necessary src/modules/perl/*.[ch] files
to the build directory of the relevant APR::* modules, but
this seems like unnecessary duplication. Another possibility
is to perhaps just link the APR::* modules against the
relevant src/modules/perl/*.o object files that already have
been built at this point?
--
best regards,
randy
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
I did some more tweaks and this time generated the source scan. Here is the
updated version: http://apache.org/~stas/apr-ext.patch
there is minor non-fatal issue during Makefile.PL, I'll handle that later.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] getting APR to work w/o modperl
Posted by Stas Bekman <st...@stason.org>.
I did some more tweaks and this time generated the source scan. Here is the
updated version: http://apache.org/~stas/apr-ext.patch
there is minor non-fatal issue during Makefile.PL, I'll handle that later.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com