Re: Function crypt, doesn't work fine with mod_perl for win32 :(
I downloaded this patch so I can execute the next program out the
mod_perl.
$perl -w
my $pass_crypt = crypt("hola","ui");
print $pass_crypt ."\n";
$
But, when Apache::AuthenDBI use this function, apache show me the error
down mentioned.
The problem is that I have not compiled correctly the DLL .How must
built the dll??
Thanks
Epi
Matt Sergeant wrote:
No, it's just not shipped with the standard source code for win32. You need
to download a small patch. See README.win32 in the perl source code archive.
On Tue, 21 Dec 1999, epi wrote:
When I use the Apache::AuthenDBI the apache server generate the next
error:
=
[Tue Dec 21 11:54:12 1999] [error] [Tue Dec 21 11:54:12 1999] nul: The
crypt() function is unimplemented due to excessive paranoia. at
c:\perl\site\5.00503\lib/Apache/AuthenDBI.pm line 186.
=
But, I built the perl with this function, and when i use this function
out mod_perl, the perl doesn't generate this error.
How I must compile the PerlModule.dll to include this function inside
mod_perl
My machine:
Windows NT40 SP5
Apache1.3.9
Mod_perl_1.21
Perl:
Summary of my perl5 (5.0 patchlevel 5 subversion 03) configuration:
Platform:
osname=MSWin32, osvers=4.0, archname=MSWin32-x86
uname=''
hint=recommended, useposix=true, d_sigaction=undef
usethreads=undef useperlio=undef d_sfio=undef
Compiler:
cc='cl.exe', optimize='-O2 -MD -DNDEBUG', gccversion=
cppflags='-DWIN32'
ccflags ='-O2 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT
-DHAVE_DES_FCRYPT '
stdchar='char', d_stdstdio=define, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
alignbytes=8, usemymalloc=n, prototype=define
Linker and Libraries:
ld='link', ldflags ='-nologo -nodefaultlib -release -machine:x86'
libpth=\lib
libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib
netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib
odbc32.lib odbccp32.lib PerlCRT.lib
libc=PerlCRT.lib, so=dll, useshrplib=yes, libperl=perl.lib
Dynamic Linking:
dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -release
-machine:x86'
Characteristics of this binary (from libperl):
Built under MSWin32
Compiled at Dec 20 1999 16:54:40
@INC:
c:\perl\5.00503\lib/MSWin32-x86
c:\perl\5.00503\lib
C:\perl\5.00503\lib/MSWin32-x86
C:\perl\5.00503\lib
C:\perl\site\5.00503\lib/MSWin32-x86
C:\perl\site\5.00503\lib
c:\perl\site\5.00503\lib/MSWin32-x86
c:\perl\site\5.00503\lib
--
Matt/
Details: FastNet Software Ltd - XML, Perl, Databases.
Tagline: High Performance Web Solutions
Web Sites: http://come.to/fastnet http://sergeant.org
Available for Consultancy, Contracts and Training.
mod_perl and module versions
Hello everyone, I have just started to play with mod_perl module I found a problem with my own modules (many versions of the module with the same name) I have found related topic dated on 28 Apr 97 (mod_perl and module versions), but unfortunatelly there was no solution... ;-( Lets say I have two directories : /cgi-bin/dir1 i /cgi-bin/dir2 and in every of them I have module conf.pm (configuration module). Of course the first using one of the module causes cache'ying it by mod_perl (using Apache::Registry or Apache::PerlRun). When I use 'use conf' from the other dir it sees the first included by perl_mod conf module (because it is present in global %INC) How can I force own namespace (including %INC) in every dir (application) ? BTW Merry X-mas and happy Y2K ;o) Best Regards, Waldek Grudzien _ http://www.uhc.lublin.pl/~waldekg/ University Health Care Lublin/Lubartow, Poland tel. +48 81 44 111 88 ICQ # 20441796
Re: mod_perl and module versions
Hi, WHy not just put each conf module in it's own namespace? Dir1::Conf and Dir2::Conf, for example. Then, you could stick them into a single lib directory, and not have to worry about modifying @INC or caching issues. Another option is to ensure that each script has a 'use lib' at the beginning that has it's own conf.pm in it, but not the other scripts, although this solution might only help with scripts running under Apache::PerlRun. darren Waldek Grudzien ([EMAIL PROTECTED]) wrote: Hello everyone, I have just started to play with mod_perl module I found a problem with my own modules (many versions of the module with the same name) I have found related topic dated on 28 Apr 97 (mod_perl and module versions), but unfortunatelly there was no solution... ;-( Lets say I have two directories : /cgi-bin/dir1 i /cgi-bin/dir2 and in every of them I have module conf.pm (configuration module). Of course the first using one of the module causes cache'ying it by mod_perl (using Apache::Registry or Apache::PerlRun). When I use 'use conf' from the other dir it sees the first included by perl_mod conf module (because it is present in global %INC) How can I force own namespace (including %INC) in every dir (application) ? BTW Merry X-mas and happy Y2K ;o) Best Regards, Waldek Grudzien _ http://www.uhc.lublin.pl/~waldekg/ University Health Care Lublin/Lubartow, Poland tel. +48 81 44 111 88 ICQ # 20441796 -- My reality check just bounced.
RFC: modperl sourcegarden discussions and logo design
Hello, gang This is to announce you that we have started a new round of discussions about mod_perl sourcegarden and source garden in general, talking about tools, future, logos and etc. This is your chance to influence, especially regarding logo issues, before it gets copyrighted The logo teasers: http://sourcegarden.org/sourcegardenlogos.png http://sourcegarden.org/sourcegardenlogos2.png http://www.sourcegarden.org/prototype/index.html Subscribe interactively at http://list.sourcegarden.org/mailman/listinfo/modperl or send a message to [EMAIL PROTECTED] with subscribe word in the body. To post to the list please use the [EMAIL PROTECTED] email address. Read and reply to the latest posts from: http://list.sourcegarden.org/pipermail/modperl/ *** *** Please DO NOT reply to this message, as it's offtopic here. *** *** Instead send email to [EMAIL PROTECTED]!*** *** Thank you for caring! Happy Xmas! ___ Stas Bekmanmailto:[EMAIL PROTECTED] http://www.stason.org/stas Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC perl.apache.orgmodperl.sourcegarden.org perlmonth.comperl.org single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com
Re: can't load Apache::DBI in starup.pl file
On Tue, 21 Dec 1999, Nancy Lin wrote: Hi - I'm running apache 1.3.9/modperl 1.19/ApacheDBI-0.87/perl5.003 on redhat 6.0 In my startup.pl file, I have the following lines: use Apache::DBI; $Apache::DBI::DEBUG = 2; When I run it w/ the -c option, I get the following error message: Can't locate object method "module" via package "Apache" at /usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 202. BEGIN failed--compilation aborted at startup.pl line 35. One possible reason may be i'm using the apache-1.3.9-4.i386.rpm from redhat. The archives mentions that the default rpm for redhat 6.1 doesn't work. However, I couldn't find anything on the 6.0 rpms. Has anyone have any problem w/ 6.0's rpm? I would rather not compile the server myself if I don't need to. i have mod_perl compiled (not RPM's) on two different servers, and i see this message, too, when running perl -cw on my modules. however, it doesn't not prevent me from restarting my servers. i just have to run "./apachectl configtest" to really find my coding errors, which is kind of a pain. i just recently noticed this message happening, but i can't recall exactly what changed to bring it about. ky
Re: [Re: [Re: again - more then one PerlTransHandler]]
I believe this should be reflected in the documentation. Because after reading Eagle book one gets absolutely different understanding. It doesn't diffirentiate Perl stacked handlers and Apache handlers. From Doug's words (and from practice :) those are slightly different in the way how their return codes are treated. BTW. Do I understand it correctly now that if my PERL handler returns either OK or DECLINED then the next PERL handler (if any) for this phase will be called anyway, but Apache "native" handlers will be called depending on what is the phase. Ie. for URL translation the "native" handler will be called only if last Perl handler returned DECLINED. Andrei On Tue, Dec 21, 1999 at 01:45:40PM -0800, Doug MacEachern wrote: At least that's what I thought ! In fact now Apache lets me use more then one PerlTransHandler, but it doesn't care of what is the return codes are!!! Even I return OK, it still calls next registered handlers. Really weird! mod_perl does care. but, mod_perl stacked handlers are not quite the same as Apache C handlers. unless the return status from a Perl handler is something other than OK or DECLINED, mod_perl propagates the status code of the last handler run back up to Apache. originally, stacked handlers were introduced for chaining multiple content handlers. if the OK status from the first handler was propagated back to Apache, there would be no chain, and little use for stacked handlers. you can always override this behavior by using a single Perl*Handler which decides what path to take based on the return status, or use a PerlDispatchHandler, or PerlDirectiveHandlers, to name a few. --
SegFaults caused by Apache::Cookie during ChildExit
I am using a home-baked session manager on my web site. I clean up expired sessions by called a child exit handlder and this all worked rather well. However, we have recompiled Perl, Apache, mod_perl and Perl modules with pgcc and a different configuration (removed all modules we didn't need), and now I get a SegFault when Apache::Cookie-new is called during a ChildExit. I use Apache::Cookie in Authorization and PerlHandler phases without a problem. Not sure whether this problem is caused by the compiler or the different configuration at compile. Any ideas of starting points? Thanks Clint
[Embperl] Bareword not allowed !
Hi all, and hi Gerald, I'm narrowing the problem down, from the previous post where I had mistakenly thought Execute would return true upon success. What I've found so far is : - The server is running Embperl as CGI - When it finds a statement looking like HTML::Embperl::DOC::someSub; it will die, saying that barewords are not allowed when the strict pragma is in use. - HTML::Embperl::DOC::someSub has been declared in a file thats been Executed with the import flag set to 1. - If I change the line to HTML::Embperl::DOC::someSub(); my problems are gone. That's what I'm doing now. - It's not consistent across files, that is, some files have all their calls to subroutines without parenthesis and not a warning is issued. - On the other hand, once a file dies, it dies quoting every 'wrong' call to subroutines. Maybe it's clear to you. It certainly looks vodoo to me :) Maybe the difference has to do with compiled and not-yet-compiled code. I don't really know. Ah, by the way, 'use strict' is only explicitly called inside the [! !] constructs where the subs are declared. And [$var $] is in use in each and every file. Is all this sensible? martin -- -- To understand recursion, one must first understand recursion. -- -- - Martin Langhoff @ S C I M Multimedia Technology - - http://www.scim.net | God is real until - - mailto:[EMAIL PROTECTED] | declared integer -
Re: Problems with dynamically-loaded perl modules under Solaris2.5.1
Dan Rench wrote: On Tue, 21 Dec 1999, Doug MacEachern wrote: this sounds an awful lot like the common solaris linker vs. gnu linker problem. what does 'perl -V:ld' say your linker is? make sure it's gnu (gcc) and that Apache is using the same. $ perl -V:ld ld='gcc'; What I don't understand is that when I "./Configure" perl it always says: NOTE: You are using GNU ld(1). GNU ld(1) will not build Perl. I'm arranging to use /usr/ccs/bin/ld by including -B/usr/ccs/bin/ in your gcc -B/usr/ccs/bin/ command. (Note that the trailing "/" is required.) This is exactly the same problem I experienced before I got libperl.so solution to work. ...so it tells me that it can't use GNU ld, and then does it anyway, apparently. Perl's Configure script also warns me that my GNU make has its set-GID bit set and I should remove it. So I "chmod 755 make". Then I get: *** WHOA THERE!!! *** Your C compiler "gcc -B/usr/ccs/bin/ -B/usr/ccs/bin/" doesn't seem to be working! You'd better start hunting for one and let me know about it. This topic is veering away from mod_perl (though the problem only manifests itself under mod_perl for me), so I'm going back to the libperl.so solution suggested earlier since that seems to work. Whatever the problem is, it appears to be fixed in the development version of Perl at least. -- Eugene Miretskiy [EMAIL PROTECTED] InVision, INC. (516) 543-1000x219 http://www.invision.net
Re: [Embperl] Bareword not allowed !
When it finds a statement looking like
HTML::Embperl::DOC::someSub;
it will die, saying that barewords are not allowed when the
strict pragma is in use.
That's what strict does. This same behavior is observed under straight
perl (i.e. without using mod_perl or Embperl).
{
no strict;
sub;# ok # same as sub(@_);
sub; # ok # same as sub(@_);
sub(); # ok
sub(); # ok # same as sub();
}
{
use strict;
sub;# not ok # same as sub(@_);
sub; # ok # same as sub(@_);
sub(); # ok
sub(); # ok # same as sub();
}
ELB
--
Eric L. Brine | Chicken: The egg's way of making more eggs.
[EMAIL PROTECTED] | Do you always hit the nail on the thumb?
ICQ# 4629314 | An optimist thinks thorn bushes have roses.
Re: mod_perl and Mac OS X Server
Oh, yeh, I had fought mod_perl on MOSX long and hard and did finally win...only to switch to linux a month later. anyway, here's what you need to do: 1. if you haven't installed the sources off the Developer CD, do so now. 2. in /System/Library/Perl/rhapsody/Config.pm remove all occurrences of -arch i386 3. in /System/Library/Perl/rhapsody/Config.pm add '-I /System/Library/Frameworks/Perl.framework/Versions/5.005/Headers' to PERL_INC I think this should do it, if not let me know, I might have missed something. Cheers Dmitry At 11:26 AM 12/22/99 , jason wrote: I've been trying for days to build mod_perl for Mac OS X Server. Whether I attempt to build a DSO module, or build mod_perl into Apache, I always receive this error:
trouble reading query string
i'm currently converting several CGI scripts into mod_perl modules, and
i'm having difficulty in one particular situation reading the variable
input (i.e., query string on a GET or STDIN on POST). quick background: i
had a PerlHandler on the end of this request for a while, accepting input
like "/foo?arg1=xarg2=y" which would create a form w/posted data
(including binary info like .png, .gif, .jpg, and .mp3), save that data
and return a user to a location. that was in the early stages of
developing this. i'm now incorporating a more realistic shell around my
dynamic output, one that show our ads which are proxy calls to a netscape
ad server.
my solution was to create a basic HTML page that has a simple perl sub on
it, like so:
!--File: foo.shtml --
html
head
title My Dynamic Page /title
/head
body
!--#AD CALL --
!--#perl sub="Foo::Bar" --
!--#MORE AD CALLS --
/body
/html
a user gets to this page by clicking on a link like this:
"/foo.shtml?arg1=xarg2=y". my module starts off like this:
my $r = shift;
$r = $r-is_main ? $r : $r-main;
my %args = ($r-method_number == M_GET) ? $r-args : $r-content;
but when i went from having the PerlHandler doing everything to having the
module being called like an SSI call, %args doesn't get populated anymore.
so i tried a hack i've done before with CGI.pm, like this:
unless (%args) {
my $q = CGI-new;
my @names = $q-param;
$args{$_} = $q-param($_) for @names;
}
but now, even this doesn't work, so i've had to put one more hack in, like
this:
unless (%args) {
my $original_request = $r-the_request;
my ($query_string) = ($original_request =~ m/\?(.*?)\s+HTTP.*/);
my $q = CGI-new($query_string);
my @names = $q-param;
$args{$_} = $q-param($_) for @names;
}
so it now works, but i feel kinda dirty. and here's the last bit of
strangeness: i have another page that is generated in the same manner
that works just fine. the only difference is that the perl sub generates
a form that is *not* enctype="multipart/form-data". both forms do,
however, POST their data.
any ideas why things are behaving so strangely? is my hack as
objectionable as i think it is?
ky
Re: trouble reading query string
At 11:52 AM 12/22/99 , Ken Y. Clark wrote: so it now works, but i feel kinda dirty. and here's the last bit of strangeness: i have another page that is generated in the same manner that works just fine. the only difference is that the perl sub generates a form that is *not* enctype="multipart/form-data". both forms do, however, POST their data. I'm not sure if I completely understand the problem at hand, but part of it, I think, is in trying to use $r-content with multipart/form-data data encoding. $r-content only works with application/x-www-form-urlencoded data (see the documentation for Apache.pm). To retrieve POSTed data in a multipart format you need to use $r-read or Apache::Request (see the docs for details). Cheers Dmitry
Re: mod_perl and Mac OS X Server
Oh, yeh, I had fought mod_perl on MOSX long and hard and did finally win...only to switch to linux a month later. I wish I could ;) anyway, here's what you need to do: 1. if you haven't installed the sources off the Developer CD, do so now. 2. in /System/Library/Perl/rhapsody/Config.pm remove all occurrences of -arch i386 3. in /System/Library/Perl/rhapsody/Config.pm add '-I /System/Library/Frameworks/Perl.framework/Versions/5.005/Headers' to PERL_INC I think this should do it, if not let me know, I might have missed something. Did all of that, but I still receive an error. I didn't find PERL_INC in Config.pm, but it was in the mod_perl Makefile with the proper path. This is the new error: *** Cut *** === modules/standard === modules/standard === modules/perl === modules/perl === modules cc -c -I./os/unix -I./include -DMAC_OS_X_SERVER -DMOD_PERL -DUSE_HSREGEX -DUS E_EXPAT -I./lib/expat-lite -DMOD_PERL modules.c cc -c -I./os/unix -I./include -DMAC_OS_X_SERVER -DMOD_PERL -DUSE_HSREGEX -DUS E_EXPAT -I./lib/expat-lite -DMOD_PERL buildmark.c cc -DMAC_OS_X_SERVER -DMOD_PERL -DUSE_HSREGEX -DUSE_EXPAT -I./lib/expat-lit e -D MOD_PERL\ -o httpd buildmark.o modules.o modules/perl/libperl.a modules/standard/lib standard.a main/libmain.a ./os/unix/libos.a ap/libap.a regex/libregex.a lib/expa t-lite/libexpat.a `perl /usr/local/src/mod_perl-1.21/src/modules/perl/ldopts ` -arch ppc /System/Library/Perl/rhapsody/auto/DynaLoader/DynaLoader.a Note (probably harmless): No library found for -lperl /usr/bin/ld: Undefined symbols: _PL_endav _PL_envgv _PL_errgv _PL_incgv _PL_markstack_max *** Cut *** _Perl_save_I32 _perl_get_hv _Perl_mess _Perl_saferealloc _Perl_savepv make[1]: *** [target_static] Error 1 make: *** [apache_httpd] Error 2 Any other solutions as to where to head? Thanks for your first tips -- they got it to compile farther than before! Jason
