[SEMI-OT] perl_tie_hash valid reference?

[dorian]

greetings all,

i was wondering if anyone could tell me if the function perl_tie_hash
in perl_util.c in the mod_perl 1.27 source could be considered
usual reference material for binding a table-like object to a
hash(ref) in XS? if not, perchance someone could point me at some
literature (or source) on the subject?

thanks in advance,

.dorian

gaining access to config directives of other modules

[dorian]

i know Apache::Module can get at all the installed modules and their
directives, and even the spec of those directives, but what about the
actual values of those directives? i notice Apache::Module is old, but
i don't see anything else out there that looks like it will come close
to doing the job.

insight is welcome.

.dorian

Apache::Module installation issues

[dorian]

i'm not sure that this is an actual problem with Apache::Module itself, but
it seems to stem from mod_perl distribution's mod_perl.h here:

#ifdef PERL_THREADS
#define _INCLUDE_APACHE_FIRST
#endif

#ifdef _INCLUDE_APACHE_FIRST
#include apache_inc.h
#endif

the perl i built against was the stock debian/i386/unstable 5.8.0 which has 
ithreads built in, although i had similar results with a source-built copy
on solaris9/sparc. the mod_perl version is 1.27. i found that if i explicitly
prepended the include for apache_inc.h in the xs, the module appeared to build 
successfully.

strangely enough, the -DPERL_THREADS was being passed into the build, which
to my knowledge should have activated the include but i suppose i must be
missing something. i notice that the module hasn't been updated since 1999,
is there a replacement for its functionality that i don't know about?

cheers,

.dorian

Re: Apache::Module installation issues

[dorian]

 I don't remember what was the outcome of the patch I've posted a long time 
 ago. I sent it after having the same problem.

ah, so it's actually a problem with the mod_perl distribution then?

i'm actually curious as to where apache_inc.h is supposed to be included,
if threads aren't defined.

.dorian

Re: Apache::Request incompatible with CGI ?

[dorian]

 I downloaded Apache::Request from CPAN and I have version 0.31. My C
 compiler is gcc 2.96

aiya. libapreq 0.31 is the one that likes to append whatever it is that
one just uploaded to it to its heap until it starves your machine of memory,
if i recall correctly. it was fixed in 0.31_03 i believe but it looks like 
1.1 was released last week. 

.dorian

Re: coredump with 3 PerlSetVars

[dorian]

On Mon, Feb 03, 2003 at 11:16:25AM -0600, Hann, Brian wrote:
 I wish that was an option, but unfortunately it's not due to the extreme
 amount of applications we would have to test and we don't have the
 manpower or time for that.

of course, by posting to this list, you have just made any would-be trawler
who happens across this information aware that the bank you work for is 
running a deprecated and insecure web server on a production machine (that 
appears to have some sort of e-banking interface?) and have no intention to
fix it. even if your server is changerooted i'd imagine you'd still need to
access things like database auth credentials and ssl private keys. can you
really afford the man-hours of labour that would be generated if those 
were compromised?

 I actually think the REAL problem is some sort of spacing/whitespace
 issue in the conf file.  I'm going to test a few more things and then
 I'll post the results.

quite possibly. you could always go through three and a half years of 
changelogs to see if that particular bug was fixed.

.dorian

mod_perl/1.27 Makefile.PL issue on sparcv9-64/gcc3.2.1

[dorian]

ignore if this has been mentioned already.

my installation of perl picked up on an assembler flag, -Wa,-xarch=v9, which
gets messed with in the mod_perl 1.27 Makefile.PL line 524:

$PERL_EXTRA_CFLAGS = join( , split(,,  $PERL_EXTRA_CFLAGS));

i'm afraid i'm far too sleep-deprived to see why it would be necessary to have
that there, but installation seems to work fine with that line commented out.

.dorian