Thread: PL_na undeclared
Gentlemen and Ladies, I patched the 6.5.1 source yesterday to 6.5.2 and when making the perl interface I get the following error: 'PL_na' undeclared (first use this function) throughout the make process. Everything else compiled and passed with flying colors (as usual :-) I looked through various files but, not being a full-fledged C or perl programmer, could find nothing that helped, and I have not dseen this problem mentioned anywhere on tis list. My system is a Redhat5.1 based running 2.2.10 with updated glibc as well as perl 5.004.04. If you need more info, please do not hesitate to ask me. I need this one for the job and am anxious. Also, I subscribe only to the digest so if you cc to me directly also, that would be a plus. Thankyou all in advance. John C. jcusick@exotrope.net
John Cusick <jcusick@exotrope.net> writes:
> I patched the 6.5.1 source yesterday to 6.5.2 and when making the perl
> interface I get the following error:
> 'PL_na' undeclared (first use this function)
> throughout the make process.
We've heard reports of that before. Apparently, the low-level
interfaces to Perl have changed incompatibly in the recent past
(between 5.004 something and 5.005 something I think).
We have been looking for a Perl guru who knows how to make Pg.pm
work under both older and newer Perls --- breaking back revs to
work with the latest doesn't seem particularly appealing :-(
Know any Perl gurus?
> My system is a Redhat5.1 based running 2.2.10 with updated glibc as well
> as perl 5.004.04.
Are you sure it's not 5.005 something? 5.004_04 is what I'm using here,
and it seems perfectly happy with the current Pg.pm. The folks who
reported this error before were using bleeding-edge Perls...
regards, tom lane
On Mon, 27 Sep 1999, Tom Lane wrote: > We've heard reports of that before. Apparently, the low-level > interfaces to Perl have changed incompatibly in the recent past > (between 5.004 something and 5.005 something I think). I am no Perl guru, but I have successfully built and tested the perl client from 6.5.2 against perl 5.00503, which shipped with RedHat 6.0. No hoops needed (except a patch to the interfaces makefile to change perl5 Makefile.pl to perl Makefile.pl The key is to build the perl client on the same version as it will be run against. Results of running the perl client test script test.pl: bash$ perl test.pl Pg::conndefaults ........ ok Pg::connectdb ........... ok $conn->exec ............. ok $conn->errorMessage ..... ok $conn->db ............... ok $conn->user ............. ok $conn->port ............. ok $conn->cmdStatus ........ ok $conn->oidStatus ........ ok $conn->getline .......... ok $conn->endcopy .......... ok $result->cmdTuples ...... ok $result->fname .......... ok $result->ftype .......... ok $result->fsize .......... ok $result->fnumber ........ ok $result->fetchrow ....... ok test sequence finished. Perl and perl-client versions: bash$ rpm -qa|grep perl perl-5.00503-2 postgresql-perl-6.5.2-1 bash$ postgresql-perl-6.5.2-1 and it's non-beta brothers will be released in a few days, once I've put it through some more hoops. This is the set that, barring any more bugs in the init and upgrading scripts, will be released with RedHat 6.1 on an undisclosed date ;-). ----------------------------------------------------------------------------- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Mon, 27 Sep 1999, Tom Lane wrote: > > John Cusick <jcusick@exotrope.net> writes: > > I patched the 6.5.1 source yesterday to 6.5.2 and when making the perl > > interface I get the following error: > > 'PL_na' undeclared (first use this function) > > throughout the make process. > > We've heard reports of that before. Apparently, the low-level > interfaces to Perl have changed incompatibly in the recent past > (between 5.004 something and 5.005 something I think). > > We have been looking for a Perl guru who knows how to make Pg.pm > work under both older and newer Perls --- breaking back revs to > work with the latest doesn't seem particularly appealing :-( > > Know any Perl gurus? Unfortunately, no. Most people in my hometown never heard of it. > > My system is a Redhat5.1 based running 2.2.10 with updated glibc as well > > as perl 5.004.04. > > Are you sure it's not 5.005 something? 5.004_04 is what I'm using here, > and it seems perfectly happy with the current Pg.pm. The folks who > reported this error before were using bleeding-edge Perls... > > regards, tom lane > Tom, et. al. Yes, I'm sure I'm using perl5.004.04 (Redhat perl-5.004m4-1.rpm distro) This was an update on the Redhat site. I have searched through all the header files on my system that are declared in pg.c and there is no reference to PL_na in any of them. I also searched through the original 5.004.04 that came with Redhat5.1 and it isn't declared in any of the perl files there either. Does anyone know where PL_na is declared (and, out curiousity, what it is)? Thanks for everyone's time in reading this. Sincerely John C.
> I have searched through all the header files on my system that are > declared in pg.c and there is no reference to PL_na in any of them. > I also searched through the original 5.004.04 that came with Redhat5.1 and > it isn't declared in any of the perl files there either. > > Does anyone know where PL_na is declared (and, out curiousity, what it > is)? In both a built and pristine 6.5.2 tarball, I find no mention of 'PL_na' at all with a recursive grep. In which file is this? Lamar Owen WGCR Internet Radio
John Cusick wrote: > On Mon, 27 Sep 1999, Tom Lane wrote: > > > > John Cusick <jcusick@exotrope.net> writes: > > > I patched the 6.5.1 source yesterday to 6.5.2 and when making the perl > > > interface I get the following error: > > > 'PL_na' undeclared (first use this function) > > > throughout the make process. > > > > We've heard reports of that before. Apparently, the low-level > > interfaces to Perl have changed incompatibly in the recent past > > (between 5.004 something and 5.005 something I think). > > > > We have been looking for a Perl guru who knows how to make Pg.pm > > work under both older and newer Perls --- breaking back revs to > > work with the latest doesn't seem particularly appealing :-( > > > > Know any Perl gurus? > > Unfortunately, no. Most people in my hometown never heard of it. > > > > My system is a Redhat5.1 based running 2.2.10 with updated glibc as well > > > as perl 5.004.04. > > > > Are you sure it's not 5.005 something? 5.004_04 is what I'm using here, > > and it seems perfectly happy with the current Pg.pm. The folks who > > reported this error before were using bleeding-edge Perls... > > > > regards, tom lane > > > Tom, et. al. > > Yes, I'm sure I'm using perl5.004.04 (Redhat perl-5.004m4-1.rpm distro) > This was an update on the Redhat site. > > I have searched through all the header files on my system that are > declared in pg.c and there is no reference to PL_na in any of them. > I also searched through the original 5.004.04 that came with Redhat5.1 and > it isn't declared in any of the perl files there either. > > Does anyone know where PL_na is declared (and, out curiousity, what it > is)? In http://www.perl.com/pub/doc/manual/html/pod/perlguts.html: PL_na A variable which may be used with SvPV to tell Perl to calculate the string length. I was looking at how Doug MacEachern handles all of the new perl global variables in modperl. In the Makefile.PL file, there is a subroutine "write_version_h" that writes a .h file that defines a variable that is the perl version. IE: #define PERLV 500503 Then when the src is being compiled, it loads the .h file: #ifndef MOD_PERL_STRING_VERSION #include "mod_perl_version.h" #endif #ifndef MOD_PERL_VERSION #define MOD_PERL_VERSION "TRUE" #endif /* patchlevel.h causes a -Wall warning,* plus chance that another patchlevel.h might be in -I paths* so try to avoid it ifpossible*/ #ifdef PERLV #if PERLV >= 500476 #include "perl_PL.h" #endif #else #include "patchlevel.h" #if ((PATCHLEVEL >= 4) && (SUBVERSION >= 76)) || (PATCHLEVEL >= 5) #include "perl_PL.h" #endif #endif /*PERLV*/ So if the PERLV is greater than 5.004_76 (When all of the internals started to be renamed) then the file perl_PL.h is included. The perl_PL.h is: ---BEGIN--- #ifndef patchlevel #define patchlevel PL_patchlevel #endif #ifndef maxo #define maxo PL_maxo #endif #ifndef op_mask #define op_mask PL_op_mask #endif #ifndef op_name #define op_name PL_op_name #endif #ifndef op_desc #define op_desc PL_op_desc #endif #ifndef statcache #define statcache PL_statcache #endif #ifndef laststatval #define laststatval PL_laststatval #endif #ifndef rs #define rs PL_rs #endif #ifndef beginav #define beginav PL_beginav #endif #ifndef defoutgv #define defoutgv PL_defoutgv #endif #ifndef defstash #define defstash PL_defstash #endif #ifndef egid #define egid PL_egid #endif #ifndef endav #define endav PL_endav #endif #ifndef envgv #define envgv PL_envgv #endif #ifndef euid #define euid PL_euid #endif #ifndef gid #define gid PL_gid #endif #ifndef hints #define hints PL_hints #endif #ifndef incgv #define incgv PL_incgv #endif #ifndef pidstatus #define pidstatus PL_pidstatus #endif #ifndef scopestack_ix #define scopestack_ix PL_scopestack_ix #endif #ifndef siggv #define siggv PL_siggv #endif #ifndef uid #define uid PL_uid #endif #ifndef warnhook #define warnhook PL_warnhook #endif #ifndef diehook #define diehook PL_diehook #endif #ifndef perl_destruct_level #define perl_destruct_level PL_perl_destruct_level #endif #ifndef sv_count #define sv_count PL_sv_count #endif #ifndef sv_objcount #define sv_objcount PL_sv_objcount #endif #ifndef sv_undef #define sv_undef PL_sv_undef #endif #ifndef sv_yes #define sv_yes PL_sv_yes #endif #ifndef sv_no #define sv_no PL_sv_no #endif #ifndef na #define na PL_na #endif #ifndef curcop #define curcop PL_curcop #endif #ifndef curstash #define curstash PL_curstash #endif #ifndef dowarn #define dowarn PL_dowarn #endif #ifndef tainting #define tainting PL_tainting #endif #ifndef stack_sp #define stack_sp PL_stack_sp #endif ---END--- -- Brian Millett Enterprise Consulting Group "Heaven can not exist, (314) 205-9030 If the family is not eternal" bpm@ec-group.com F. Ballard Washburn
Brian P Millett <bpm@ec-group.com> writes:
> So if the PERLV is greater than 5.004_76 (When all of the internals
> started to be renamed) then the file perl_PL.h is included. The
> perl_PL.h is:
> #ifndef patchlevel
> #define patchlevel PL_patchlevel
> #endif
> [ and a lot more in the same vein ]
Ugh. I was afraid the answer would be just that dirty :-(
Would someone volunteer to do the legwork on teaching the postgres perl5
module about this? I had a TODO item to look into it myself, but it
could be a long time before it gets to the top of my queue.
Probably we ought to modify the Pg.pm file to use the new names, and
then conditionally include macro definitions to substitute the old
names, rather than the other way around as your example has it.
Forward thinking and all that.
regards, tom lane
Tom Lane wrote: > Would someone volunteer to do the legwork on teaching the postgres perl5 > module about this? I had a TODO item to look into it myself, but it > could be a long time before it gets to the top of my queue. > > Probably we ought to modify the Pg.pm file to use the new names, and > then conditionally include macro definitions to substitute the old > names, rather than the other way around as your example has it. > Forward thinking and all that. Uh, Tom, the Pg module works for me under Perl _5.00503_. The test.pl script completes and all that. The key is building the module with the version of perl that the module is going to run against (and rebuilding the module when you upgrade perl). This is not a great issue unless you are packaging binaries, though... It ain't broke (at least on RedHat 6.x with the RPM installation). I don't necessarily think that the Pg module is at fault here. Of course, I reserve the right to be totally wrong and will, at my own expense, perform a podondectomy on myself. (that is, surgically remove my foot from my mouth). Lamar Owen WGCR Internet Radio
Lamar Owen <lamar.owen@wgcr.org> writes:
> Uh, Tom, the Pg module works for me under Perl _5.00503_. The test.pl
> script completes and all that. The key is building the module with the
> version of perl that the module is going to run against (and rebuilding
> the module when you upgrade perl).
Hmm. But IIRC, the complaints were from people who were trying and
failing to build the Pg module in the first place. Could it be that
they have mucked-up Perl installations (headers different revision
from Perl binary, or some such)?
regards, tom lane
On Sat, 02 Oct 1999, Tom Lane wrote: > Lamar Owen <lamar.owen@wgcr.org> writes: > > Uh, Tom, the Pg module works for me under Perl _5.00503_. The test.pl > > script completes and all that. The key is building the module with the > > version of perl that the module is going to run against (and rebuilding > > the module when you upgrade perl). > > Hmm. But IIRC, the complaints were from people who were trying and > failing to build the Pg module in the first place. Could it be that > they have mucked-up Perl installations (headers different revision > from Perl binary, or some such? It is possible. I always build with as close to pristine a system as possible -- otherwise, the RPM's I generate become tied to my installation and become useless to anyone else. To provide a point of reference, PL_na is defined on a pristine RedHat 6.0 installation in the file '/usr/lib/perl5/5.00503/i386-linux/CORE/embedvar.h' Also, under RedHat 6.0, only the main perl RPM is necessary to get a good build of Pg. Now, not being a perl wizard, and not being very familiar with the Pg mechanism, I am curious if those having problems have an issue with the build finding the above referenced embedvar.h. (In src/interfaces/perl5/Makefile, after Makefile.PL has run, find the line defining PERL_INC -- on a RedHat 6.0 system, this var should be equal to /usr/lib/perl5/5.00503/i386-linux/CORE -- in other Perl installations, PERL_INC should be set to wherever the CORE header files are.) To provide another point of reference, using the RedHat default installation of the Perl RPM's, I get a good build both with Perl 5.00503 under RedHat 6.0 AND with Perl 5.004m7 under RedHat 5.2. If a copy of my Pg.c, Makefile, or any other files in src/interface/perl5 after the build will help in troubleshooting this problem, let me know. This build has no unusual options for configure or make. There are some shenanigens necessary in the install due to the use of Buildroot in the RPM build process, but that is way after the compile. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Sat, 2 Oct 1999, Tom Lane wrote: > Date: Sat, 02 Oct 1999 11:52:08 -0400 > From: Tom Lane <tgl@sss.pgh.pa.us> > To: Lamar Owen <lamar.owen@wgcr.org> > Cc: Brian P Millett <bpm@ec-group.com>, John Cusick <jcusick@exotrope.net>, > pgsql-interfaces@hub.org > Subject: Re: [INTERFACES] PL_na undeclared > > Lamar Owen <lamar.owen@wgcr.org> writes: > > Uh, Tom, the Pg module works for me under Perl _5.00503_. The test.pl > > script completes and all that. The key is building the module with the > > version of perl that the module is going to run against (and rebuilding > > the module when you upgrade perl). > > Hmm. But IIRC, the complaints were from people who were trying and > failing to build the Pg module in the first place. Could it be that > they have mucked-up Perl installations (headers different revision > from Perl binary, or some such)? > > regards, tom lane > Tom, et. al. Might have been a mucked up installation here. I decided to delete the 5.0004.04 RPM and jump up to 5.005.02 source RPM and build from scratch. Before doing so, i did a recursive grep on the entire 5.005.02 distro and 'PL_na' was all over the place. I then re-built all my perl add-ons from scratch, including the postgreSQL perl mod and all is fine here. I absolutely found no references to 'PL_na' in the earlier distro (and I grepped a couple of times, 'cause I'm still learning everything and don't always believe what I see :-) Anyway, I'm happy now and can continue on with my db demo at my workplace, which is entirely MS based. It's amazing to me that a 130,000 line database returns answers quicker on UNIX(Linux)/PostgreSQL from an ancient Cyrix 386 masqaurading as a 486 than MS Access does from a PentiumII NT server. ( Not much quicker, but check the hardware :-) Thanks again for all the replies and suggestions. The support here is terrific and appreciated. Maybe I will soon be a Perl guru after all, you never know... Sincerely, John C.