php-tuxedo-development Mailing List for BEA Tuxedo module for PHP (Page 2)
Status: Pre-Alpha
Brought to you by:
cdog1977
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(10) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(7) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
|
Apr
(10) |
May
(4) |
Jun
(2) |
Jul
(5) |
Aug
(9) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Brian F. <bf...@vi...> - 2002-08-26 04:48:19
|
I believe this could be the source of your problem. (If and only IF you are using Tuxedo >=3D 7.1) Another user found this same problem a while ago, and I'm real sorry I haven't found time to get it in a patch or new release. Just been so busy. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://edocs.beasys.com/tuxedo/tux80/atmi/pbthr13.htm "To join an application, a multithreaded Workstation client must always c= all=20 tpinit(3c) with the TPMULTICONTEXTS flag set, even if the client is runni= ng=20 in single-context mode." This looks like a new flag that I don't have a predefined value for, so add something like this to php_tuxedo.c and then use it in the flags: REGISTER_LONG_CONSTANT("TUX_TPMULTICONTEXTS", TPMULTICONTEXTS, CONSTANT_F= LAG); =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This user was using Tuxedo 8.0 and it fixed his problem,=20 but would probably be the same for 7.1. If you are using 6.5 this is probably NOT your problem. Add this define to php_tuxedo.c (where all the other similar defines are) and then add TUX_TPMULTICONTEXTS to the flags of tux_tpinit. If this fixes your problem, sorry I haven't gotten around to getting a new version to fix this published. Let me know if this helps. Brian On Sunday 25 August 2002 11:18 pm, you wrote: > HI,Sir: > I have some problem in write the program. When i > used php program to connect the tuxedo services after > many times , the tux_tpinit(null,null,null,0) always > thrown the errors. And wait a miniute,the errors no > display. > My php client program used functions are : > tux_tpinit(null,null,null,0) > tux_tpcall("service",fml_buff,$fm_buff,1) > tux_tpfree(fml_buff) > tux_tpterm() > Are the errors relation with the threads. Could you > tell me? > > Thands > > --- Brian Foddy <bf...@vi...> wrote: > > Those libraries are provided in the Tuxedo package, > > not included with php-tuxedo or Redhat. If you > > don't > > have the Tuxedo libraries and header files for your > > platform, it will not work. > > > > Brian > > > > On Thu, 8 Aug 2002, Tom Stone wrote: > > > I have configured php more than 10 times.But it > > > > was > > > > > not included tuxedo modules. And then removed the > > > libnwi.so;libnws.so;libgp.so libraries,the > > > > configure > > > > > is ok. But when i configed the apache sever,the > > > > errors > > > > > was shown. What's the matter? And could you tell > > > > me > > > > > what are the three > > > libraries:libnwi.so;libnws.so;libgp.so. I can not > > > > find > > > > > them in RedHat 6.2. > > > Thanks. > > > > > > --- Brian Foddy <bf...@vi...> wrote: > > > > I have seen some times when buildconf will not > > > > pick > > > > > > up the > > > > new tuxedo/config.m4 file because it uses a > > > > date/time check similar > > > > to "make" looking for new files. Many times > > > > simply > > > > > > touch tuxedo/config.m4 (or equiv depending on > > > > what > > > > > > dir you are in) > > > > > > > > will correct the problem, then re-run the > > > > buildconf > > > > > > and > > > > configure. There is a couple lines of output in > > > > the > > > > > > configure > > > > script about Tuxedo, if you don't see those, its > > > > not > > > > > > including the > > > > module. > > > > > > > > Brian > > > > > > > > On Thu, 8 Aug 2002, CheolMin Lee wrote: > > > > > The information about your problem is > > > > insufficient > > > > > > so that I'm only > > > > > > > > > guessing it. > > > > > Can you provide some output from configure or > > > > make > > > > > > where the error is > > > > > > > > > occurred? > > > > > > > > > > On Wed, Aug 07, 2002 at 10:49:54PM -0700, Tom > > > > > > > > Stone wrote: > > > > > > sure,i used buildconf commnad,but problem > > > > was > > > > > > not > > > > > > > > > > resolved. And i did not found the follow the > > > > > > > > lib: > > > > > > libnwi.so > > > > > > libnws.so > > > > > > libgp.so > > > > > > > > > > > > > > > > > > --- CheolMin Lee > > > > <cm...@us...> > > > > > > wrote: > > > > > > > On Mon, Aug 05, 2002 at 01:21:28AM -0700, > > > > > > > > jackliu > > > > > > > > > > > wrote: > > > > > > > > I use php-tuxedo module 0.4.1 in php > > > > 4.2.2, > > > > > > but > > > > > > > > > > > when i > > > > > > > > > > > > > > > configure the php,can not include > > > > ext/tuxedo > > > > > > > > > subdir. And > > > > > > > > > > > > > > > found some errors in > > > > ext/tuxedo/config.m4 > > > > > > file,the > > > > > > > > > > > follows > > > > > > > > > > > > > > > files not found. > > > > > > > > PHP_ADD_LIBRARY(nwi) libnwi.so > > > > > > > > PHP_ADD_LIBRARY(nws) libnws.so > > > > > > > > PHP_ADD_LIBRARY(gp) libgp.so > > > > > > > > > > > > > > > > Could you tell me why? And how to > > > > resolve > > > > > > the > > > > > > > > > > > problems? > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > Best Regards. > > > > > > > > > > > > > > Did you re-build configure.in? > > > > > > > php-tuxedo is not built-in php extension > > > > so > > > > > > you must > > > > > > > > > > > re-build > > > > > > > configure.in by 'buildconf' script to use > > > > > > > php-tuxedo. > > > > > > > > > > > > > > README.EXT_SKEL in PHP's source will help > > > > you. > > > > > > :) > > > > : > > > > > > > -- > > > > > > > CheolMin Lee <cmlee @ > > > > users.sourceforge.net> > > > > > > <cmlee > > > > > > > > > > > @ kt.co.kr> > > > > > > > Homepage: http://tclab.kaist.ac.kr/~cmlee/ > > > > __________________________________________________ > > > > > > > > Do You Yahoo!? > > > > > > HotJobs - Search Thousands of New Jobs > > > > > > http://www.hotjobs.com > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > HotJobs - Search Thousands of New Jobs > > > http://www.hotjobs.com > > __________________________________________________ > Do You Yahoo!? > Yahoo! Finance - Get real-time stock quotes > http://finance.yahoo.com |
From: Brian D. <br...@tp...> - 2002-08-09 04:34:56
|
Attached are two the my config.m4 file and config.WithTuxedo, which is the configure script I use for PHP4.2.1 with Tuxedo 8.0 It's been working real well for several months for me. Enjoy. At 09:06 AM 8/9/2002 +0900, CheolMin Lee wrote: >:) > >On Thu, Aug 08, 2002 at 11:55:44AM -0500, Brian Foddy wrote: > > Those libraries are provided in the Tuxedo package, > >Tom, Tuxedo is commercial. >You may download trial version for RedHat. Check the following >link: > >http://commerce.bea.com/downloads/tuxedo.jsp > >Good luck. > > > not included with php-tuxedo or Redhat. If you don't > > have the Tuxedo libraries and header files for your > > platform, it will not work. > > > > Brian > > > > On Thu, 8 Aug 2002, Tom Stone wrote: > > > > > I have configured php more than 10 times.But it was > > > not included tuxedo modules. And then removed the > > > libnwi.so;libnws.so;libgp.so libraries,the configure > > > is ok. But when i configed the apache sever,the errors > > > was shown. What's the matter? And could you tell me > > > what are the three > > > libraries:libnwi.so;libnws.so;libgp.so. I can not find > > > them in RedHat 6.2. > > > Thanks. > > > > > > --- Brian Foddy <bf...@vi...> wrote: > > > > I have seen some times when buildconf will not pick > > > > up the > > > > new tuxedo/config.m4 file because it uses a > > > > date/time check similar > > > > to "make" looking for new files. Many times simply > > > > > > > > touch tuxedo/config.m4 (or equiv depending on what > > > > dir you are in) > > > > > > > > will correct the problem, then re-run the buildconf > > > > and > > > > configure. There is a couple lines of output in the > > > > configure > > > > script about Tuxedo, if you don't see those, its not > > > > including the > > > > module. > > > > > > > > Brian > > > > > > > > > > > > On Thu, 8 Aug 2002, CheolMin Lee wrote: > > > > > > > > > The information about your problem is insufficient > > > > so that I'm only > > > > > guessing it. > > > > > Can you provide some output from configure or make > > > > where the error is > > > > > occurred? > > > > > > > > > > On Wed, Aug 07, 2002 at 10:49:54PM -0700, Tom > > > > Stone wrote: > > > > > > sure,i used buildconf commnad,but problem was > > > > not > > > > > > resolved. And i did not found the follow the > > > > lib: > > > > > > libnwi.so > > > > > > libnws.so > > > > > > libgp.so > > > > > > > > > > > > > > > > > > --- CheolMin Lee <cm...@us...> > > > > wrote: > > > > > > > On Mon, Aug 05, 2002 at 01:21:28AM -0700, > > > > jackliu > > > > > > > wrote: > > > > > > > > I use php-tuxedo module 0.4.1 in php 4.2.2, > > > > but > > > > > > > when i > > > > > > > > configure the php,can not include ext/tuxedo > > > > > > > subdir. And > > > > > > > > found some errors in ext/tuxedo/config.m4 > > > > file,the > > > > > > > follows > > > > > > > > files not found. > > > > > > > > PHP_ADD_LIBRARY(nwi) libnwi.so > > > > > > > > PHP_ADD_LIBRARY(nws) libnws.so > > > > > > > > PHP_ADD_LIBRARY(gp) libgp.so > > > > > > > > > > > > > > > > Could you tell me why? And how to resolve > > > > the > > > > > > > problems? > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > Best Regards. > > > > > > > > > > > > > > > > > > > > > > Did you re-build configure.in? > > > > > > > php-tuxedo is not built-in php extension so > > > > you must > > > > > > > re-build > > > > > > > configure.in by 'buildconf' script to use > > > > > > > php-tuxedo. > > > > > > > > > > > > > > README.EXT_SKEL in PHP's source will help you. > > > > :) > > > > > > > > > > > > > > -- > > > > > > > CheolMin Lee <cmlee @ users.sourceforge.net> > > > > <cmlee > > > > > > > @ kt.co.kr> > > > > > > > Homepage: http://tclab.kaist.ac.kr/~cmlee/ > > > > > > > > > > > > > > > > > > > > > > __________________________________________________ > > > > > > Do You Yahoo!? > > > > > > HotJobs - Search Thousands of New Jobs > > > > > > http://www.hotjobs.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > HotJobs - Search Thousands of New Jobs > > > http://www.hotjobs.com > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Php-tuxedo-development mailing list > > Php...@li... > > https://lists.sourceforge.net/lists/listinfo/php-tuxedo-development > > > >-- >CheolMin Lee <cmlee @ users.sourceforge.net> <cmlee @ kt.co.kr> >Homepage: http://tclab.kaist.ac.kr/~cmlee/ > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >Php-tuxedo-development mailing list >Php...@li... >https://lists.sourceforge.net/lists/listinfo/php-tuxedo-development Brian Douglass br...@tp... 702-254-5485 |
From: CheolMin L. <cm...@us...> - 2002-08-09 00:06:21
|
:) On Thu, Aug 08, 2002 at 11:55:44AM -0500, Brian Foddy wrote: > Those libraries are provided in the Tuxedo package, Tom, Tuxedo is commercial. You may download trial version for RedHat. Check the following link: http://commerce.bea.com/downloads/tuxedo.jsp Good luck. > not included with php-tuxedo or Redhat. If you don't > have the Tuxedo libraries and header files for your > platform, it will not work. > > Brian > > On Thu, 8 Aug 2002, Tom Stone wrote: > > > I have configured php more than 10 times.But it was > > not included tuxedo modules. And then removed the > > libnwi.so;libnws.so;libgp.so libraries,the configure > > is ok. But when i configed the apache sever,the errors > > was shown. What's the matter? And could you tell me > > what are the three > > libraries:libnwi.so;libnws.so;libgp.so. I can not find > > them in RedHat 6.2. > > Thanks. > > > > --- Brian Foddy <bf...@vi...> wrote: > > > I have seen some times when buildconf will not pick > > > up the > > > new tuxedo/config.m4 file because it uses a > > > date/time check similar > > > to "make" looking for new files. Many times simply > > > > > > touch tuxedo/config.m4 (or equiv depending on what > > > dir you are in) > > > > > > will correct the problem, then re-run the buildconf > > > and > > > configure. There is a couple lines of output in the > > > configure > > > script about Tuxedo, if you don't see those, its not > > > including the > > > module. > > > > > > Brian > > > > > > > > > On Thu, 8 Aug 2002, CheolMin Lee wrote: > > > > > > > The information about your problem is insufficient > > > so that I'm only > > > > guessing it. > > > > Can you provide some output from configure or make > > > where the error is > > > > occurred? > > > > > > > > On Wed, Aug 07, 2002 at 10:49:54PM -0700, Tom > > > Stone wrote: > > > > > sure,i used buildconf commnad,but problem was > > > not > > > > > resolved. And i did not found the follow the > > > lib: > > > > > libnwi.so > > > > > libnws.so > > > > > libgp.so > > > > > > > > > > > > > > > --- CheolMin Lee <cm...@us...> > > > wrote: > > > > > > On Mon, Aug 05, 2002 at 01:21:28AM -0700, > > > jackliu > > > > > > wrote: > > > > > > > I use php-tuxedo module 0.4.1 in php 4.2.2, > > > but > > > > > > when i > > > > > > > configure the php,can not include ext/tuxedo > > > > > > subdir. And > > > > > > > found some errors in ext/tuxedo/config.m4 > > > file,the > > > > > > follows > > > > > > > files not found. > > > > > > > PHP_ADD_LIBRARY(nwi) libnwi.so > > > > > > > PHP_ADD_LIBRARY(nws) libnws.so > > > > > > > PHP_ADD_LIBRARY(gp) libgp.so > > > > > > > > > > > > > > Could you tell me why? And how to resolve > > > the > > > > > > problems? > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > Best Regards. > > > > > > > > > > > > > > > > > > > Did you re-build configure.in? > > > > > > php-tuxedo is not built-in php extension so > > > you must > > > > > > re-build > > > > > > configure.in by 'buildconf' script to use > > > > > > php-tuxedo. > > > > > > > > > > > > README.EXT_SKEL in PHP's source will help you. > > > :) > > > > > > > > > > > > -- > > > > > > CheolMin Lee <cmlee @ users.sourceforge.net> > > > <cmlee > > > > > > @ kt.co.kr> > > > > > > Homepage: http://tclab.kaist.ac.kr/~cmlee/ > > > > > > > > > > > > > > > > > > __________________________________________________ > > > > > Do You Yahoo!? > > > > > HotJobs - Search Thousands of New Jobs > > > > > http://www.hotjobs.com > > > > > > > > > > > > > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > HotJobs - Search Thousands of New Jobs > > http://www.hotjobs.com > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Php-tuxedo-development mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/php-tuxedo-development > -- CheolMin Lee <cmlee @ users.sourceforge.net> <cmlee @ kt.co.kr> Homepage: http://tclab.kaist.ac.kr/~cmlee/ |
From: Brian F. <bf...@vi...> - 2002-08-08 16:55:50
|
Those libraries are provided in the Tuxedo package, not included with php-tuxedo or Redhat. If you don't have the Tuxedo libraries and header files for your platform, it will not work. Brian On Thu, 8 Aug 2002, Tom Stone wrote: > I have configured php more than 10 times.But it was > not included tuxedo modules. And then removed the > libnwi.so;libnws.so;libgp.so libraries,the configure > is ok. But when i configed the apache sever,the errors > was shown. What's the matter? And could you tell me > what are the three > libraries:libnwi.so;libnws.so;libgp.so. I can not find > them in RedHat 6.2. > Thanks. > > --- Brian Foddy <bf...@vi...> wrote: > > I have seen some times when buildconf will not pick > > up the > > new tuxedo/config.m4 file because it uses a > > date/time check similar > > to "make" looking for new files. Many times simply > > > > touch tuxedo/config.m4 (or equiv depending on what > > dir you are in) > > > > will correct the problem, then re-run the buildconf > > and > > configure. There is a couple lines of output in the > > configure > > script about Tuxedo, if you don't see those, its not > > including the > > module. > > > > Brian > > > > > > On Thu, 8 Aug 2002, CheolMin Lee wrote: > > > > > The information about your problem is insufficient > > so that I'm only > > > guessing it. > > > Can you provide some output from configure or make > > where the error is > > > occurred? > > > > > > On Wed, Aug 07, 2002 at 10:49:54PM -0700, Tom > > Stone wrote: > > > > sure,i used buildconf commnad,but problem was > > not > > > > resolved. And i did not found the follow the > > lib: > > > > libnwi.so > > > > libnws.so > > > > libgp.so > > > > > > > > > > > > --- CheolMin Lee <cm...@us...> > > wrote: > > > > > On Mon, Aug 05, 2002 at 01:21:28AM -0700, > > jackliu > > > > > wrote: > > > > > > I use php-tuxedo module 0.4.1 in php 4.2.2, > > but > > > > > when i > > > > > > configure the php,can not include ext/tuxedo > > > > > subdir. And > > > > > > found some errors in ext/tuxedo/config.m4 > > file,the > > > > > follows > > > > > > files not found. > > > > > > PHP_ADD_LIBRARY(nwi) libnwi.so > > > > > > PHP_ADD_LIBRARY(nws) libnws.so > > > > > > PHP_ADD_LIBRARY(gp) libgp.so > > > > > > > > > > > > Could you tell me why? And how to resolve > > the > > > > > problems? > > > > > > > > > > > > Thanks. > > > > > > > > > > > > Best Regards. > > > > > > > > > > > > > > > > Did you re-build configure.in? > > > > > php-tuxedo is not built-in php extension so > > you must > > > > > re-build > > > > > configure.in by 'buildconf' script to use > > > > > php-tuxedo. > > > > > > > > > > README.EXT_SKEL in PHP's source will help you. > > :) > > > > > > > > > > -- > > > > > CheolMin Lee <cmlee @ users.sourceforge.net> > > <cmlee > > > > > @ kt.co.kr> > > > > > Homepage: http://tclab.kaist.ac.kr/~cmlee/ > > > > > > > > > > > > > > __________________________________________________ > > > > Do You Yahoo!? > > > > HotJobs - Search Thousands of New Jobs > > > > http://www.hotjobs.com > > > > > > > > > > > > > > > __________________________________________________ > Do You Yahoo!? > HotJobs - Search Thousands of New Jobs > http://www.hotjobs.com > |
From: Brian F. <bf...@vi...> - 2002-08-08 13:49:57
|
I have seen some times when buildconf will not pick up the new tuxedo/config.m4 file because it uses a date/time check similar to "make" looking for new files. Many times simply touch tuxedo/config.m4 (or equiv depending on what dir you are in) will correct the problem, then re-run the buildconf and configure. There is a couple lines of output in the configure script about Tuxedo, if you don't see those, its not including the module. Brian On Thu, 8 Aug 2002, CheolMin Lee wrote: > The information about your problem is insufficient so that I'm only > guessing it. > Can you provide some output from configure or make where the error is > occurred? > > On Wed, Aug 07, 2002 at 10:49:54PM -0700, Tom Stone wrote: > > sure,i used buildconf commnad,but problem was not > > resolved. And i did not found the follow the lib: > > libnwi.so > > libnws.so > > libgp.so > > > > > > --- CheolMin Lee <cm...@us...> wrote: > > > On Mon, Aug 05, 2002 at 01:21:28AM -0700, jackliu > > > wrote: > > > > I use php-tuxedo module 0.4.1 in php 4.2.2, but > > > when i > > > > configure the php,can not include ext/tuxedo > > > subdir. And > > > > found some errors in ext/tuxedo/config.m4 file,the > > > follows > > > > files not found. > > > > PHP_ADD_LIBRARY(nwi) libnwi.so > > > > PHP_ADD_LIBRARY(nws) libnws.so > > > > PHP_ADD_LIBRARY(gp) libgp.so > > > > > > > > Could you tell me why? And how to resolve the > > > problems? > > > > > > > > Thanks. > > > > > > > > Best Regards. > > > > > > > > > > Did you re-build configure.in? > > > php-tuxedo is not built-in php extension so you must > > > re-build > > > configure.in by 'buildconf' script to use > > > php-tuxedo. > > > > > > README.EXT_SKEL in PHP's source will help you. :) > > > > > > -- > > > CheolMin Lee <cmlee @ users.sourceforge.net> <cmlee > > > @ kt.co.kr> > > > Homepage: http://tclab.kaist.ac.kr/~cmlee/ > > > > > > __________________________________________________ > > Do You Yahoo!? > > HotJobs - Search Thousands of New Jobs > > http://www.hotjobs.com > > > > |
From: CheolMin L. <cm...@us...> - 2002-08-08 08:46:28
|
The information about your problem is insufficient so that I'm only guessing it. Can you provide some output from configure or make where the error is occurred? On Wed, Aug 07, 2002 at 10:49:54PM -0700, Tom Stone wrote: > sure,i used buildconf commnad,but problem was not > resolved. And i did not found the follow the lib: > libnwi.so > libnws.so > libgp.so > > > --- CheolMin Lee <cm...@us...> wrote: > > On Mon, Aug 05, 2002 at 01:21:28AM -0700, jackliu > > wrote: > > > I use php-tuxedo module 0.4.1 in php 4.2.2, but > > when i > > > configure the php,can not include ext/tuxedo > > subdir. And > > > found some errors in ext/tuxedo/config.m4 file,the > > follows > > > files not found. > > > PHP_ADD_LIBRARY(nwi) libnwi.so > > > PHP_ADD_LIBRARY(nws) libnws.so > > > PHP_ADD_LIBRARY(gp) libgp.so > > > > > > Could you tell me why? And how to resolve the > > problems? > > > > > > Thanks. > > > > > > Best Regards. > > > > > > > Did you re-build configure.in? > > php-tuxedo is not built-in php extension so you must > > re-build > > configure.in by 'buildconf' script to use > > php-tuxedo. > > > > README.EXT_SKEL in PHP's source will help you. :) > > > > -- > > CheolMin Lee <cmlee @ users.sourceforge.net> <cmlee > > @ kt.co.kr> > > Homepage: http://tclab.kaist.ac.kr/~cmlee/ > > > __________________________________________________ > Do You Yahoo!? > HotJobs - Search Thousands of New Jobs > http://www.hotjobs.com > -- CheolMin Lee <cmlee @ users.sourceforge.net> <cmlee @ kt.co.kr> Homepage: http://tclab.kaist.ac.kr/~cmlee/ |
From: Brian F. <bf...@vi...> - 2002-06-02 21:06:27
|
Just to let everyone know, I haven't falled of the face of the earth; and some new development is in the works. Brian Douglas has been active in using PHP-Tuxedo in his work and is reporting back some issues he is encountering. I'm currently working on getting a better config.m4 script to automatically detect the proper link libraries required for individual Tuxedo installs. Linking problems is my most common trouble problem. Also, with the recent release of Apache 2, and the more common usage of Tuxedo 8, some multi-threaded issues are sure to be following. I have posted the following http://php-tuxedo.sourceforge.net/multi-thread.html on the project web page to try and provide assistance and=20 guidance on which combinations I feel are safe and which are not. Please review this and any feedback on this document would be greatly appreciated and would be quickly applied. Thanks, Brian |
From: Brian F. <bf...@vi...> - 2002-03-29 15:42:08
|
Asong, One additional thought... Have you checked the ORDER of these libraries in the config.m4? Do they exactly match the buildclient output. Even if a duplicate lib exists, it must be duplicated in config.m4 (don't ask me why cuz I don't know, but many times its needed). Brian On Fri, 29 Mar 2002, Brian Foddy wrote: > Does anyone have any other ideas about this link problem. > Brian Douglas... Ever seen these entrypoints? > It must be something unique to the Intel Solaris Tuxedo libraries. > I've not seen these on Solaris Sparc or Linux. And he has gotten > it working on Linux. > > Also, I did a Google search on these entry points, found no hits. > I don't have Tuxedo for Solaris Intel, any my machine is down for > upgrades for a couple weeks anyway. I'm running out of ideas . > Other than just start adding addition Tux libs one-by-one and hoping > to find it. > > Brian > > ---------- Forwarded message ---------- > Date: Fri, 29 Mar 2002 13:33:0 +0800 > From: as...@ma... <as...@ma...> > To: Brian Foddy <bf...@vi...> > Subject: Re: Re: Re: Hi about php-tuxedo in sol 8 > > > Hi Brian: > Thank u very much. > > my buildclient 's line is cc -I$TUXDIR/include -o a.out -L${TUXDIR}/lib servicetest.c -ltux -lbuft -ltux2 -lfml -lfml32 -lgp -lnsl -lsocket > and I added "nsl" in TUXLIBS and ADD_PHP_LIBS. > > > Still the problem. > ps:I have installed php-tuxedo successfully in Linux platform. > > ************************************************************************************* > -o httpd buildmark.o modules.o modules/php4/libphp4.a modules/extra/libextra.a modules/standard/libstandard.a main/libmain.a ./os/unix/libos.a ap/libap.a lib/expat-lite/libexpat.a -R/usr/ucblib -R/usr/local/lib/gcc-lib/i386-pc-solaris2.8/2.95.3 -R/u01/app/oracle/product/8.1.6/lib -R/home/tuxedo/lib -L/usr/ucblib -L/usr/local/lib/gcc-lib/i386-pc-solaris2.8/2.95.3 -L/u01/app/oracle/product/8.1.6/lib -L/home/tuxedo/lib -Lmodules/php4 -L../modules/php4 -L../../modules/php4 -lmodphp4 -lpam -ldl -lfml32 -lfml -lgp -lnws -lnwi -lbuft -lwsc -lm -lthread -laio -lelf -ldl -lgen -lnsl -lsocket -lm -lthread -laio -lelf -ldl -lgen -lnsl -lsocket -lcrypt -lresolv -lresolv -lm -ldl -lnsl -lsocket -lsocket -lgcc -lclntsh -lclntsh -lsocket -lnsl > Undefined first referenced > symbol in file > tmnwpoll /home/tuxedo/lib/libwsc.a(libwsc.so.60) > tmnwclose /home/tuxedo/lib/libwsc.a(libwsc.so.60) > tmnwconnect /home/tuxedo/lib/libwsc.a(libwsc.so.60) > tmnwrelease /home/tuxedo/lib/libwsc.a(libwsc.so.60) > tmnwsnd /home/tuxedo/lib/libwsc.a(libwsc.so.60) > tmnwopen /home/tuxedo/lib/libwsc.a(libwsc.so.60) > tmnwgetbuf /home/tuxedo/lib/libwsc.a(libwsc.so.60) > tmnwinitnet /home/tuxedo/lib/libwsc.a(libwsc.so.60) > tmnwhold /home/tuxedo/lib/libwsc.a(libwsc.so.60) > tmaddr_inet2bin /home/tuxedo/lib/libwsc.a(libwsc.so.60) > tmnwfreebuf /home/tuxedo/lib/libwsc.a(libwsc.so.60) > _tmtypeswaddr /home/tuxedo/lib/libwsc.a(libwsc.so.60) > tmnwcntl /home/tuxedo/lib/libwsc.a(libwsc.so.60) > tmnwsetsig /home/tuxedo/lib/libwsc.a(libwsc.so.60) > tmnwrcv /home/tuxedo/lib/libwsc.a(libwsc.so.60) > ld: fatal: Symbol referencing errors. No output written to httpd > collect2: ld returned 1 exit status > make[2]: *** [target_static] Error 1 > > ************************************************************************************ > > > > Best Regards > > > > >Unfortunately, my main development system is down for upgrades, but > >I will explain what you need to try... > > > >As I said before the config.m4 frequently needs changing from > >version to version (of Tuxedo/platform). > > > >Try this... > > > >Take your C program that compiles/builds fine. I assume > >you are using buildclient to build it. Run the same > >command line with -v (buildclient -v ...). > > > >The output it produces will include the -l(libraries) that > >are needed for your platform. Copy these lines > >into the TUXLIBS line on config.m4, and if any libs > >are new add them to the ADD_PHP_LIBS lines following the > >same format that is there. > > > >Rebuild everything from scratch (rm config.cache, buildconf, > >config, make) and see if that doesn't help, or at least > >reduce the link errors. > > > >I know it builds find on normal Solaris 2.8 and 6.5, > >Intel Solaris may have a few different libraries it needs. > > > >The fact that it can resolve most of the basic entry points > >tells me you've made a lot of progress. > > > >Sorry its such a pain to link, I do hope to improve > >this but its not easy and my machine is down right now. > > > >Write back if you have more problems. > > > >Brian > > > > > >On Wed, 27 Mar 2002 as...@ma... wrote: > > > >> Hi Brian: > >> I have build a c program in my server.and it works fine. > >> but again,when compile php-tuxedo. > >> I encounter such a error,looks different from the last onle. > >> > >> > >> > >> *********************************************************************** > >> Undefined first referenced > >> symbol in file > >> tmnwpoll /home/tuxedo/lib/libwsc.a(libwsc.so.60) > >> tmnwclose /home/tuxedo/lib/libwsc.a(libwsc.so.60) > >> tmnwconnect /home/tuxedo/lib/libwsc.a(libwsc.so.60) > >> tmnwrelease /home/tuxedo/lib/libwsc.a(libwsc.so.60) > >> tmnwsnd /home/tuxedo/lib/libwsc.a(libwsc.so.60) > >> tmnwopen /home/tuxedo/lib/libwsc.a(libwsc.so.60) > >> tmnwgetbuf /home/tuxedo/lib/libwsc.a(libwsc.so.60) > >> tmnwinitnet /home/tuxedo/lib/libwsc.a(libwsc.so.60) > >> tmnwhold /home/tuxedo/lib/libwsc.a(libwsc.so.60) > >> tmaddr_inet2bin /home/tuxedo/lib/libwsc.a(libwsc.so.60) > >> tmnwfreebuf /home/tuxedo/lib/libwsc.a(libwsc.so.60) > >> _tmtypeswaddr /home/tuxedo/lib/libwsc.a(libwsc.so.60) > >> tmnwcntl /home/tuxedo/lib/libwsc.a(libwsc.so.60) > >> tmnwsetsig /home/tuxedo/lib/libwsc.a(libwsc.so.60) > >> tmnwrcv /home/tuxedo/lib/libwsc.a(libwsc.so.60) > >> ld: fatal: Symbol referencing errors. No output written to httpd > >> ********************************************************************** > >> > >> > >> I am using the last config.m4.php-4.1.2 + apache 1.3.24 + solaris8(intel) + tuxedo6.5 > >> > >> Could u give me some advice? > >> > >> > >> Best Regards > >> > >> > >> Frank > >> > >> > >> > >> ÔÚ 2002-03-20 00:17:00 > >> >Looks like the build process can't find ANY of the > >> >tuxedo libraries. All these calls are the basic Tuxedo > >> >API calls called from the program. > >> > > >> >One of the items needing work is the auto config > >> >(buildconf) for this project. Tuxedo changes the linking > >> >with each release, so its impossible to effectively hardcode. > >> > > >> >You can try and grab the latest config.m4 file in the CVS tree, > >> >I know it works properly on Solaris Sparc 2.8 and Tux 6.5 as > >> >that is one of the test combos. > >> > > >> >However, because you have missed sooo many basic entry points, > >> >you really have something more fundamental wrong with your build > >> >and link environment. Recheck all your lib paths and such. > >> >Try to build a example standard C tux client to make sure > >> >everything is working. > >> > > >> >Brian > >> > > >> > > >> > > >> >On Wed, 20 Mar 2002 13:27:40 +0800, as...@ma... wrote: > >> > > >> >>Hi Bfoddy: > >> >>Now I am installing php-tuxedo 0.41(or 0.3.5) in my Solaris 8 (intel platform) with tuxedo 6.5, php4.1.1 and > >> >apache-1.3.20. > >> >>but when compling the apache,I encounter such error: > >> >> > >> >> > >> >>*****************BEGAIN********************************* > >> >>Undefined first referenced > >> >> symbol in file > >> >>Fchksum modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Ffprint32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fget modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fdel32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fcpy32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>tpclose modules/php4/libphp4.a(php_tuxedo.o) > >> >>tpcommit modules/php4/libphp4.a(php_tuxedo.o) > >> >>Fchg modules/php4/libphp4.a(php_tuxedo_arrayfml.o) > >> >>Fnum modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fldid32 modules/php4/libphp4.a(php_tuxedo_arrayfml.o) > >> >>Fldtype modules/php4/libphp4.a(php_tuxedo_arrayfml.o) > >> >>tx_close modules/php4/libphp4.a(php_tuxedo.o) > >> >>Funused modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Ftype modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fused32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Funindex32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Findex32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>tpfree modules/php4/libphp4.a(php_tuxedo.o) > >> >>Fcmp modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fname32 modules/php4/libphp4.a(php_tuxedo_arrayfml.o) > >> >>Fldno32 modules/php4/libphp4.a(php_tuxedo_arrayfml.o) > >> >>Flen32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fmkfldid32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Findex modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Ffind modules/php4/libphp4.a(php_tuxedo_arrayfml.o) > >> >>Fnmid_unload32 modules/php4/libphp4.a(php_tuxedo.o) > >> >>Ferror32 modules/php4/libphp4.a(php_tuxedo_arrayfml.o) > >> >>Fldid modules/php4/libphp4.a(php_tuxedo_arrayfml.o) > >> >>tpalloc modules/php4/libphp4.a(php_tuxedo.o) > >> >>Fneeded modules/php4/libphp4.a(php_tuxedo_arrayfml.o) > >> >>Fcpy modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fdelall32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Foccur modules/php4/libphp4.a(php_tuxedo_arrayfml.o) > >> >>Fmove modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fidxused32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fdel modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fldno modules/php4/libphp4.a(php_tuxedo_arrayfml.o) > >> >>tuxreadenv modules/php4/libphp4.a(php_tuxedo.o) > >> >>Fsizeof32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Frstrindex32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Flen modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Ferror modules/php4/libphp4.a(php_tuxedo.o) > >> >>tpbegin modules/php4/libphp4.a(php_tuxedo.o) > >> >>tpinit modules/php4/libphp4.a(php_tuxedo.o) > >> >>Fidxused modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fldtype32 modules/php4/libphp4.a(php_tuxedo_arrayfml.o) > >> >>Fnext32 modules/php4/libphp4.a(php_tuxedo_arrayfml.o) > >> >>Fused modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>tuxgetenv modules/php4/libphp4.a(php_tuxedo.o) > >> >>Fojoin modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fnmid_unload modules/php4/libphp4.a(php_tuxedo.o) > >> >>Fconcat modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fielded modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Ftype32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Foccur32 modules/php4/libphp4.a(php_tuxedo_arrayfml.o) > >> >>Fupdate32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>tpabort modules/php4/libphp4.a(php_tuxedo.o) > >> >>tprealloc modules/php4/libphp4.a(php_tuxedo.o) > >> >>Fcmp32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fconcat32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fmkfldid modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fname modules/php4/libphp4.a(php_tuxedo_arrayfml.o) > >> >>Fjoin32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fielded32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fupdate modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fsizeof modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Funused32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>tuxputenv modules/php4/libphp4.a(php_tuxedo.o) > >> >>Fneeded32 modules/php4/libphp4.a(php_tuxedo_arrayfml.o) > >> >>Fchksum32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fdelall modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fnum32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Funindex modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>tpcall modules/php4/libphp4.a(php_tuxedo.o) > >> >>Fmove32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Ffind32 modules/php4/libphp4.a(php_tuxedo_arrayfml.o) > >> >>Fojoin32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fnext modules/php4/libphp4.a(php_tuxedo_arrayfml.o) > >> >>Fpres32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fjoin modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Frstrindex modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>tpterm modules/php4/libphp4.a(php_tuxedo.o) > >> >>tpstrerror modules/php4/libphp4.a(php_tuxedo.o) > >> >>tperrno modules/php4/libphp4.a(php_tuxedo.o) > >> >>Fpres modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>tpacall modules/php4/libphp4.a(php_tuxedo.o) > >> >>Fget32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fstrerror32 modules/php4/libphp4.a(php_tuxedo_arrayfml.o) > >> >>Ffprint modules/php4/libphp4.a(php_tuxedo_fml_api.o) > >> >>Fstrerror modules/php4/libphp4.a(php_tuxedo_arrayfml.o) > >> >>Fchg32 modules/php4/libphp4.a(php_tuxedo_arrayfml.o) > >> >>tpgetrply modules/php4/libphp4.a(php_tuxedo.o) > >> >>ld: fatal: Symbol referencing errors. No output written to httpd > >> >>collect2: ld returned 1 exit status > >> >>make[2]: *** [target_static] Error 1 > >> >>make[2]: Leaving directory `/home/kai/apache_1.3.20/src' > >> >>make[1]: *** [build-std] Error 2 > >> >>make[1]: Leaving directory `/home/kai/apache_1.3.20' > >> >>make: *** [build] Error 2 > >> >> > >> >>**********************************END******************************************************* > >> >> > >> >> > >> >>I need your help very vexedly. > >> >> > >> >> > >> >>Best Reards > >> >> > >> >> > >> >> > >> >>Frank > >> >> > >> >> > >> > >> > > Ö > Àñ£¡ > > asong > as...@ma... > > > > _______________________________________________ > Php-tuxedo-development mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/php-tuxedo-development > > |
From: Brian F. <bf...@vi...> - 2002-03-29 15:26:08
|
Does anyone have any other ideas about this link problem. Brian Douglas... Ever seen these entrypoints? It must be something unique to the Intel Solaris Tuxedo libraries. I've not seen these on Solaris Sparc or Linux. And he has gotten it working on Linux. Also, I did a Google search on these entry points, found no hits. I don't have Tuxedo for Solaris Intel, any my machine is down for upgrades for a couple weeks anyway. I'm running out of ideas . Other than just start adding addition Tux libs one-by-one and hoping to find it. Brian ---------- Forwarded message ---------- Date: Fri, 29 Mar 2002 13:33:0 +0800 From: as...@ma... <as...@ma...> To: Brian Foddy <bf...@vi...> Subject: Re: Re: Re: Hi about php-tuxedo in sol 8 Hi Brian: Thank u very much. my buildclient 's line is cc -I$TUXDIR/include -o a.out -L${TUXDIR}/lib servicetest.c -ltux -lbuft -ltux2 -lfml -lfml32 -lgp -lnsl -lsocket and I added "nsl" in TUXLIBS and ADD_PHP_LIBS. Still the problem. ps:I have installed php-tuxedo successfully in Linux platform. ************************************************************************************* -o httpd buildmark.o modules.o modules/php4/libphp4.a modules/extra/libextra.a modules/standard/libstandard.a main/libmain.a ./os/unix/libos.a ap/libap.a lib/expat-lite/libexpat.a -R/usr/ucblib -R/usr/local/lib/gcc-lib/i386-pc-solaris2.8/2.95.3 -R/u01/app/oracle/product/8.1.6/lib -R/home/tuxedo/lib -L/usr/ucblib -L/usr/local/lib/gcc-lib/i386-pc-solaris2.8/2.95.3 -L/u01/app/oracle/product/8.1.6/lib -L/home/tuxedo/lib -Lmodules/php4 -L../modules/php4 -L../../modules/php4 -lmodphp4 -lpam -ldl -lfml32 -lfml -lgp -lnws -lnwi -lbuft -lwsc -lm -lthread -laio -lelf -ldl -lgen -lnsl -lsocket -lm -lthread -laio -lelf -ldl -lgen -lnsl -lsocket -lcrypt -lresolv -lresolv -lm -ldl -lnsl -lsocket -lsocket -lgcc -lclntsh -lclntsh -lsocket -lnsl Undefined first referenced symbol in file tmnwpoll /home/tuxedo/lib/libwsc.a(libwsc.so.60) tmnwclose /home/tuxedo/lib/libwsc.a(libwsc.so.60) tmnwconnect /home/tuxedo/lib/libwsc.a(libwsc.so.60) tmnwrelease /home/tuxedo/lib/libwsc.a(libwsc.so.60) tmnwsnd /home/tuxedo/lib/libwsc.a(libwsc.so.60) tmnwopen /home/tuxedo/lib/libwsc.a(libwsc.so.60) tmnwgetbuf /home/tuxedo/lib/libwsc.a(libwsc.so.60) tmnwinitnet /home/tuxedo/lib/libwsc.a(libwsc.so.60) tmnwhold /home/tuxedo/lib/libwsc.a(libwsc.so.60) tmaddr_inet2bin /home/tuxedo/lib/libwsc.a(libwsc.so.60) tmnwfreebuf /home/tuxedo/lib/libwsc.a(libwsc.so.60) _tmtypeswaddr /home/tuxedo/lib/libwsc.a(libwsc.so.60) tmnwcntl /home/tuxedo/lib/libwsc.a(libwsc.so.60) tmnwsetsig /home/tuxedo/lib/libwsc.a(libwsc.so.60) tmnwrcv /home/tuxedo/lib/libwsc.a(libwsc.so.60) ld: fatal: Symbol referencing errors. No output written to httpd collect2: ld returned 1 exit status make[2]: *** [target_static] Error 1 ************************************************************************************ Best Regards >Unfortunately, my main development system is down for upgrades, but >I will explain what you need to try... > >As I said before the config.m4 frequently needs changing from >version to version (of Tuxedo/platform). > >Try this... > >Take your C program that compiles/builds fine. I assume >you are using buildclient to build it. Run the same >command line with -v (buildclient -v ...). > >The output it produces will include the -l(libraries) that >are needed for your platform. Copy these lines >into the TUXLIBS line on config.m4, and if any libs >are new add them to the ADD_PHP_LIBS lines following the >same format that is there. > >Rebuild everything from scratch (rm config.cache, buildconf, >config, make) and see if that doesn't help, or at least >reduce the link errors. > >I know it builds find on normal Solaris 2.8 and 6.5, >Intel Solaris may have a few different libraries it needs. > >The fact that it can resolve most of the basic entry points >tells me you've made a lot of progress. > >Sorry its such a pain to link, I do hope to improve >this but its not easy and my machine is down right now. > >Write back if you have more problems. > >Brian > > >On Wed, 27 Mar 2002 as...@ma... wrote: > >> Hi Brian: >> I have build a c program in my server.and it works fine. >> but again,when compile php-tuxedo. >> I encounter such a error,looks different from the last onle. >> >> >> >> *********************************************************************** >> Undefined first referenced >> symbol in file >> tmnwpoll /home/tuxedo/lib/libwsc.a(libwsc.so.60) >> tmnwclose /home/tuxedo/lib/libwsc.a(libwsc.so.60) >> tmnwconnect /home/tuxedo/lib/libwsc.a(libwsc.so.60) >> tmnwrelease /home/tuxedo/lib/libwsc.a(libwsc.so.60) >> tmnwsnd /home/tuxedo/lib/libwsc.a(libwsc.so.60) >> tmnwopen /home/tuxedo/lib/libwsc.a(libwsc.so.60) >> tmnwgetbuf /home/tuxedo/lib/libwsc.a(libwsc.so.60) >> tmnwinitnet /home/tuxedo/lib/libwsc.a(libwsc.so.60) >> tmnwhold /home/tuxedo/lib/libwsc.a(libwsc.so.60) >> tmaddr_inet2bin /home/tuxedo/lib/libwsc.a(libwsc.so.60) >> tmnwfreebuf /home/tuxedo/lib/libwsc.a(libwsc.so.60) >> _tmtypeswaddr /home/tuxedo/lib/libwsc.a(libwsc.so.60) >> tmnwcntl /home/tuxedo/lib/libwsc.a(libwsc.so.60) >> tmnwsetsig /home/tuxedo/lib/libwsc.a(libwsc.so.60) >> tmnwrcv /home/tuxedo/lib/libwsc.a(libwsc.so.60) >> ld: fatal: Symbol referencing errors. No output written to httpd >> ********************************************************************** >> >> >> I am using the last config.m4.php-4.1.2 + apache 1.3.24 + solaris8(intel) + tuxedo6.5 >> >> Could u give me some advice? >> >> >> Best Regards >> >> >> Frank >> >> >> >> ÔÚ 2002-03-20 00:17:00 >> >Looks like the build process can't find ANY of the >> >tuxedo libraries. All these calls are the basic Tuxedo >> >API calls called from the program. >> > >> >One of the items needing work is the auto config >> >(buildconf) for this project. Tuxedo changes the linking >> >with each release, so its impossible to effectively hardcode. >> > >> >You can try and grab the latest config.m4 file in the CVS tree, >> >I know it works properly on Solaris Sparc 2.8 and Tux 6.5 as >> >that is one of the test combos. >> > >> >However, because you have missed sooo many basic entry points, >> >you really have something more fundamental wrong with your build >> >and link environment. Recheck all your lib paths and such. >> >Try to build a example standard C tux client to make sure >> >everything is working. >> > >> >Brian >> > >> > >> > >> >On Wed, 20 Mar 2002 13:27:40 +0800, as...@ma... wrote: >> > >> >>Hi Bfoddy: >> >>Now I am installing php-tuxedo 0.41(or 0.3.5) in my Solaris 8 (intel platform) with tuxedo 6.5, php4.1.1 and >> >apache-1.3.20. >> >>but when compling the apache,I encounter such error: >> >> >> >> >> >>*****************BEGAIN********************************* >> >>Undefined first referenced >> >> symbol in file >> >>Fchksum modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Ffprint32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fget modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fdel32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fcpy32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>tpclose modules/php4/libphp4.a(php_tuxedo.o) >> >>tpcommit modules/php4/libphp4.a(php_tuxedo.o) >> >>Fchg modules/php4/libphp4.a(php_tuxedo_arrayfml.o) >> >>Fnum modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fldid32 modules/php4/libphp4.a(php_tuxedo_arrayfml.o) >> >>Fldtype modules/php4/libphp4.a(php_tuxedo_arrayfml.o) >> >>tx_close modules/php4/libphp4.a(php_tuxedo.o) >> >>Funused modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Ftype modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fused32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Funindex32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Findex32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>tpfree modules/php4/libphp4.a(php_tuxedo.o) >> >>Fcmp modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fname32 modules/php4/libphp4.a(php_tuxedo_arrayfml.o) >> >>Fldno32 modules/php4/libphp4.a(php_tuxedo_arrayfml.o) >> >>Flen32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fmkfldid32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Findex modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Ffind modules/php4/libphp4.a(php_tuxedo_arrayfml.o) >> >>Fnmid_unload32 modules/php4/libphp4.a(php_tuxedo.o) >> >>Ferror32 modules/php4/libphp4.a(php_tuxedo_arrayfml.o) >> >>Fldid modules/php4/libphp4.a(php_tuxedo_arrayfml.o) >> >>tpalloc modules/php4/libphp4.a(php_tuxedo.o) >> >>Fneeded modules/php4/libphp4.a(php_tuxedo_arrayfml.o) >> >>Fcpy modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fdelall32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Foccur modules/php4/libphp4.a(php_tuxedo_arrayfml.o) >> >>Fmove modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fidxused32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fdel modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fldno modules/php4/libphp4.a(php_tuxedo_arrayfml.o) >> >>tuxreadenv modules/php4/libphp4.a(php_tuxedo.o) >> >>Fsizeof32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Frstrindex32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Flen modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Ferror modules/php4/libphp4.a(php_tuxedo.o) >> >>tpbegin modules/php4/libphp4.a(php_tuxedo.o) >> >>tpinit modules/php4/libphp4.a(php_tuxedo.o) >> >>Fidxused modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fldtype32 modules/php4/libphp4.a(php_tuxedo_arrayfml.o) >> >>Fnext32 modules/php4/libphp4.a(php_tuxedo_arrayfml.o) >> >>Fused modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>tuxgetenv modules/php4/libphp4.a(php_tuxedo.o) >> >>Fojoin modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fnmid_unload modules/php4/libphp4.a(php_tuxedo.o) >> >>Fconcat modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fielded modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Ftype32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Foccur32 modules/php4/libphp4.a(php_tuxedo_arrayfml.o) >> >>Fupdate32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>tpabort modules/php4/libphp4.a(php_tuxedo.o) >> >>tprealloc modules/php4/libphp4.a(php_tuxedo.o) >> >>Fcmp32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fconcat32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fmkfldid modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fname modules/php4/libphp4.a(php_tuxedo_arrayfml.o) >> >>Fjoin32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fielded32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fupdate modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fsizeof modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Funused32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>tuxputenv modules/php4/libphp4.a(php_tuxedo.o) >> >>Fneeded32 modules/php4/libphp4.a(php_tuxedo_arrayfml.o) >> >>Fchksum32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fdelall modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fnum32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Funindex modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>tpcall modules/php4/libphp4.a(php_tuxedo.o) >> >>Fmove32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Ffind32 modules/php4/libphp4.a(php_tuxedo_arrayfml.o) >> >>Fojoin32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fnext modules/php4/libphp4.a(php_tuxedo_arrayfml.o) >> >>Fpres32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fjoin modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Frstrindex modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>tpterm modules/php4/libphp4.a(php_tuxedo.o) >> >>tpstrerror modules/php4/libphp4.a(php_tuxedo.o) >> >>tperrno modules/php4/libphp4.a(php_tuxedo.o) >> >>Fpres modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>tpacall modules/php4/libphp4.a(php_tuxedo.o) >> >>Fget32 modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fstrerror32 modules/php4/libphp4.a(php_tuxedo_arrayfml.o) >> >>Ffprint modules/php4/libphp4.a(php_tuxedo_fml_api.o) >> >>Fstrerror modules/php4/libphp4.a(php_tuxedo_arrayfml.o) >> >>Fchg32 modules/php4/libphp4.a(php_tuxedo_arrayfml.o) >> >>tpgetrply modules/php4/libphp4.a(php_tuxedo.o) >> >>ld: fatal: Symbol referencing errors. No output written to httpd >> >>collect2: ld returned 1 exit status >> >>make[2]: *** [target_static] Error 1 >> >>make[2]: Leaving directory `/home/kai/apache_1.3.20/src' >> >>make[1]: *** [build-std] Error 2 >> >>make[1]: Leaving directory `/home/kai/apache_1.3.20' >> >>make: *** [build] Error 2 >> >> >> >>**********************************END******************************************************* >> >> >> >> >> >>I need your help very vexedly. >> >> >> >> >> >>Best Reards >> >> >> >> >> >> >> >>Frank >> >> >> >> >> >> Ö Àñ£¡ asong as...@ma... |
From: Brian F. <bf...@vi...> - 2002-01-20 00:54:59
|
This is to inform you of an impending email address change for my personal email account. Please start using this account, bf...@vi... instead of my old account of bf...@mn.... I will continue to get mail from my old account until March 15, 2002 at which time not only will my Cable modem account be turned off, but the provider will be retiring the whole mediaone.net name. So I would have had to change emails anyway. My work email account of bri...@nw... won't change. Thanks, Brian |
From: Brian F. <bf...@mn...> - 2002-01-11 00:23:34
|
Sorry, I missed that because my #ifdef was false. Change le_fopen to php_file_le_open () A function call that returns the apparent global variable. Brian --Original Message Text--- From: Tixier Alain Date: Thu, 10 Jan 2002 11:37:38 +0100 Hello Bryan, I'm trying to build the new PHP-Tuxedo version and I get the following error: Making all in tuxedo /bin/sh /prod/outils/php-4.1.1/libtool --silent --mode=compile gcc -I. -I/prod/outils/php- 4.1.1/ext/tuxedo -I/prod/outils/php-4.1.1/main -I/prod/outils/php-4.1.1 -I/usr/local/apache/include - I/prod/outils/php-4.1.1/Zend -I/prod/outils/php-4.1.1/ext/mysql/libmysql - I/app/oracle/product/8.0.5/rdbms/demo -I/app/oracle/product/8.0.5/network/public - I/app/oracle/product/8.0.5/plsql/public -I/app/tuxedo/include -I/prod/outils/php-4.1.1/ext/xml/expat - D_POSIX_PTHREAD_SEMANTICS -DSOLARIS2=260 -DUSE_EXPAT -I/prod/outils/php-4.1.1/TSRM -g -O2 -prefer-pic -c php_tuxedo_fml_api.c php_tuxedo_fml_api.c: In function `zif_tux_ffprint': php_tuxedo_fml_api.c:1958: `le_fopen' undeclared (first use in this function) php_tuxedo_fml_api.c:1958: (Each undeclared identifier is reported only once php_tuxedo_fml_api.c:1958: for each function it appears in.) *** Error code 1 make: Fatal error: Command failed for target `php_tuxedo_fml_api.lo' Current working directory /prod/outils/php-4.1.1/ext/tuxedo Until now I'm unable to find where "le_fopen" file type should be defined. Thank you for your help. Best regards. Alain Tixier Email: ti...@fr... Tel: 01.45.68.61.15 Fax: 01.45.68.66.60 |
From: Brian F. <bf...@mn...> - 2002-01-10 05:28:51
|
I just release 0.4.0 tonight. I has all the changes we've been discussing recently. PHP 4.1 support, fget, ffprint, and argument changes. I updated some of the docs and ran some more tests. Brian |
From: Brian F. <bf...@mn...> - 2002-01-07 05:54:13
|
Well I decided to go with the overloaded argument approach. The Field ID argument in the functions tux_fdelall, tux_foccur, tux_fdel, tux_flen, tux_fpres, tux_fadd and tux_fget can be passed as either an Integer, hence taken as the Tuxedo Field ID, or as a string, taken as the Tuxedo Field Name and hence calling fldid on it. I think this will give us the best mix. I decided against just changing to only Field Name because Field Names are optional, while highly recommended, still optional. But I did agree with CMLees point that it makes for extra & ugly code to have to nest the tux_fldid call for each usage. Also, I made a small about face with tux_fml2array. Earlier I checked in changes that removed the flag argument in favor of just creating indexes by Field Number and Field Name always for each item. After looking at it more and trying it in some examples, I didn't like it because the very common array combination list/each would find both keys for the same value, making it appear like twice as many values existed in the array, even tho they really didn't. So I put the flag back in, but enhanced it a bit also. Now instead of a simple 0 or 1, its 3 bit flags, so you can have the indexes returned as either 0 or 1 = Field IDs 2 = Field Numbers 4 = Field Names or any combination of these will give multiple indexes ie: 5 = Field Names and Field IDs. All this code is checked in, and some testing has been done. I want to run some more tests before I'm done, but I think we are getting close to a new release point. Brian Foddy |
From: Andi G. <an...@ze...> - 2002-01-05 21:09:21
|
Just be aware that POST/GET/COOKIE data is always saved as a string. So if someone sends you 2 it'll be the string "2". If the arguments to your function won't originate from the above but are written by the developer then overloading will work well. If not you might want to consider splitting the function into two. Andi At 02:10 PM 1/5/2002 -0600, Brian Foddy wrote: >In an external php module project (php-tuxedo), >we have a group of about 7 php functions that, >depending on how we design them, could take two different types >of arguments. >1. A integer argument >2. A string argument. > >If the string argument is given, there is another routine that can >convert it to the corresponding integer argument, but its not >guarenteed to match. Using the integer argument is guarenteed >to work; hence we really need to support the integer args. > >However, the majority of users will want to use the string argument >because its more intuitive and they should provide the translation >tables to allow strings to work. > >I'd like to come up with a solution flexible enough for both. And I have >come up with three different solutions... >1. Create two different function names/entry points, one set for ints, > one set for strings. >2. Overload the function arguments and check which type of arg is being > passed. >3. Screw it and just accept the ints, and let the users nest a function > (in their PHP code) to convert to strings if they want. > >Questions... >1. Any slick way to do solution 1, say with aliases or something? >2. How difficult / successful is it to test the arg type for solution 2. > >Let me re-stress, I'm talking about a PHP C code module, not >PHP code. > >I can provide more detailed description if you need. >Thoughts? >Brian > > > >-- >PHP Development Mailing List <http://www.php.net/> >To unsubscribe, e-mail: php...@li... >For additional commands, e-mail: php...@li... >To contact the list administrators, e-mail: php...@li... |
From: Markus F. <mfi...@gu...> - 2002-01-05 20:41:41
|
On Sat, Jan 05, 2002 at 02:10:17PM -0600, Brian Foddy wrote : > 2. Overload the function arguments and check which type of arg is being > passed. Just accept a ZVAL and do your appropriate conversion later on. > > Questions... > 2. How difficult / successful is it to test the arg type for solution 2. It's a matter of switch(Z_TYPE_P(zval_container)) { case IS_STRING: // do appropriate conversion break; case IS_LONG: // everythings fine break; default: php_error(E_WARNING, "%s(): argument 1 must be integer or string", get_active_function_name(TSRMLS_C)); RETURN_FALSE; } IMHO. Watch out, YMMV; HTH. -- Please always Cc to me when replying to me on the lists. |
From: Brian F. <bf...@mn...> - 2002-01-05 19:12:19
|
In an external php module project (php-tuxedo), we have a group of about 7 php functions that, depending on how we design them, could take two different types of arguments. 1. A integer argument 2. A string argument. If the string argument is given, there is another routine that can convert it to the corresponding integer argument, but its not guarenteed to match. Using the integer argument is guarenteed to work; hence we really need to support the integer args. However, the majority of users will want to use the string argument because its more intuitive and they should provide the translation tables to allow strings to work. I'd like to come up with a solution flexible enough for both. And I have come up with three different solutions... 1. Create two different function names/entry points, one set for ints, one set for strings. 2. Overload the function arguments and check which type of arg is being passed. 3. Screw it and just accept the ints, and let the users nest a function (in their PHP code) to convert to strings if they want. Questions... 1. Any slick way to do solution 1, say with aliases or something? 2. How difficult / successful is it to test the arg type for solution 2. Let me re-stress, I'm talking about a PHP C code module, not PHP code. I can provide more detailed description if you need. Thoughts? Brian |
From: Brian F. <bf...@mn...> - 2002-01-05 06:58:03
|
On Fri, 28 Dec 2001 17:11:52 +0900, CheolMin Lee wrote: >Returning "automatic FML type(16 or 32) decision" issue. > >The following is my old suggestion: > >> >> Synopsis >> mixed tux_fget (resource FML_buffer, int field_id [, int occ]) >> >> Returns the corresponding the value of the field occurrence, or FALSE >> if some error occurs >> >> FML_buffer is FML buffer resource reference >> field_id is FML Field identifier >> occ is occurrence number of the field >> >> I temporarily implemented this function takes not field name but field id >> to indicate a field because of preserving consistency with tux_fadd, tux_flen, >> etc. But, I think it is more convenient to take field name as the argument >> when using in the real world. For example: >> >> tux_fget($fmlbuf, tux_fldid("A_FIELD", TUX_FML)); >> >> vs. >> >> tux_fget($fmlbuf, "A_FIELD"); /* FML or FML32 depends on $fmlbuf */ >> >> Which one do you like? >> > >Before next official release, how about changing argument type from >field_id to field_name? I've already got the code which working on my own >project and finished field-test. > >Target functions for changing the argument type are: > tux_fdelall tux_foccur tux_fdel tux_flen tux_fpres tux_fadd tux_fget > CheolMin, I face this with mixed thoughts. Using the Field ID parameter keeps it in sync with the raw Tux FML calls. However I agree most people will probably have the Field Name, not the ID. Hence we would save them always calling tux_fldid nested like that. If they do still want to use Field ID, they can nest tux_fname ($fieldID, TUX_FML32). There is one other subtle factor in this decision... In Tuxedo, a FML32 ID is defined as a unsigned long (32 bits). However a PHP variable can only be a signed long. Hence there is the possibility of a very large Field ID that can't be properly stored in a PHP variable or parameter. This is a PHP limitation that isn't easy to get around. If we encourage users to use the Field Name, we might reduce the likelyhood of hitting this. I haven't looked in depth at this, but its not been forgotten either. Other thoughts? Brian Douglas, have you ever seen a Field ID that fills up the whole unsigned 32 bits? I'm probably leaning towards changing the params, but can still be swayed either way... Brian |
From: Brian F. <bf...@mn...> - 2002-01-05 06:15:53
|
On Fri, 28 Dec 2001 16:22:34 +0900, CheolMin Lee wrote: >good idea. BTW, is it working well for pipe or socket? >I checked in your recently updated code and found that >php_file_le_fopen() was used to get the resource. >I'm wondering that php_file_le_fopen() works for pipe or socket >even if not using php_file_le_popen() or php_file_le_socket(). > >I'm not an expert in Zend and PHP. So just curious. Good call, I rans some tests and no it wouldn't work primarily because you have to tell the file resource function what types of file resources to accept. So I've changed that code to reflect the example in fwrite, using the raw function call not the macro. Upon testing this, I found files and pipes work fine. I tried a socket connection to an echo server and received a core dump inside the Tuxedo Ffprint function. So until we can get those file types to work, I've removed them from the acceptable list to zend_fetch_resource. I would think files and pipes would be the most important types, but it would be nice to get sockets going someday. Brian |
From: Brian F. <bf...@mn...> - 2002-01-02 00:40:37
|
ChoelMin, Good to hear from you. Several of the earlier messages bounced so I thought maybe you had changed your email address. On Fri, 28 Dec 2001 16:22:34 +0900, CheolMin Lee wrote: >LTNS :) > >On Sun, Dec 23, 2001 at 02:00:54AM -0600, Brian Foddy wrote: >> CheolMin, >> Haven't heard from you in awhile, how goes Php-Tuxedo? >> >> I've been making some updates to get it running on >> Php 4.1 and some other long overdue changes, and >> I'd like to propose a small change to your >> tux_ffprint function... >> >> Rather than have it open and close the file, >> how about passing it a already open PHP open >> file reference, and have it use it. I've got >> most of the designs ready to do this, but it >> would probably involve changing the arg types, >> hence would break anything you've written using your >> arguments. >> >> Thoughts? > >good idea. BTW, is it working well for pipe or socket? >I checked in your recently updated code and found that >php_file_le_fopen() was used to get the resource. >I'm wondering that php_file_le_fopen() works for pipe or socket >even if not using php_file_le_popen() or php_file_le_socket(). > To be honest, I've not tried it for anything except regular files, I made this just before leaving for vacation. I'm back now, I will try and test it somehow with other file types. >> Also, I was looking at the "data" argument you added >> to tux_tpinit... Is it ever possible "data" could be >> a binary value, hence the strlen and strcpy could fail? >> I'm proposing we use memcpy and the internal PHP API >> data length argument for binary safeness. >> > >I like it. Brian Douglas and I traded a couple emails debating if tux_tpinit should accept all the arguments of the real tpinit. His position was it should accept all the real args in the same order, even the "group" arg which is always NULL for us. Apparently some other packages use these same API calls and they do use the "group" argument. Technically, I think I can rely on PHP to tell me how long a string or binary value is, but if people are used to using all these args, I have no problem adding them. Other thoughts from others? Brian |
From: CheolMin L. <cm...@us...> - 2001-12-28 08:12:10
|
Returning "automatic FML type(16 or 32) decision" issue. The following is my old suggestion: > > Synopsis > mixed tux_fget (resource FML_buffer, int field_id [, int occ]) > > Returns the corresponding the value of the field occurrence, or FALSE > if some error occurs > > FML_buffer is FML buffer resource reference > field_id is FML Field identifier > occ is occurrence number of the field > > I temporarily implemented this function takes not field name but field id > to indicate a field because of preserving consistency with tux_fadd, tux_flen, > etc. But, I think it is more convenient to take field name as the argument > when using in the real world. For example: > > tux_fget($fmlbuf, tux_fldid("A_FIELD", TUX_FML)); > > vs. > > tux_fget($fmlbuf, "A_FIELD"); /* FML or FML32 depends on $fmlbuf */ > > Which one do you like? > Before next official release, how about changing argument type from field_id to field_name? I've already got the code which working on my own project and finished field-test. Target functions for changing the argument type are: tux_fdelall tux_foccur tux_fdel tux_flen tux_fpres tux_fadd tux_fget Anything else? On Tue, Dec 25, 2001 at 11:00:37PM -0600, Brian Foddy wrote: > I've checked in some changes for the following... > > 1. PHP 4.1.0 API changes thanks to Tixier Alain. > 2. Changed tux_fml2array to remove the Fname flag argument. Now > instead of relying on the flag to say whether you want items returned > in a Fname or FieldID array, it will attempt both, so its accessable either > way. Its actually only storing the data once, but with two different keys. > 3. CMLee's tux_ffprint function now takes a PHP $fp file pointer instead > of a path string. This should allow us to use sockets, pipes, etc for > much more flexibility and PHP standarization. > > These changes are all checked into CVS, but I have not tagged them nor > created an official release, nor updated any documentation. I'll do these > steps when I return from the holidays. But feel free to try them if you > want any of these features. > > Happy Holidays, > Brian > -- CheolMin Lee <cmlee @ users.sourceforge.net> <cmlee @ kt.co.kr> <cmlee @ bigfoot.com> |
From: CheolMin L. <cm...@us...> - 2001-12-28 07:22:50
|
LTNS :) On Sun, Dec 23, 2001 at 02:00:54AM -0600, Brian Foddy wrote: > CheolMin, > Haven't heard from you in awhile, how goes Php-Tuxedo? > > I've been making some updates to get it running on > Php 4.1 and some other long overdue changes, and > I'd like to propose a small change to your > tux_ffprint function... > > Rather than have it open and close the file, > how about passing it a already open PHP open > file reference, and have it use it. I've got > most of the designs ready to do this, but it > would probably involve changing the arg types, > hence would break anything you've written using your > arguments. > > Thoughts? good idea. BTW, is it working well for pipe or socket? I checked in your recently updated code and found that php_file_le_fopen() was used to get the resource. I'm wondering that php_file_le_fopen() works for pipe or socket even if not using php_file_le_popen() or php_file_le_socket(). I'm not an expert in Zend and PHP. So just curious. > > I've given some thought to try and overload > the argument type so it can go either way, but > I'd rather just keep it clean and use PHP files. > The advantage should be it would work for sockets > and other file types. I don't know if that would > ever be used, but at least its available. > > Also, I was looking at the "data" argument you added > to tux_tpinit... Is it ever possible "data" could be > a binary value, hence the strlen and strcpy could fail? > I'm proposing we use memcpy and the internal PHP API > data length argument for binary safeness. > I like it. > I can't believe its been 4 months since your changes, > I've been so busy I haven't had time to keep the project > moving. But I got a few emails recently of others > using the project and I knew I had to get your changes, > 4.1 support, and other fixes in an official release. > > Thanks for you help so far... > Brian > > > On Tue, 21 Aug 2001 18:58:11 +0900, CheolMin Lee wrote: > > >Hi, PHP-TUXEDOers. > > > >I committed some updates for PHP-Tuxedo 0.3.5. > > > > 1. tux_tpinit has one more but optional argument > > 2. tux_tuxreadenv was fixed > > 3. tux_fget was implemented > > 4. tux_ffprint was implemented > > > >Let me explain the above changes. > > > >[1] > >Brian's original version of tux_tpinit has 4 arguments: user name, > >client name, application password and flags. > >These are essential. However, if someone want to take more powerful > >security level such as USER_AUTH and ACL in their Tuxedo application, > >TPINIT buffer must have the user-level authentication data which is > >usually user password. > >So I added the optional argument, data, into the tux_tpinit. > >You can use the funtion in the php source like this: > > > > tux_tpinit($username, $clientname, $app_passwd, $flag, $user_passwd); > > > > > >[2] > >tux_tuxreadenv() is my contribution to this project. It works good but > >sometimes not good. :) > >In the same PHP scope(that is, it the same PHP file) if tux_tuxreadenv() > >occurs two or more times with mutually different tuxedo environemnt > >especially FML-related, FieldName->FieldID mapping table happend to be > >dirty. So the following functions such as tux_array2fml() may work abnormally. > > > >I fixed this problem with placing Fnmid_unload() before tuxreadenv(). > > > > > >[3] > >tux_fget() is added. > > > >Synopsis > > mixed tux_fget (resource FML_buffer, int field_id [, int occ]) > > > > Returns the corresponding the value of the field occurrence, or FALSE > > if some error occurs > > > > FML_buffer is FML buffer resource reference > > field_id is FML Field identifier > > occ is occurrence number of the field > > > >I temporarily implemented this function takes not field name but field id > >to indicate a field because of preserving consistency with tux_fadd, tux_flen, > >etc. But, I think it is more convenient to take field name as the argument > >when using in the real world. For example: > > > > tux_fget($fmlbuf, tux_fldid("A_FIELD", TUX_FML)); > > > > vs. > > > > tux_fget($fmlbuf, "A_FIELD"); /* FML or FML32 depends on $fmlbuf */ > > > >Which one do you like? > > > > > >[4] > >tux_ffprint() is added. > > > >Synopsis > > int tux_ffprint (resource FML_buffer, string file_path [, string mode]) > > > > Returns the return value of Ffprint(32). > > > > FML_buffer is FML buffer resource reference > > file_path is output file path name > > mode is file open mode("a", "w", etc) > > > >This is another implementation of Brian's tux_ffprintf(). > >Brian's implementation is to print FML buffer into the pre-defined file > >which is "/tmp/php_tux.out". Will it be a potential security hole? > >I have no idea. > >Anyway tux_ffprint() takes the file path from the PHP users, and I think > >this would be a replacement of tux_ffprintf(). > >How about taking tux_ffprint() instead of tux_ffprintf() in the next version? > > > >-- > >CheolMin Lee <cmlee @ kt.co.kr> > > <cmlee @ users.sf.net> <cmlee @ bigfoot.com> > > > >_______________________________________________ > >Php-tuxedo-development mailing list > >Php...@li... > >http://lists.sourceforge.net/lists/listinfo/php-tuxedo-development > > > -- CheolMin Lee <cmlee @ users.sourceforge.net> <cmlee @ kt.co.kr> <cmlee @ bigfoot.com> |
From: Brian D. <br...@tp...> - 2001-12-26 19:56:04
|
Hi everybody. Like everyone else, I haven't been doing much work on PHP Tuxedo, but suddenly it seems to be the answer to some problems of a couple of clients. So, I'm going to be heavily exercising it over the next several weeks. My back ground is in Tuxedo, over 10 years I've been using it from fielding phone support calls to consulting to companies all over the world. I'm brand new to PHP and consider my Web skills to be intermediate (I can read HTML :-). So far, I absolutely love what I see. There has been some great work done. Suddenly, Tuxedo can directly perform eCommerce systems. I think once word gets out, there will be a lot of interests in PHP/Tuxedo. What I have tasked for myself is to 1) Learn PHP enough to write good scripts in it. (There went my Christmas Vacation). 2) Write a series of scripts to provide PHP/Tuxedo interfaces to: Simpapp (Done) Bankapp (in progress) 3) Define the Libraries for compiling with Tuxedo 6.5, 7.1, and 8.0. 4) Test out PHP/Tuxedo to insure it implements all the native client capabilities. As I work through all of these tasks, I will be sending out e-mails to the list requesting comments, information, answers to questions, etc. I know Brian Foddy is on Vacation (lucky dog) and can't answer, but I would appreciate as quick a turn around on responses as possible. The BEA User's Group meeting is in Feb in San Diego. I probably will be attending, and while there is no forum to make a formal announcement, we might be able to make some informal announcements. I will also be publishing my scripts as early as possible for everyone's perusal and comments. Cheers. Brian Douglass President/Enterprise Architect Transaction Processing Solutions, Inc. 8555 W. Sahara Suite 112 Las Vegas, NV 89117 702-254-5485 Voice 702-562-3206 Fax br...@tp... |
From: Brian F. <bf...@mn...> - 2001-12-26 04:01:09
|
I've checked in some changes for the following... 1. PHP 4.1.0 API changes thanks to Tixier Alain. 2. Changed tux_fml2array to remove the Fname flag argument. Now instead of relying on the flag to say whether you want items returned in a Fname or FieldID array, it will attempt both, so its accessable either way. Its actually only storing the data once, but with two different keys. 3. CMLee's tux_ffprint function now takes a PHP $fp file pointer instead of a path string. This should allow us to use sockets, pipes, etc for much more flexibility and PHP standarization. These changes are all checked into CVS, but I have not tagged them nor created an official release, nor updated any documentation. I'll do these steps when I return from the holidays. But feel free to try them if you want any of these features. Happy Holidays, Brian |
From: Brian F. <bf...@mn...> - 2001-12-23 07:01:58
|
CheolMin, Haven't heard from you in awhile, how goes Php-Tuxedo? I've been making some updates to get it running on Php 4.1 and some other long overdue changes, and I'd like to propose a small change to your tux_ffprint function... Rather than have it open and close the file, how about passing it a already open PHP open file reference, and have it use it. I've got most of the designs ready to do this, but it would probably involve changing the arg types, hence would break anything you've written using your arguments. Thoughts? I've given some thought to try and overload the argument type so it can go either way, but I'd rather just keep it clean and use PHP files. The advantage should be it would work for sockets and other file types. I don't know if that would ever be used, but at least its available. Also, I was looking at the "data" argument you added to tux_tpinit... Is it ever possible "data" could be a binary value, hence the strlen and strcpy could fail? I'm proposing we use memcpy and the internal PHP API data length argument for binary safeness. I can't believe its been 4 months since your changes, I've been so busy I haven't had time to keep the project moving. But I got a few emails recently of others using the project and I knew I had to get your changes, 4.1 support, and other fixes in an official release. Thanks for you help so far... Brian On Tue, 21 Aug 2001 18:58:11 +0900, CheolMin Lee wrote: >Hi, PHP-TUXEDOers. > >I committed some updates for PHP-Tuxedo 0.3.5. > > 1. tux_tpinit has one more but optional argument > 2. tux_tuxreadenv was fixed > 3. tux_fget was implemented > 4. tux_ffprint was implemented > >Let me explain the above changes. > >[1] >Brian's original version of tux_tpinit has 4 arguments: user name, >client name, application password and flags. >These are essential. However, if someone want to take more powerful >security level such as USER_AUTH and ACL in their Tuxedo application, >TPINIT buffer must have the user-level authentication data which is >usually user password. >So I added the optional argument, data, into the tux_tpinit. >You can use the funtion in the php source like this: > > tux_tpinit($username, $clientname, $app_passwd, $flag, $user_passwd); > > >[2] >tux_tuxreadenv() is my contribution to this project. It works good but >sometimes not good. :) >In the same PHP scope(that is, it the same PHP file) if tux_tuxreadenv() >occurs two or more times with mutually different tuxedo environemnt >especially FML-related, FieldName->FieldID mapping table happend to be >dirty. So the following functions such as tux_array2fml() may work abnormally. > >I fixed this problem with placing Fnmid_unload() before tuxreadenv(). > > >[3] >tux_fget() is added. > >Synopsis > mixed tux_fget (resource FML_buffer, int field_id [, int occ]) > > Returns the corresponding the value of the field occurrence, or FALSE > if some error occurs > > FML_buffer is FML buffer resource reference > field_id is FML Field identifier > occ is occurrence number of the field > >I temporarily implemented this function takes not field name but field id >to indicate a field because of preserving consistency with tux_fadd, tux_flen, >etc. But, I think it is more convenient to take field name as the argument >when using in the real world. For example: > > tux_fget($fmlbuf, tux_fldid("A_FIELD", TUX_FML)); > > vs. > > tux_fget($fmlbuf, "A_FIELD"); /* FML or FML32 depends on $fmlbuf */ > >Which one do you like? > > >[4] >tux_ffprint() is added. > >Synopsis > int tux_ffprint (resource FML_buffer, string file_path [, string mode]) > > Returns the return value of Ffprint(32). > > FML_buffer is FML buffer resource reference > file_path is output file path name > mode is file open mode("a", "w", etc) > >This is another implementation of Brian's tux_ffprintf(). >Brian's implementation is to print FML buffer into the pre-defined file >which is "/tmp/php_tux.out". Will it be a potential security hole? >I have no idea. >Anyway tux_ffprint() takes the file path from the PHP users, and I think >this would be a replacement of tux_ffprintf(). >How about taking tux_ffprint() instead of tux_ffprintf() in the next version? > >-- >CheolMin Lee <cmlee @ kt.co.kr> > <cmlee @ users.sf.net> <cmlee @ bigfoot.com> > >_______________________________________________ >Php-tuxedo-development mailing list >Php...@li... >http://lists.sourceforge.net/lists/listinfo/php-tuxedo-development |
From: Brian F. <bf...@mn...> - 2001-12-21 22:56:14
|
Thank you very much. I knew I had to try 4.1.0 for API changes, figured there would be some. But you've just saved me a lot of time. I'll try and get these incorporated in a new release soon, but with Christmas coming on, I can't guarentee it will be before then. Once again, thanks and I'm always interested in strengths and weaknesses people find, and how well it works once installed in a real project. Brian --Original Message Text--- From: Tixier Alain Date: Fri, 21 Dec 2001 15:51:13 +0100 Hi ! Congratulations for your project; I'm trying to disploy it in our Tuxedo environment. I encountered three problems during configuration with the new 4.1.0 PHP version due to modifications or deprecations in Zend API's. 1. The following code: zend_module_entry tuxedo_module_entry = "BEA Tuxedo Module", /* the name of these modules */ tuxedo_functions, /* points to zend_function_entry */ ZEND_MINIT (tuxedo), /* module startup function */ ZEND_MSHUTDOWN (tuxedo), /* module shutdown function */ ZEND_RINIT (tuxedo), /* request startup function */ ZEND_RSHUTDOWN (tuxedo), /* request shutdown function */ ZEND_MINFO (tuxedo), /* phpinfo callback function */ STANDARD_MODULE_PROPERTIES /* sets defaults for global startup/shutdown */ }; has to be changed to: zend_module_entry tuxedo_module_entry = { #if ZEND_MODULE_API_NO >= 20010901 STANDARD_MODULE_HEADER, #endif "BEA Tuxedo Module", /* the name of these modules */ tuxedo_functions, /* points to zend_function_entry */ ZEND_MINIT (tuxedo), /* module startup function */ ZEND_MSHUTDOWN (tuxedo), /* module shutdown function */ ZEND_RINIT (tuxedo), /* request startup function */ ZEND_RSHUTDOWN (tuxedo), /* request shutdown function */ ZEND_MINFO (tuxedo), /* phpinfo callback function */ #if ZEND_MODULE_API_NO >= 20010901 NO_VERSION_YET, /* extension version number (string) */ #endif STANDARD_MODULE_PROPERTIES /* sets defaults for global startup/shutdown */ }; 2. "ParameterPassedByRef" has been deprecated !! So, I have done the following changes: ....... ZEND_FE (tux_tpacall, NULL) #if ZEND_MODULE_API_NO >= 20010901 ZEND_FE (tux_tpgetrply, first_arg_force_ref) #else ZEND_FE (tux_tpgetrply, NULL) #endif ZEND_FE (tux_tpclose, NULL) ....... /* check for arg_tpacall_cd_ref being passed by reference */ #if ZEND_MODULE_API_NO < 20010901 if(!ParameterPassedByReference(ht, 1)) { zend_error(E_ERROR, "Argument 1 needs to be passed as a reference"); RETURN_NULL(); } #endif convert_to_long_ex (arg_flags); ....... 3. I experienced some "referecenced symbol not found" while loading "libphp4.so" for the "libwsc.so.60" module. So, I have modified config.m4 to conform the recommended BEA link of WS client. ......... PHP_ADD_INCLUDE($TUXEDO_INCDIR) PHP_ADD_LIBPATH($TUXEDO_LIBDIR) PHP_ADD_LIBRARY_WITH_PATH(gp,$TUXDIR/lib) PHP_ADD_LIBRARY_WITH_PATH(fml32,$TUXDIR/lib) PHP_ADD_LIBRARY_WITH_PATH(fml,$TUXDIR/lib) PHP_ADD_LIBRARY_WITH_PATH(nws,$TUXDIR/lib) PHP_ADD_LIBRARY_WITH_PATH(nwi,$TUXDIR/lib) PHP_ADD_LIBRARY_WITH_PATH(nws,$TUXDIR/lib) PHP_ADD_LIBRARY_WITH_PATH(wsc,$TUXDIR/lib) PHP_ADD_LIBRARY_WITH_PATH(buft,$TUXDIR/lib) PHP_ADD_LIBRARY_WITH_PATH(wsc,$TUXDIR/lib) TUXEDO_LIBS="-lwsc -lbuft -lwsc -lnws -lnwi -lnws -lfml -lfml32 -lgp" ........ Everything seems OK after these cosmetic changes. And finally, due to our own requirements, I have also modified the TPINIT routine to accept 2 new parameters "datalen" and "data". The content of "data" field is forwarded to the application defined authentication service. Kind regards. Happy Christmas! Happy new year! Alain Tixier Email: ti...@fr... Tel: 01.45.68.61.15 Fax: 01.45.68.66.60 |