You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Steve Davis <sj...@mindspring.com> on 2002/12/31 20:52:38 UTC
mod_perl make failed: cannot find -lapr
Your help will be very much appreciated to resolve the following issue.
When attempting to make mod_perl.so, the make script 'almost' makes a
touchdown but fails before getting to the finishing line. Now it is
time get some help from a coach. Hopefully, with a little help, a
touchdown will soon follow. Below, I present was appears to be the
problem, but someone else will have to direct me to the next set of
steps.
I've spend an extensive amount of time trying to resolve this myself and
it needs another set of eyes. The news groups were reviewed
(repeatedly) for assistance, on-line docs, and what available books I
could find.
The environment is RH 8.0, Apache 2.0.43, Perl 5.8.0, mod_perl 1.99_07.
As best as I can tell, Apache, Perl, and mod_perl have been compiled
using the recommended configuration options listed in either Redhat's
instructions or mod_perl's on-line docs. Get care has been taken to try
to dot every one and cross every 't' to my ability.
This problem 'may' have to do with an issue of a change of naming
conventions which were adapted by the apr apache group. Confer with
Stas Bekman's post on Nov 26, 2002 with a title of "Problems compiling
mod_perl 1.99_07 in RH 8.0". He provides a cvs patch; but,
unfortunately, I'm not familiar with using that-as least-as of yet.
(Look's like I might have learn this package real soon.) Are they any
intentions to update the mod_perl-1.99_07.tar.gz? If my conclusion is
correct, then currently, and according to the on-line instructions, the
present tar.gz edition is not compatible to the latest edition of
apache. (2.0.43). So, 'maybe' the cause of my make failure. It appears
as if, only the cvs repository maybe a valid for compiling. If my
analysis is correct, and a new edition of the respective non-cvs files
be acquired somehow.
I confuse my ignorance and lack of familiarity with these packages so I
could be off.
Thank you. Steve
The environment is described below.
Apache has been configured with "--prefix=/etc/httpd
--with-mpm=prefork".
Perl has been configured with "-des -Dusethreads -Doptimize='-g'
-Dusedevel".
The perl Makefile.PL was flagged with "MP_AP_PREFIX=/etc/httpd
MP_INST_APACHE2=1 MP_APXS=/etc/httpd/bin". (I also, attempted to
configure the mod_perl makefile with the MP_APXS which generated the
same error message.)
The details follow below.
Here is excerpt from the screen dump from the make output.
make[1]
: Leaving directory `/usr/src/mod_perl/mod_perl-1.99_07/WrapXS'
make[1]
: Entering directory
`/usr/src/mod_perl/mod_perl-1.99_07/docs/api/mod_perl-2.0'
make[1]
: Leaving directory
`/usr/src/mod_perl/mod_perl-1.99_07/docs/api/mod_perl-2.0'
make[1]
: Entering directory `/usr/src/mod_perl/mod_perl-1.99_07/xs'
make[2]
: Entering directory `/usr/src/mod_perl/mod_perl-1.99_07/xs/APR'
make[3]
: Entering directory `/usr/src/mod_perl/mod_perl-1.99_07/xs/APR/APR'
rm -f
../../../blib/arch/Apache2/auto/APR/APR.so
LD_RUN_PATH="/usr/lib" cc
-shared -L/usr/local/lib APR.o -o ../../../blib/arch/Apache2-lapr
-laprutil
/usr/bin/ld
: cannot find -lapr
collect2
: ld returned 1 exit status
make[3]
: *** [../../../blib/arch/Apache2/auto/APR/APR.so]
Error 1
make[3]
: Leaving directory `/usr/src/mod_perl/mod_perl-1.99_07/xs/APR/APR'
make[2]
: *** [subdirs] Error 2
make[2]
: Leaving directory `/usr/src/mod_perl/mod_perl-1.99_07/xs/APR'
make[1]
: *** [subdirs] Error 2
make[1]: Leaving directory `/usr/src/mod_perl/mod_perl-1.99_07/xs'
m
Here is a list of the files within /etc/httpd/lib.
-rw-r--r-- 1 root root 6996 Dec 30 21:04
apr.exp
-rw-r--r-- 1 root root 3481 Dec 30 21:04
aprutil.exp
-rwxr-xr-x 1 root root 21354 Dec 30 21:01 apxs
-rw-r--r-- 1 root root 2685082 Dec 30 21:03 libapr-0.a
-rw-r--r-- 1 root root 628 Dec 30 21:03
libapr-0.la
lrwxrwxrwx 1 root root 17 Dec 30 01:42
libapr-0.so -> libapr-0.so.0.9.2
lrwxrwxrwx 1 root root 17 Dec 30 01:42
libapr-0.so.0 -> libapr-0.so.0.9.2
-rwxr-xr-x 1 root root 1282063 Dec 30 01:42
libapr-0.so.0.9.2
-rw-r--r-- 1 root root 1425080 Dec 30 21:04
libaprutil-0.a
-rw-r--r-- 1 root root 640 Dec 30 21:04
libaprutil-0.la
lrwxrwxrwx 1 root root 21 Dec 30 01:42
libaprutil-0.so -> libaprutil-0.so.0.9.2
lrwxrwxrwx 1 root root 21 Dec 30 01:42
libaprutil-0.so.0 -> libaprutil-0.so.0.9.2
-rwxr-xr-x 1 root root 765330 Dec 30 01:42
libaprutil-0.so.0.9.2
In case the following can be of any value, here is further info. from
the perl REPORT program. (In this case that would be,
/usr/src/mod_perl/mod_perl-1.99_07/t.)
. Problem Description:
[DESCRIBE THE PROBLEM HERE]
2. Used Components and their Configuration:
*** using
/usr/src/mod_perl/mod_perl-1.99_07/t/../lib/Apache/BuildConfig.pm
*** Makefile.PL options:
MP_APXS => /etc/httpd/bin/apxs
MP_AP_PREFIX => /etc/httpd
MP_GENERATE_XS => 1
MP_INST_APACHE2 => 1
MP_LIBNAME => mod_perl
MP_USE_DSO => 1
MP_USE_STATIC => 1
*** /etc/httpd/bin/httpd -V
Server version: Apache/2.0.43
Server built: Dec 30 2002 21:03:18
Server's Module Magic Number: 20020903:0
Architecture: 32-bit
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT="/etc/httpd"
-D SUEXEC_BIN="/etc/httpd/bin/suexec"
-D DEFAULT_PIDLOG="logs/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="logs/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"
*** /usr/local/bin/perl5.8.0 -V
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=linux, osvers=2.4.18-19.8.0, archname=i686-linux-thread-multi
uname='linux ns1 2.4.18-19.8.0 #1 thu dec 12 05:39:29 est 2002 i686
i686 i386 gnulinux '
config_args='-des -Dusethreads -Doptimize=-g -Dusedevel'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING
-fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/include/gdbm',
optimize='-g',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING
-fno-strict-aliasing -I/usr/include/gdbm'
ccversion='', gccversion='3.2 20020903 (Red Hat Linux 8.0 3.2-7)',
gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil
perllibs=-lnsl -ldl -lm -lpthread -lc -lcrypt -lutil
libc=/lib/libc-2.2.93.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.2.93'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS
USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
Built under linux
Compiled at Dec 30 2002 17:16:58
%ENV:
PERL_LWP_USE_HTTP_10="1"
@INC:
/usr/local/lib/perl5/5.8.0/i686-linux-thread-multi
/usr/local/lib/perl5/5.8.0
/usr/local/lib/perl5/site_perl/5.8.0/i686-linux-thread-multi
/usr/local/lib/perl5/site_perl/5.8.0
/usr/local/lib/perl5/site_perl
Again, thank you for your assistance. It is sincerely appreciated.
RE: mod_perl make failed: cannot find -lapr
Posted by Steve Davis <sj...@mindspring.com>.
Here is an update:
But before I begin, let me say thank you for both Stan Bekman and Randy
Kobes for your assistance. So far, result was both good and bad. The
original issue which I was facing appears to have been resolved.
Unfortunately, yet another problem has been created. Hence, this
problem may branch into a new issue for which I have started a new
newsgroup thread.
I would like to recap the measures which were taken for the benefit of
others. So I'll discuss these points first. This will show what fix
was used in order to resolve the initial problem. Then I'll address the
new development. Refer below section "Still again, another option" to
get the punch line.
Background:
To solve the original problem I was having, it appears as if a new set
of source was needed, or the it might be resolved by acquiring just
incremental changes. I didn't' have a client edition of CVS on my
system, and I was trying to avoid bringing that package online. But I
also can appreciate the difficulty of segregating non-CVS files from the
entire release just to fix the problem I was having. So there seamed to
be merit bringing going through yet another learning curve.
The first set of alternatives:
So, therefore, it looked as if I had two options to choose from 1)
install CVS and get incremental code that way; or, 2) acquire an entire
'bleeding edge' software release. This wouldn't be 1.99_07 but result
in acquiring the work in process edition-which was yet another item I
was trying to avoid.
I did work with CVS to bring it on line. (I did not have a CVS client
established. I acquired the manuals, set up the environment variables,
learned the syntax, etc. I stumbled for a while because I wasn't aware
the package needed to be 'init'(ialized) before it would work. So
although I used the proper command line syntax, it gave me numerous
error messages. I eventually got to the point where the code imported,
and the incremental updates were applied. But regretfully, the
compilation still failed.
The comment I would make about this is having both a CVS and non-CVS
edition of source code available to the public is good. At time it
maybe necessary to get the CVS code but for some this may turn out to be
somewhat of a headache to bring online. Unfortunately, in my case, this
turn out to be yet another rabbit trail.
Yet another alternative was considered:
At one point, to solve my problem, I tried to get another edition of
apr, in the hope it might resolve issues with incompatibilities between
software packages. Perhaps, I could go forward or backward one resolve
to fix problems with the naming conventions.
At least on my own system, conflicts were created with I downloaded the
latest edition of apr. When this was compiled, I was no longer was I
able to recompile apache and the issues with mod_perl compiling were not
resolved. There appears to be a conflict with apache 2.0.43 with
apr-0.9.2. Now things were definitely getting worse. Now web server
was offline too and an important library directory had incompatible
libraries in it. I lost territory.
And I not so sure there is an issue with naming conventions after all,
for I tried to use an earlier edition of apr dating back to august and
it problems still existed. Further, between the different apr
compilations the naming conventions did not change. I could investigate
this further but I am not it would be worth the energy. Changes may
have occurred but not with the source for which I was working with.
Still again, another option:
Then I hunted and pecked for a while for another alternative. (At this
point, I was on a mission. Some minds are like finished cement,
thoroughly mixed and permanently set. I would really like to get this
online.) Finally, I discovered http://cvs.apache.org/snapshots/ and it
was from this resource for which I able to get an easier solution. The
is a different source rather than that found under
http://perl.apache.org/dist/ and provided from
http://perl.apache.org/download/source.html#2_0_Development_Source_Distr
ibution
Finally, a step in the right direction:
I don't know if the is a difference between the distribution source vs.
that found in the CVS source, or it there just happened to be recent
changes (directories/links to these files), but there is a change in the
outcome than what I was first working with. Through this new resource,
I downloaded an entire software release and began to work with that.
Fortunately, I was able to compile mod_perl. Progress at last!
Working with mod_perl 2.0 was definitely better than edition 1.99_07.
The bad news:
But now a new problem has developed-the bad news. When httpd.conf
configured to invoke the new mod_perl module, and when httpd is started,
Apache is generates the following error message "httpd failed. The error
was: Starting httpd: httpd: module "mod_perl.c" is not compatible with
this version of Apache. Please contact the vendor for the correct
version."
[FAILED] I have to comment out the invocation of mod_perl in order to
the web server to work.
A request for more help:
To continue with the football analogy which I started with, after
mod_perl was finally compiled, I thought I was headed for a touchdown.
Maybe, we have headed few yards toward the goal line. But a little more
help is needed to head further towards making a score. I'll start a new
thread for the sake this new problem.
Concluding comment:
For obvious reasons, I think Stan's comment about modify folks that the
last edition of mod_perl requires the respective compatible edition of
apache is an excellent idea. This will avoid a lot of headaches. The
sooner this comment is added to the mod_perl web page, the better.
Steve
____________________________________________
Your help will be very much appreciated to resolve the following issue.
When attempting to make mod_perl.so, the make script 'almost' makes a
touchdown but fails before getting to the finishing line. Now it is
time get some help from a coach. Hopefully, with a little help, a
touchdown will soon follow. Below, I present was appears to be the
problem, but someone else will have to direct me to the next set of
steps.
I've spend an extensive amount of time trying to resolve this myself and
it needs another set of eyes. The news groups were reviewed
(repeatedly) for assistance, on-line docs, and what available books I
could find.
The environment is RH 8.0, Apache 2.0.43, Perl 5.8.0, mod_perl 1.99_07.
As best as I can tell, Apache, Perl, and mod_perl have been compiled
using the recommended configuration options listed in either Redhat's
instructions or mod_perl's on-line docs. Get care has been taken to try
to dot every one and cross every 't' to my ability.
This problem 'may' have to do with an issue of a change of naming
conventions which were adapted by the apr apache group. Confer with
Stas Bekman's post on Nov 26, 2002 with a title of "Problems compiling
mod_perl 1.99_07 in RH 8.0". He provides a cvs patch; but,
unfortunately, I'm not familiar with using that-as least-as of yet.
(Look's like I might have learn this package real soon.) Are they any
intentions to update the mod_perl-1.99_07.tar.gz? If my conclusion is
correct, then currently, and according to the on-line instructions, the
present tar.gz edition is not compatible to the latest edition of
apache. (2.0.43). So, 'maybe' the cause of my make failure. It appears
as if, only the cvs repository may be valid for compiling. If my
analysis is correct, and a new edition of the respective non-cvs files
be acquired, then can non-CVS incremental files be obtained somehow?
I confess my ignorance and lack of familiarity with these packages so I
could be off.
Thank you. Steve
The environment is described below.
Apache has been configured with "--prefix=/etc/httpd
--with-mpm=prefork".
Perl has been configured with "-des -Dusethreads -Doptimize='-g'
-Dusedevel".
The perl Makefile.PL was flagged with "MP_AP_PREFIX=/etc/httpd
MP_INST_APACHE2=1 MP_APXS=/etc/httpd/bin". (I also, attempted to
configure the mod_perl makefile with the MP_APXS which generated the
same error message.)
The details follow below.
Here is excerpt from the screen dump from the make output.
make[1]
: Leaving directory `/usr/src/mod_perl/mod_perl-1.99_07/WrapXS'
make[1]
: Entering directory
`/usr/src/mod_perl/mod_perl-1.99_07/docs/api/mod_perl-2.0'
make[1]
: Leaving directory
`/usr/src/mod_perl/mod_perl-1.99_07/docs/api/mod_perl-2.0'
make[1]
: Entering directory `/usr/src/mod_perl/mod_perl-1.99_07/xs'
make[2]
: Entering directory `/usr/src/mod_perl/mod_perl-1.99_07/xs/APR'
make[3]
: Entering directory `/usr/src/mod_perl/mod_perl-1.99_07/xs/APR/APR'
rm -f
../../../blib/arch/Apache2/auto/APR/APR.so
LD_RUN_PATH="/usr/lib" cc
-shared -L/usr/local/lib APR.o -o ../../../blib/arch/Apache2-lapr
-laprutil
/usr/bin/ld
: cannot find -lapr
collect2
: ld returned 1 exit status
make[3]
: *** [../../../blib/arch/Apache2/auto/APR/APR.so]
Error 1
make[3]
: Leaving directory `/usr/src/mod_perl/mod_perl-1.99_07/xs/APR/APR'
make[2]
: *** [subdirs] Error 2
make[2]
: Leaving directory `/usr/src/mod_perl/mod_perl-1.99_07/xs/APR'
make[1]
: *** [subdirs] Error 2
make[1]: Leaving directory `/usr/src/mod_perl/mod_perl-1.99_07/xs'
m
Here is a list of the files within /etc/httpd/lib.
-rw-r--r-- 1 root root 6996 Dec 30 21:04
apr.exp
-rw-r--r-- 1 root root 3481 Dec 30 21:04
aprutil.exp
-rwxr-xr-x 1 root root 21354 Dec 30 21:01 apxs
-rw-r--r-- 1 root root 2685082 Dec 30 21:03 libapr-0.a
-rw-r--r-- 1 root root 628 Dec 30 21:03
libapr-0.la
lrwxrwxrwx 1 root root 17 Dec 30 01:42
libapr-0.so -> libapr-0.so.0.9.2
lrwxrwxrwx 1 root root 17 Dec 30 01:42
libapr-0.so.0 -> libapr-0.so.0.9.2
-rwxr-xr-x 1 root root 1282063 Dec 30 01:42
libapr-0.so.0.9.2
-rw-r--r-- 1 root root 1425080 Dec 30 21:04
libaprutil-0.a
-rw-r--r-- 1 root root 640 Dec 30 21:04
libaprutil-0.la
lrwxrwxrwx 1 root root 21 Dec 30 01:42
libaprutil-0.so -> libaprutil-0.so.0.9.2
lrwxrwxrwx 1 root root 21 Dec 30 01:42
libaprutil-0.so.0 -> libaprutil-0.so.0.9.2
-rwxr-xr-x 1 root root 765330 Dec 30 01:42
libaprutil-0.so.0.9.2
In case the following can be of any value, here is further info. from
the perl REPORT program. (In this case that would be,
/usr/src/mod_perl/mod_perl-1.99_07/t.)
. Problem Description:
[DESCRIBE THE PROBLEM HERE]
2. Used Components and their Configuration:
*** using
/usr/src/mod_perl/mod_perl-1.99_07/t/../lib/Apache/BuildConfig.pm
*** Makefile.PL options:
MP_APXS => /etc/httpd/bin/apxs
MP_AP_PREFIX => /etc/httpd
MP_GENERATE_XS => 1
MP_INST_APACHE2 => 1
MP_LIBNAME => mod_perl
MP_USE_DSO => 1
MP_USE_STATIC => 1
*** /etc/httpd/bin/httpd -V
Server version: Apache/2.0.43
Server built: Dec 30 2002 21:03:18
Server's Module Magic Number: 20020903:0
Architecture: 32-bit
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT="/etc/httpd"
-D SUEXEC_BIN="/etc/httpd/bin/suexec"
-D DEFAULT_PIDLOG="logs/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="logs/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"
*** /usr/local/bin/perl5.8.0 -V
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=linux, osvers=2.4.18-19.8.0, archname=i686-linux-thread-multi
uname='linux ns1 2.4.18-19.8.0 #1 thu dec 12 05:39:29 est 2002 i686
i686 i386 gnulinux '
config_args='-des -Dusethreads -Doptimize=-g -Dusedevel'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING
-fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/include/gdbm',
optimize='-g',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING
-fno-strict-aliasing -I/usr/include/gdbm'
ccversion='', gccversion='3.2 20020903 (Red Hat Linux 8.0 3.2-7)',
gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil
perllibs=-lnsl -ldl -lm -lpthread -lc -lcrypt -lutil
libc=/lib/libc-2.2.93.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.2.93'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS
USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
Built under linux
Compiled at Dec 30 2002 17:16:58
%ENV:
PERL_LWP_USE_HTTP_10="1"
@INC:
/usr/local/lib/perl5/5.8.0/i686-linux-thread-multi
/usr/local/lib/perl5/5.8.0
/usr/local/lib/perl5/site_perl/5.8.0/i686-linux-thread-multi
/usr/local/lib/perl5/site_perl/5.8.0
/usr/local/lib/perl5/site_perl
Again, thank you for your assistance. It is sincerely appreciated.
RE: [OT] Redirect POST to POST off-site?
Posted by Rob Bloodgood <ro...@empire2.com>.
(sorry about the blank reply a minute ago)
> I am looking into the more advanced paypal instant notification
> stuff for the next version of my sw, but version one is using a
> simpler approach to get it out the door. Even that paypal sw
> wouldn't solve my problem, which is to make sure that the POST to
> paypal actually matches the transaction that the user has built up.
I found IPN to be *very* simple to use, logging the notifications to a DB
and then acting as required. I would even be happy to send you my
notification script, which uses Apache::Registry but is really just a simple
POST BACK to paypal and when the response is 'OK', take the appropriate
action (payment received, account terminated, etc) (but please reply
privately if you want it).
The only nits I experienced were A) forgetting to send back the "OK\r\n" to
paypal that they expect to see from a successful notify. They called me and
wondered if my script was broken... B) having to set up a unique index on my
logging table on the "verify_sign" field, because in spite of the correct
response chain, paypal has a tendency to notify repeatedly and redundantly.
HTH!
L8r,
Rob
Redirect POST to POST off-site?
Posted by George Valpak <gv...@yahoo.com>.
Possibly off topic but I am not sure....
I have a page that contains a payment button for paypal which is essentially a form that gets POST'ed to paypal's https server.
I would like to do some processing on my end when the user clicks on that form.
My config is Apace 1.3.2x, MP 1.2x, Apache::Registry (all very recent but don't have the numbers handy here).
My idea is to replace the action on the form to point to my (non-https) web server, do my processing, and then redirect the request to paypal via 307.
My research seems to turn up that the appropriate RFC says the browser "MUST" confirm such a redirect with the user, which is no good for me on the server end (although I understand why on the client side).
I don't want to proxy the paypal server because:
- it seems like a security issue, even if I use https
- it probably violates paypal TOS
If it doesn't violate the TOS, I suppose I could just proxy the PayPal landing page and let paypal handle it from there. But I am hoping for a easier solution... any ideas?
I am looking into the more advanced paypal instant notification stuff for the next version of my sw, but version one is using a simpler approach to get it out the door. Even that paypal sw wouldn't solve my problem, which is to make sure that the POST to paypal actually matches the transaction that the user has built up.
GV
Re: mod_perl make failed: cannot find -lapr
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Tue, 31 Dec 2002, Steve Davis wrote:
>
>
>>Your help will be very much appreciated to resolve the
>>following issue. When attempting to make mod_perl.so, the make
>>script 'almost' makes a touchdown but fails before getting to
>>the finishing line. Now it is time get some help from a coach.
>>Hopefully, with a little help, a touchdown will soon follow.
>>Below, I present was appears to be the problem, but someone
>>else will have to direct me to the next set of steps.
>
> [ .. ]
>
>>This problem 'may' have to do with an issue of a change of
>>naming conventions which were adapted by the apr apache group.
>>Confer with Stas Bekman's post on Nov 26, 2002 with a title of
>>"Problems compiling mod_perl 1.99_07 in RH 8.0". He provides a
>>cvs patch; but, unfortunately, I'm not familiar with using
>>that-as least-as of yet. (Look's like I might have learn this
>>package real soon.) Are they any intentions to update the
>>mod_perl-1.99_07.tar.gz? If my conclusion is correct, then
>>currently, and according to the on-line instructions, the
>>present tar.gz edition is not compatible to the latest edition
>>of apache. (2.0.43). So, 'maybe' the cause of my make failure.
>>It appears as if, only the cvs repository maybe a valid for
>>compiling. If my analysis is correct, and a new edition of the
>>respective non-cvs files be acquired somehow.
>
>
> It might be easier to obtain the whole mod_perl 2.0 sources
> via cvs, rather than patching - this is described at
> http://perl.apache.org/download/source.html#2_0_Development_Source_Distribution
> You likely have a cvs client already, so it's a matter of
> changing to an appropriate directory and doing
>
> % cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic login
> % cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic co modperl-2.0
Or you can use the cvs snapshots tarballs, linked from the same URL
Randy provided.
1.99_08 should be released RSN. I will make sure that it will state in
the README file which Apache version it will work with.
__________________________________________________________________
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: mod_perl make failed: cannot find -lapr
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 31 Dec 2002, Steve Davis wrote:
> Your help will be very much appreciated to resolve the
> following issue. When attempting to make mod_perl.so, the make
> script 'almost' makes a touchdown but fails before getting to
> the finishing line. Now it is time get some help from a coach.
> Hopefully, with a little help, a touchdown will soon follow.
> Below, I present was appears to be the problem, but someone
> else will have to direct me to the next set of steps.
[ .. ]
> This problem 'may' have to do with an issue of a change of
> naming conventions which were adapted by the apr apache group.
> Confer with Stas Bekman's post on Nov 26, 2002 with a title of
> "Problems compiling mod_perl 1.99_07 in RH 8.0". He provides a
> cvs patch; but, unfortunately, I'm not familiar with using
> that-as least-as of yet. (Look's like I might have learn this
> package real soon.) Are they any intentions to update the
> mod_perl-1.99_07.tar.gz? If my conclusion is correct, then
> currently, and according to the on-line instructions, the
> present tar.gz edition is not compatible to the latest edition
> of apache. (2.0.43). So, 'maybe' the cause of my make failure.
> It appears as if, only the cvs repository maybe a valid for
> compiling. If my analysis is correct, and a new edition of the
> respective non-cvs files be acquired somehow.
It might be easier to obtain the whole mod_perl 2.0 sources
via cvs, rather than patching - this is described at
http://perl.apache.org/download/source.html#2_0_Development_Source_Distribution
You likely have a cvs client already, so it's a matter of
changing to an appropriate directory and doing
% cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic login
% cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic co modperl-2.0
--
best regards,
randy kobes
RE: mod_perl make failed: cannot find -lapr
Posted by Dale Lancaster <da...@123hire.com>.
I want to raise my hand on this one too. I went and downloaded, compiled
and built and received the exact same problem on RedHat 8.0 with the same
versin of perl and mod_perl (no surprise). But I just don't have the time
or expertise to track down the exact reason by libapr.so isn't around or
being built. But I did want to add to the issue that its more than just you
:-)
dale
-----Original Message-----
From: Steve Davis [mailto:sjdavis@mindspring.com]
Sent: Tuesday, December 31, 2002 2:53 PM
To: modperl@perl.apache.org
Subject: mod_perl make failed: cannot find -lapr
Your help will be very much appreciated to resolve the following issue.
When attempting to make mod_perl.so, the make script 'almost' makes a
touchdown but fails before getting to the finishing line. Now it is
time get some help from a coach. Hopefully, with a little help, a
touchdown will soon follow. Below, I present was appears to be the
problem, but someone else will have to direct me to the next set of
steps.
I've spend an extensive amount of time trying to resolve this myself and
it needs another set of eyes. The news groups were reviewed
(repeatedly) for assistance, on-line docs, and what available books I
could find.
The environment is RH 8.0, Apache 2.0.43, Perl 5.8.0, mod_perl 1.99_07.
As best as I can tell, Apache, Perl, and mod_perl have been compiled
using the recommended configuration options listed in either Redhat's
instructions or mod_perl's on-line docs. Get care has been taken to try
to dot every one and cross every 't' to my ability.
This problem 'may' have to do with an issue of a change of naming
conventions which were adapted by the apr apache group. Confer with
Stas Bekman's post on Nov 26, 2002 with a title of "Problems compiling
mod_perl 1.99_07 in RH 8.0". He provides a cvs patch; but,
unfortunately, I'm not familiar with using that-as least-as of yet.
(Look's like I might have learn this package real soon.) Are they any
intentions to update the mod_perl-1.99_07.tar.gz? If my conclusion is
correct, then currently, and according to the on-line instructions, the
present tar.gz edition is not compatible to the latest edition of
apache. (2.0.43). So, 'maybe' the cause of my make failure. It appears
as if, only the cvs repository maybe a valid for compiling. If my
analysis is correct, and a new edition of the respective non-cvs files
be acquired somehow.
I confuse my ignorance and lack of familiarity with these packages so I
could be off.
Thank you. Steve
The environment is described below.
Apache has been configured with "--prefix=/etc/httpd
--with-mpm=prefork".
Perl has been configured with "-des -Dusethreads -Doptimize='-g'
-Dusedevel".
The perl Makefile.PL was flagged with "MP_AP_PREFIX=/etc/httpd
MP_INST_APACHE2=1 MP_APXS=/etc/httpd/bin". (I also, attempted to
configure the mod_perl makefile with the MP_APXS which generated the
same error message.)
The details follow below.
Here is excerpt from the screen dump from the make output.
make[1]
: Leaving directory `/usr/src/mod_perl/mod_perl-1.99_07/WrapXS'
make[1]
: Entering directory
`/usr/src/mod_perl/mod_perl-1.99_07/docs/api/mod_perl-2.0'
make[1]
: Leaving directory
`/usr/src/mod_perl/mod_perl-1.99_07/docs/api/mod_perl-2.0'
make[1]
: Entering directory `/usr/src/mod_perl/mod_perl-1.99_07/xs'
make[2]
: Entering directory `/usr/src/mod_perl/mod_perl-1.99_07/xs/APR'
make[3]
: Entering directory `/usr/src/mod_perl/mod_perl-1.99_07/xs/APR/APR'
rm -f
../../../blib/arch/Apache2/auto/APR/APR.so
LD_RUN_PATH="/usr/lib" cc
-shared -L/usr/local/lib APR.o -o ../../../blib/arch/Apache2-lapr
-laprutil
/usr/bin/ld
: cannot find -lapr
collect2
: ld returned 1 exit status
make[3]
: *** [../../../blib/arch/Apache2/auto/APR/APR.so]
Error 1
make[3]
: Leaving directory `/usr/src/mod_perl/mod_perl-1.99_07/xs/APR/APR'
make[2]
: *** [subdirs] Error 2
make[2]
: Leaving directory `/usr/src/mod_perl/mod_perl-1.99_07/xs/APR'
make[1]
: *** [subdirs] Error 2
make[1]: Leaving directory `/usr/src/mod_perl/mod_perl-1.99_07/xs'
m
Here is a list of the files within /etc/httpd/lib.
-rw-r--r-- 1 root root 6996 Dec 30 21:04
apr.exp
-rw-r--r-- 1 root root 3481 Dec 30 21:04
aprutil.exp
-rwxr-xr-x 1 root root 21354 Dec 30 21:01 apxs
-rw-r--r-- 1 root root 2685082 Dec 30 21:03 libapr-0.a
-rw-r--r-- 1 root root 628 Dec 30 21:03
libapr-0.la
lrwxrwxrwx 1 root root 17 Dec 30 01:42
libapr-0.so -> libapr-0.so.0.9.2
lrwxrwxrwx 1 root root 17 Dec 30 01:42
libapr-0.so.0 -> libapr-0.so.0.9.2
-rwxr-xr-x 1 root root 1282063 Dec 30 01:42
libapr-0.so.0.9.2
-rw-r--r-- 1 root root 1425080 Dec 30 21:04
libaprutil-0.a
-rw-r--r-- 1 root root 640 Dec 30 21:04
libaprutil-0.la
lrwxrwxrwx 1 root root 21 Dec 30 01:42
libaprutil-0.so -> libaprutil-0.so.0.9.2
lrwxrwxrwx 1 root root 21 Dec 30 01:42
libaprutil-0.so.0 -> libaprutil-0.so.0.9.2
-rwxr-xr-x 1 root root 765330 Dec 30 01:42
libaprutil-0.so.0.9.2
In case the following can be of any value, here is further info. from
the perl REPORT program. (In this case that would be,
/usr/src/mod_perl/mod_perl-1.99_07/t.)
. Problem Description:
[DESCRIBE THE PROBLEM HERE]
2. Used Components and their Configuration:
*** using
/usr/src/mod_perl/mod_perl-1.99_07/t/../lib/Apache/BuildConfig.pm
*** Makefile.PL options:
MP_APXS => /etc/httpd/bin/apxs
MP_AP_PREFIX => /etc/httpd
MP_GENERATE_XS => 1
MP_INST_APACHE2 => 1
MP_LIBNAME => mod_perl
MP_USE_DSO => 1
MP_USE_STATIC => 1
*** /etc/httpd/bin/httpd -V
Server version: Apache/2.0.43
Server built: Dec 30 2002 21:03:18
Server's Module Magic Number: 20020903:0
Architecture: 32-bit
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT="/etc/httpd"
-D SUEXEC_BIN="/etc/httpd/bin/suexec"
-D DEFAULT_PIDLOG="logs/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="logs/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"
*** /usr/local/bin/perl5.8.0 -V
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=linux, osvers=2.4.18-19.8.0, archname=i686-linux-thread-multi
uname='linux ns1 2.4.18-19.8.0 #1 thu dec 12 05:39:29 est 2002 i686
i686 i386 gnulinux '
config_args='-des -Dusethreads -Doptimize=-g -Dusedevel'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING
-fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/include/gdbm',
optimize='-g',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING
-fno-strict-aliasing -I/usr/include/gdbm'
ccversion='', gccversion='3.2 20020903 (Red Hat Linux 8.0 3.2-7)',
gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil
perllibs=-lnsl -ldl -lm -lpthread -lc -lcrypt -lutil
libc=/lib/libc-2.2.93.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.2.93'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS
USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
Built under linux
Compiled at Dec 30 2002 17:16:58
%ENV:
PERL_LWP_USE_HTTP_10="1"
@INC:
/usr/local/lib/perl5/5.8.0/i686-linux-thread-multi
/usr/local/lib/perl5/5.8.0
/usr/local/lib/perl5/site_perl/5.8.0/i686-linux-thread-multi
/usr/local/lib/perl5/site_perl/5.8.0
/usr/local/lib/perl5/site_perl
Again, thank you for your assistance. It is sincerely appreciated.