Re: [PHP] `AM_PROG_LIBTOOL' not found in library
Do a 'which libtool' and I'd hazard a guess that it'll find the one in /usr/local/bin first. As it's using that libtool (dir: /usr/local/bin) and your normal automake (dir: /usr/bin), the dirs don't match and aclocal fails, as the warning mentions. Either switch your path around to move /usr/local/bin after /usr/bin (and end up using the libtool your system came with), or reconfigure and reinstall libtool 1.3.5 starting with "./configure --prefix=/usr" which will cause it to install into /usr/bin, /usr/share, etc. (otherwise it defaults to /usr/local which is likely the problem you have right now). Pablo Sabatino wrote: > > Hello!! > I am using php4-cvs on Linux Suse 6.4. > I issued the command ./buildconf and got a message: > > pablo@pablito:~/php4 > ./buildconf > buildconf: checking installation... > buildconf: autoconf version 2.13 (ok) > buildconf: automake version 1.4 (ok) > buildconf: libtool version 1.3.5 (ok) > > > WARNING: automake and libtool are installed in different >directories. This may cause aclocal to fail. >continuing anyway > aclocal: configure.in: 810: macro `AM_PROG_LIBTOOL' not found in library > make[1]: *** [aclocal.m4] Error 1 > make: *** [all] Error 2 > pablo@pablito:~/php4 > > > pablo@pablito:~/php4 > whereis libtool > libtool: /usr/bin/libtool /usr/local/bin/libtool /usr/share/libtool > pablo@pablito:~/php4 > whereis automake > automake: /usr/bin/automake /usr/share/automake > pablo@pablito:~/php4 > whereis automake > automake: /usr/bin/automake /usr/share/automake > pablo@pablito:~/php4 > > > I installed libtool-1.3.5. > Help me, please!! > Pablo Sabatino.. -- - Kelly Cochran <[EMAIL PROTECTED]> Technical Staff - funschool.com Corporation -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] `AM_PROG_LIBTOOL' not found in library
Ok, now I have no idea. I'd suggest grabbing the latest RC or waiting for the release at this point. CVS versions require a bunch of tools to generate files (autoconf, libtool, etc.). The RC and releases come with the generated files. There appears to be some odd problem with you build environment. What it is, I don't know. Pablo Sabatino wrote: > > I deleted php4 and downladed the software again from the cvs and compiled > it. > This is the error message when executed ./make > > gmake: *** [zend_language_parser.c] Violación de segmento > pablo@pablito:~/php4/Zend > cd .. > pablo@pablito:~/php4 > gmake > Making all in Zend > gmake[1]: Entering directory `/home/pablo/php4/Zend' > bison -y -p zend -v -d ./zend_language_parser.y -o zend_language_parser.c > gmake[1]: *** [zend_language_parser.c] Violación de segmento > gmake[1]: Leaving directory `/home/pablo/php4/Zend' > gmake: *** [all-recursive] Error 1 > pablo@pablito:~/php4 > > > The version bison is: 1.28 and this messages is from ./configure [args] > The system operating is SUSE 6.4. > > Configuring Zend > checking bison version... 1.28 (ok) > checking for limits.h... (cached) yes > checking for malloc.h... yes > checking for string.h... (cached) yes > checking for unistd.h... (cached) yes > checking for stdarg.h... (cached) yes > checking for sys/types.h... (cached) yes > checking for signal.h... (cached) yes > checking for unix.h... (cached) no > checking for dlfcn.h... yes > checking for size_t... (cached) yes > checking return type of signal handlers... void > checking for dlopen in -ldl... (cached) yes > checking for dlopen... (cached) yes > checking for uint... yes > checking for ulong... yes > checking for vprintf... (cached) yes > checking for 8-bit clean memcmp... yes > checking for working alloca.h... (cached) yes > checking for alloca... (cached) yes > checking for memcpy... (cached) yes > checking for strdup... (cached) yes > checking for getpid... yes > checking for kill... yes > checking for strtod... yes > checking for strtol... yes > checking for finite... yes > checking for fpclass... no > checking whether sprintf is broken... (cached) no > checking for finite... (cached) yes > checking for isfinite... no > checking for isinf... yes > checking for isnan... yes > checking whether fp_except is defined... no > checking whether to enable experimental ZTS... no > checking whether to enable inline optimization for GCC... no > checking whether to enable a memory limit... no > checking whether to enable Zend debugging... no > checking for inline... inline > > what the matter??? > Could resolve it? > > Please, help me! > > Thanks pablo! > > > From: "Kelly Cochran" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Thursday, April 19, 2001 6:41 PM > > Subject: Re: [PHP] `AM_PROG_LIBTOOL' not found in library > > > > > > You'll likely have to do a make distclean in the root PHP dir as well. > > Without that, make is probably finding the zend_ini_parser.c that your > > old bison created from zend_ini_parser.y, and therefore doesn't > > regenerate it. Or you could probably also simply 'touch > > Zend/zend_ini_parser.y' and that should also cause make to regen the .c > > file. Either that, or you could simply nuke the whole dir, and checkout > > from CVS again doing the './buildconf; ./configure ; make' cycle > > again. -- - Kelly Cochran <[EMAIL PROTECTED]> Technical Staff - funschool.com Corporation -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Payflow, story continued
John Donagher wrote: > > If anyone has worked around the deficiencies, great; I just haven't received a > v3 SDK yet (and my company's account has not yet been converted) so I can't > speak intelligently about what may be missing from the extension. > > As far as I know, the interface remains untouched, which means the work that > will need to be done will likely be minimal. Looks like the PN*() funcs all became pfpro*(). They also split the connection and process call into a context creator and a processing call. This can be just thrown in the middle of the existing pfpro_process[_raw]() funcs, which is how I managed to get it to compile, but never managed to get it to a testable phase as their 3.x SDK is threaded, and they sent me the 2.x SDK before I got around to working around that issue. Cleaner implementation would be to expose the additional step to PHP with default context selection, ala the MySQL default db handles, but that's beyond my tinkering skills with PHP extensions at the moment. I'll be happy to send what I have to whomever is most likely to end up doing the 3.x extension. Just let me know. -- - Kelly Cochran <[EMAIL PROTECTED]> Technical Staff - funschool.com Corporation -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] is CURL right for SSL post to payment processing Authenticate.net
I was doing this a while back with Authorize.net and using cURL with PHP let me ditch the C CGI I had been using to accomplish this. Not quite as clear-cut a solution as something like the PayFlow extension, but it's quite doable. Main gotcha is having to compile cURL against the same SSL libs as were linked into the webserver (Stronghold in this case) if you're not using PHP as a CGI. Tom Beidler wrote: > > I'm wondering if anyone has experience using CURL and could advise if it's > the best direction for creating a SSL to a payment processing service. > > I'm trying to connect an existing PHP form to a payment processing service > called Authorize.net. Using there direct response method requires a Secure > Socket which a thought meant to send from a secure form to their secure > script which didn't work. Here's what I got from their tech support. > > "The problem is that you can't send an HTML form POST when using Direct > Response. You must write a script that creates an SSL connection directly > with our server (port 443) and send the information to us through that > connection. I do not know if this is possible through PHP but usually this > is done with PERL, CGI, or ColdFusion. Please refer to the Developer's guide > for more information: > > https://secure.authorize.net/docs > > Thank you for contacting our customer service group." > > I found some info about CURL, http://curl.haxx.se/, and it seems like it > might do the trick. I was wondering if anyone has experience with this a can > confirm that this is the best approach or give me some other direction. > > Thanks, > Tom -- - Kelly Cochran <[EMAIL PROTECTED]> Technical Staff - funschool.com Corporation -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
