On Tue, Mar 18, 2003 at 09:22:36AM +0100, H.Merijn Brand wrote:
> On Mon 17 Mar 2003 21:03, Tim Bunce <[EMAIL PROTECTED]> wrote:
> > On Mon, Mar 17, 2003 at 07:39:50PM +0100, H.Merijn Brand wrote:
> > > On Thu 13 Mar 2003 01:25, Tim Bunce <[EMAIL PROTECTED]> wrote:
> >
> > Could you generate a patch for me, that also includes a comment
> > describing the underlying issue?
>
> This is done in hints/hpux.sh, and based upon the docs in Glossary:
>
> cccdlflags (dlsrc.U):
> This variable contains any special flags that might need to be
> passed with 'cc -c' to compile modules to be used to create a shared
> library that will be used for dynamic loading. For hpux, this
> should be +z. It is up to the makefile to use it.
>
> I think that the change in the warning is clear enough to not need additional
> comment or explanation
>
> --- Makefile.PL.org 2003-03-14 18:46:06.000000000 +0100
> +++ Makefile.PL 2003-03-18 08:44:43.000000000 +0100
Thanks.
> @@ -452,14 +452,17 @@
>
> - if ( ($Config{'cc'} eq 'cc') && ($Config{'ccflags'} !~ m/\+z/ &&
> $Config{'ccldflags'} !~ m/\+Z/i) ) {
> - print "Warning: perl was not built with +z in ccflags\n"
> + if ($Config{'cc'}) {
> + my $ccf = $Config{ccflags};
> + exists $Config{ccldflags} and $ccf .= $Config{ccldflags};
> + exists $Config{cccdlflags} and $ccf .= $Config{cccdlflags};
> + $ccf =~ m/\+[zZ]/ and
> + print "Warning: perl was not built with +z or +Z in compiler flags\n"
> . " You may need to rebuild perl from sources\n"
> . " See instructions in README.hpux\n" ;
Isn't that logic reversed? I think that'll print "perl was not built
with +z or +Z" if link flags do match m/\+[zZ]/. Is that right?
> On a side note, is line 539 still valid?
>
> lep a5:/pro/3gl/CPAN/DBD-Oracle-1.13 145 > perl -V:osvers
> osvers='11.00';
> lep a5:/pro/3gl/CPAN/DBD-Oracle-1.13 146 > perl5.6.1 -V:osvers
> osvers='11.00';
> lep a5:/pro/3gl/CPAN/DBD-Oracle-1.13 147 > uname -r
> B.11.00
> lep a5:/pro/3gl/CPAN/DBD-Oracle-1.13 148 >
>
> @@ -536,7 +539,7 @@
> # files, we sadly have to build static on HP-UX 9 :(
> if ($os eq 'hpux') {
> print "***$BELL\n";
> - $osvers =~ s/^[a-z]\.//; # Sigh... 'b.11.0' etc
> + $osvers =~ s/^[a-z]\.//i; # Sigh... 'b.11.0' etc (5.6.1 and up have '11.00')
I've removed it now as there's lots of code above that assumes $osvers
is numeric. Thanks.
> > > "oci8.c", line 271.29: 1506-068 (E) Operation between types "void*(*)(struct
> > > imp_dbh_st*,int,int)" and "void*" is not allowed.
> > > "oci8.c", line 498.12: 1506-068 (E) Operation between types "unsigned char*" and
> > > "char*" is not allowed.
> > > "oci8.c", line 522.45: 1506-280 (E) Function argument assignment between types
> > > "unsigned char*" and "char*" is not allowed.
> >
> > I've fixed the last two. For the first, does just removing the
> > "(void*)" cast fix it for you?
> [...]
> Which explains the error: struct imp_sth_st * vs struct imp_dbh_st *
Ah, thanks!
> How picky can compilers be :)
>
> dbdimp.c: imp_dbh->get_oci_handle = oci_db_handle;
> dbdimp.h: void *(*get_oci_handle) _((imp_dbh_t *imp_dbh, int handle_type, int
> flags));
> dbdimp.h: void *(*get_oci_handle) _((imp_dbh_t *imp_dbh, int handle_type, int
> flags));
>
> It *is* contradicting. I don't know what you want
The second void *(*get_oci_handle)... (line 129 in dbdimp.h) should be
using imp_sth_t *imp_sth. Let me know if that fixes it. Thanks.
> > > > I'm aware that OCI7 support is broken - the tests just dump core.
> > > > If someone could look into that I'd be grateful.
> > > >
> > > > There is still a large backlog of issues I've not dealt with so
> > > > please don't ask if any particular change is in or not.
> > > > What's needed right now is testing of this release candidate.
> > >
> > > Since Oracle databases are supported from Unify 4GL, I cannot install
> > > DBD-Oracle in the main perl lib, and I choose to install under
> > >
> > > $UNIFY/perl
> > >
> > > so I can mix several versions of perl with several versions of $UNIFY
> > >
> > > Would you condider to allow 'make installu' using attached script to support
> > > this special way of installation?
> > >
> > > --8<--- Makefile.PL
> > >
> > > package MY;
> > > sub postamble
> > > {
> > > join "\n" =>
> > > DBI::DBD::dbd_postamble (),
> > > '',
> > > 'installu uinstall: all',
> > > ' $(PERL) installu.pl',
> > > '';
> > > } # postamble
> >
> > I can't see much point or value to be honest. Why not just:
> >
> > perl Makefile.PL && make && make test && perl installu.pl
>
> 1. I have to rebuild the tarball to include installu.pl, so I can automate
> installations. Only after having installu.pl available, that sequence will
> work. [ And in fact, that *is* the sequence I'm currently using from my
> install scripts ]
You'd still have to rebuild the tarball to include installu.pl.
I don't see what you've gained.
> 2. It might be the start of documenting that it may be very useful to install
> DBD-Oracle outside the base tree, in order to be able to run several
> versions alongside. I bet you have been thinking about that too, the first
> time you had to upgrade Oracle, and your DBD::Oracle suddenly stopped
> working, or you wanted to switch DBD version depending on your current DB.
> IMHO, the only workable solution is to use $PERL5LIB, which you can
> (automatically) set on switching DB. Using that, it's safer to place *all*
> DBD's outside the base tree, instead of risking calling the wrong (default)
> one on a mismatching DB.
I'd be more interested in a patch that implements a more general
and reasonably complete solution that other people could use.
That can probably best be discussed on dbi-users till some consensus
is reached.
Tim.
