Re: Table base class for DBD::File & Co
On 05/10/10 21:00, Tim Bunce wrote: On Thu, May 06, 2010 at 10:28:29AM +, Jens Rehsack wrote: Hi Tim, hi DBI developers, inspired by the issues reported against DBD::DBM and SQL::Statement regarding Test-Database, I checked SQL::Statement, DBD::File and DBD::DBM to figure out where it fails. [...] > > Sorry for the delay replying, and the top-post. Most questions you answered in IRC (remember, I'm Sno| (workstation) or [Sno] (Laptop) there). Looks if you're still under water :( I'll try to get most things done this week - I'd like to get it out as soon as possible, because Test::Database quirks on the bugs and we must coordinate SQL::Statement and DBI releases. > It would be nice to also get coverage of the nano + DBI::PurePerl case. Sure - as I proposed/asked yesterday in a private mail :) I'll think a bit over it - how to do it best. I even miss some tests for DBD::DBM (I detected potential issues with DBI::SQL::Nano when updating or deleting several lines with one matching WHERE clause - and maybe SQL::Statement leads into similar problems, even if I hope to have them fixed). Then some additional tests for DBD::DBM could be done in case SQL::Statement is found (e.g. joining, aggregation tests, ...) > All sounds good. Thanks! \o/ Jens
Re: Table base class for DBD::File & Co
Sorry for the delay replying, and the top-post.
All sounds good. Thanks!
Tim.
On Thu, May 06, 2010 at 10:28:29AM +, Jens Rehsack wrote:
> Hi Tim, hi DBI developers,
>
> inspired by the issues reported against DBD::DBM and SQL::Statement
> regarding Test-Database, I checked SQL::Statement, DBD::File and
> DBD::DBM to figure out where it fails.
>
> I found several bugs which are fixed for now (even if I wouldn't
> tend to release this time). I'd like to get your opinion about
> following two changes:
>
> 1) Introduce a DBI::SQL::Nano::Table, deriving either from
>SQL::Eval::Table or DBI::SQL::Nano::Table_ - like
>DBI::SQL::Nano::Statement does.
>
>Derive DBD::File::Table from DBI::SQL::Nano::Table.
>
> 2) Add 2 additional tests (naming proposals) which test DBD::DBM
>and DBD::Gofer using SQL::Statement, if available.
>To be honest, I would let the 2 new tests use
>"$ENV{DBI_SQL_NANO} = 1" and remove this line from t/50dbm.t
>and t/85gofer.t
>The tests could be named t/zqs_$1
>
> Following changes are planned to do before next DBI release:
> - Synchronize DBD::DBM::Statement and DBD::DBM::Table with DBD::File
> classes
> - allow case insensitive table -> file mapping for tables without ""
> (might need flags for the statement instance)
>
>
> Jens
Re: [svn:dbi] r13966 - dbi/trunk/lib/DBI/SQL
On Sun, May 09, 2010 at 10:45:23PM -0700, rehs...@cvs.perl.org wrote:
> - move from "die" to "croak"
> +croak "Can't find columns\n" unless $self->{column_names};
> +croak "Can't find columns\n" unless $self->{column_names};
> +croak "Can't parse values\n" unless $self->{values};
> +croak "Couldn't parse\n"
> +croak "Bad ORDER BY clause '$str'\n" if @clause > 2;
> +croak "Bad ORDER BY clause '$clause[1]'\n";
> + croak "No column definition for '$_'\n";
> +croak "Can't parse set clause\n"
> +croak "Couldn't find WHERE clause in '$str'\n";
> +croak "Couldn't parse WHERE expression '$str'\n"
> +croak "Number of params '$num_params' does not match "
>. "number of placeholders '$num_placeholders'\n"
> +croak "No such column '$stmt_col_name'\n";
> +croak "No such column '$stmt_col_name'\n";
A croak message that ends with a newline yields a messy error that has a
newline between the error and the file and line number details.
Best to delete the newlines.
> +croak $@ if $@;
In this case you'll probably want to chomp $@ first.
Tim.
Re: Patch to allow tests with SQL::Statement for DBD::DBM and DBD::Gofer
It would be nice to also get coverage of the nano + DBI::PurePerl case.
Tim.
On Fri, May 07, 2010 at 02:18:46PM +0200, Jens Rehsack wrote:
> Hi,
>
> as requested, I'd like to allow tests against SQL::Statement for those
> DBD's which support it, too.
> If no one has objections, I'd like to commit attached patch.
>
> Best regards,
> Jens
> Index: lib/DBI/DBD.pm
> ===
> --- lib/DBI/DBD.pm(revision 13946)
> +++ lib/DBI/DBD.pm(working copy)
> @@ -3320,20 +3320,25 @@
> if @_;
> _inst_checks();
>
> +my %test_variants;
> +
> # decide what needs doing
>
> # do whatever needs doing
> if ($dbd_attr->{create_pp_tests}) {
> # XXX need to convert this to work within the generated Makefile
> # so 'make' creates them and 'make clean' deletes them
> - my %test_variants = (
> + %test_variants = (
> p => { name => "DBI::PurePerl",
> + match => qr/^\d/,
> add => [ '$ENV{DBI_PUREPERL} = 2' ],
> },
> g => { name => "DBD::Gofer",
> + match => qr/^\d/,
> add => [ q{$ENV{DBI_AUTOPROXY} =
> 'dbi:Gofer:transport=null;policy=pedantic'} ],
> },
> xgp => {name => "PurePerl & Gofer",
> + match => qr/^\d/,
> add => [ q{$ENV{DBI_PUREPERL} = 2; $ENV{DBI_AUTOPROXY}
> = 'dbi:Gofer:transport=null;policy=pedantic'} ],
> },
> # mx => { name => "DBD::Multiplex",
> @@ -3344,7 +3349,17 @@
> # add => [ q{local $ENV{DBI_AUTOPROXY} =
> 'dbi:Proxy:XXX';} ],
> # }
> );
> +}
>
> +if ($dbd_attr->{create_nano_tests}) {
> + $test_variants{n} = {
> + name => "DBI::SQL::Nano",
> + match => qr/^(50dbm|85gofer)\.t$/,
> + add => [ q{$ENV{DBI_SQL_NANO} = 1; # force use of DBI::SQL::Nano} ],
> + };
> +}
> +
> +if( 0 != scalar keys %test_variants ) {
> opendir DIR, 't' or die "Can't read 't' directory: $!";
> my @tests = grep { /\.t$/ } readdir DIR;
> closedir DIR;
> @@ -3353,7 +3368,7 @@
> printf "Creating test wrappers for $v_info->{name}:\n";
>
> foreach my $test (sort @tests) {
> -next if $test !~ /^\d/;
> +next if $test !~ $v_info->{match};
> my $usethr = ($test =~ /(\d+|\b)thr/ && $] >= 5.008 &&
> $Config{useithreads});
> my $v_test = "t/zv${v_type}_$test";
> my $v_perl = ($test =~ /taint/) ? "perl -wT" : "perl -w";
> Index: Makefile.PL
> ===
> --- Makefile.PL (revision 13946)
> +++ Makefile.PL (working copy)
> @@ -159,6 +159,7 @@
> WriteMakefile(
> dbd_edit_mm_attribs(\%opts, {
> create_pp_tests => 1,
> + create_nano_tests => 1,
> })
> );
> # WriteMakefile call is last thing executed
> Index: t/85gofer.t
> ===
> --- t/85gofer.t (revision 13946)
> +++ t/85gofer.t (working copy)
> @@ -22,7 +22,8 @@
>
> # 0=SQL::Statement if avail, 1=DBI::SQL::Nano
> # next line forces use of Nano rather than default behaviour
> -$ENV{DBI_SQL_NANO}=1;
> +# $ENV{DBI_SQL_NANO}=1;
> +# This is done in zvn_50dbm.t
>
> GetOptions(
> 'c|count=i' => \(my $opt_count = (-t STDOUT ? 100 : 0)),
> Index: t/50dbm.t
> ===
> --- t/50dbm.t (revision 13946)
> +++ t/50dbm.t (working copy)
> @@ -21,7 +21,8 @@
>
> # 0=SQL::Statement if avail, 1=DBI::SQL::Nano
> # next line forces use of Nano rather than default behaviour
> -$ENV{DBI_SQL_NANO}=1;
> +# $ENV{DBI_SQL_NANO}=1;
> +# This is done in zvn_50dbm.t
>
> push @mldbm_types, '';
> if (eval { require 'MLDBM.pm'; }) {
> @@ -155,14 +156,15 @@
> 5 => '15',
> } if $mldbm;
>
> - print " $sql\n";
> + print " $sql ...";
> $sql =~ s/\s*;\s*(?:#(.*))//;
> my $comment = $1;
>
> my $sth = $dbh->prepare($sql) or die $dbh->errstr;
> my @bind;
> @bind = split /,/, $comment if $sth->{NUM_OF_PARAMS};
> -$sth->execute(@bind);
> +my $n = $sth->execute(@bind);
> + print " $n\n";
> die $sth->errstr if $sth->err and $sql !~ /DROP/;
>
> next unless $sql =~ /SELECT/;
> @@ -187,8 +189,8 @@
> INSERT INTO fruit VALUES (3, NULL );
> INSERT INTO fruit VALUES (4,'to delete' );
> INSERT INTO fruit VALUES (?,?); #5,via placeholders
> +DELETE FROM fruit WHERE dVal='to delete';
> UPDATE fruit SET dVal='apples' WHERE dKey=2;
> -DELETE FROM fruit WHERE dVal='to delete';
> SELECT * FROM fruit;
> DROP TABLE fruit;
>
Re: Clarification sought on private_attribute_info WAS Re: DBD::Oracle 11gr2 & ORA-38909
[Sorry for the delay]
On the one hand, the DBI makes a distinction between "method attributes"
and "handle attributes. They're different things.
On the other hand, the handle constructor methods are a special case.
The method attributes passed to connect() are applied to the newly
created dbh as handle attributes.
The same _ought_ to be true of prepare() but isn't, sadly. This is one
of those areas of the DBI where the risk of breakage now far outweighs
the gains from trying to fix it.
So, to answer your question Martin, I'll update the docs to clarify that
it applies to handle attributes.
Tim.
On Fri, May 07, 2010 at 04:35:32PM +0100, Martin Evans wrote:
> Apologies for top posting but this is an old thread and I include it for
> reference but really I'd like some clarification from Tim as to whether
> the following is correct.
>
> As John states the DBI documentation says for private_attribute_info:
>
> "Returns a reference to a hash whose keys are the names of
> driver-private attributes available for the kind of handle (driver,
> database, statement) that the method was called on."
>
> My question is does this include attributes which may be specified on
> the prepare call when there is no separate store/fetch on the handle. e.g.,
>
> $h->prepare("select 1 from dual", {ora_parse_lang => 2});
>
> You cannot set ora_parse_lang on a $sth or retrieve it so should it be
> in private_attribute_info?
>
> I would like to know since if ora_parse_lang in DBD::Oracle should be in
> private_attribute_info when it cannot be independently stored or fetched
> then this impacts similar prepare attributes in DBD::ODBC.
>
> Martin
> --
> Martin J. Evans
> Easysoft Limited
> http://www.easysoft.com
>
>
> John Scoles wrote:
> >
> >
> > On Tue, Apr 6, 2010 at 4:51 AM, Martin Evans > > wrote:
> >
> > I haven't seen a reply to this yet but I've been on holiday so might
> > have missed it:
> >
> > Scott T. Hildreth wrote:
> > > On Wed, 2010-03-31 at 12:20 -0500, Scott T. Hildreth wrote:
> > >> We have run into an issue with array processing in 11g. The
> > developer
> > >> was using execute_array and his sql statement had 'LOG ERRORS' in it.
> > >> This did not error out until we switched to 11g. The issue is
> > that only
> > >> one is allowed, either 'LOG ERRORS' or 'SAVE EXCEPTIONS'. Our DBA
> > >> logged and error report with Oracle and after several posts back and
> > >> forth this is what they concluded,
> > >>
> > >>
> > ==
> > >> After investigation and discussion, development has closed the bug as
> > >> 'Not a Bug' with the following reason:
> > >>
> > >> "this is an expected behavior in 11g and the user needs to specify
> > >> either of 'SAVE EXCEPTIONS' clause or the 'DML error logging',
> > but NOT
> > >> both together.
> > >> The batch error mode, in the context of this bug, is basically
> > referring
> > >> to the SAVE EXCEPTIONS clause.
> > >> It seems the code is trying to use both dml error logging and batch
> > >> error handling for the same insert. In that case, this is not a bug.
> > >>
> > >> For INSERT, the data errors are logged in an error logging table
> > (when
> > >> the dml error logging feature is used) or returned in batch error
> > >> handles (when using batch mode).
> > >> Since the error messages are available to the user in either
> > case, there
> > >> is no need to both log the error in the error logging table and
> > return
> > >> the errors in batch error handles,
> > >> and we require the user to specify one option or the other but
> > not both
> > >> in 11G.
> > >>
> > >> Both features exist in 10.x. For 11.x, users should change their
> > >> application to avoid the error.
> > >>
> > ==
> > >>
> > >> So basically we need a way to turn off the 'SAVE EXCEPTIONS' for the
> > >> batch mode. I found in dbdimp.c that the oci_mode is being set to
> > >> OCI_BATCH_ERRORS in the ora_st_execute_array function. I was
> > planning
> > >> on setting it to OCI_BATCH_MODE and running a test to see if this
> > will
> > >> not error out. I report back when I have run the test, but I was
> > >> wondering what would be the best way to give the user the ability to
> > >> override the oci_mode.
> > >
> > > Setting oci_mode to OCI_BATCH_MODE works. So I want to add a prepare
> > > attribute that will turn off the SAVE EXCEPTIONS. I'm looking for
> > some
> > > direction on how to add it to dbdimp.c. I haven't thought of a
> > name yet,
> > > but something like
> > >
> > > my $sth = $dbh->prepare($SQL,{ora_oci_err_mode => 0});
> > >
> > > I assume I wou
Re: DBI package problem?
On 10/05/2010 17:44, Tim Bunce wrote: On Sun, Mar 28, 2010 at 11:40:35PM +0200, rosenfield.alb...@gmail.com wrote: > In practice this results in circa 70% of smoke testers running the > module with DBI installed. > > The remaining 30% however, fails with this error: > = # Failed test 'use DBI;' # > at t/00-load.t line 4. # Tried to use 'DBI'. # Error: > Can't locate DBI.pm in @INC (@INC contains: [...snip...]) at (eval > 4) line 2. # BEGIN failed--compilation aborted at (eval 4) line 2. > = > > I could easily change the "use DBI" line into a conditional > "require DBI::PurePerl" during BEGIN, but this does not fix the > root of the problem, namely that the PurePerl version of DBI never > gets installed. We don't know the *root* of the problem. The error you quote above just a symptom of an earlier problem. Where do you get the 70%/30% ratio from? I don't know as cpanstats db shows for the last 2 versions: state, version, count(*) 'fail', '1.609', 44 'na', '1.609', 16 'na', '1.611', 1 'pass', '1.609', 1153 'pass', '1.611', 101 'unknown', '1.609', 11 'unknown', '1.611', 1 4% (rounded up) of failures for fails/passes in 1.609 discounting nas. The na status are all perls too old (not at least 5.8.1). Of the fails in 1.609 most are test failures (after compilation) and for problems Tim has addressed in 1.611. Of all the failures in 1.609 (44 of them) I got fed up of checking them after doing over half of them and finding no lack of compiler problems. In 1.611 the one compiler error is: *** You're using Microsoft Visual C++ compiler or similar but the LIB and INCLUDE environment variables are not both set. You need to run the VCVARS32.BAT batch file that was supplied with the compiler before you can use it. A copy of vcvars32.bat can typically be found in the following directories under your Visual Studio install directory: Visual C++ 6.0: vc98\bin Visual Studio .NET: vc7\bin Find it, run it, then retry this. If you think this error is not correct then just set the LIB and INCLUDE environment variables to some value to disable the check. and DBD::ODBC gets the same error from this particular smoker although on a different smoking platform. For DBI it is Win32 with MS VisC 12 and for DBD::ODBC it is Win32 with gcc. It is hardly surprising DBI and DBD::ODBC produce the same error as I think the test is in DBI but I've always been confused by the error when gcc is being used. I'd like to see details of the specific underlying problems that cause build failures with the current release. Ideally with some indication of which are the most frequent. Tim. There used to be an http://analysis.cpantesters.org/ (or something like that) but the link from the cpan testers wiki does not work now. I got the data from the cpantesters database but it does not seem to contain the actual failure report. If someone knows where the report info is I may be prepared to dig into this a little deeper but I don't as yet see any evidence that 30% of build failures are down to lack of a compiler. Martin
Re: DBI package problem?
On Sun, Mar 28, 2010 at 11:40:35PM +0200, rosenfield.alb...@gmail.com wrote: > In practice this results in circa 70% of smoke testers running the > module with DBI installed. > > The remaining 30% however, fails with this error: > = > # Failed test 'use DBI;' > # at t/00-load.t line 4. > # Tried to use 'DBI'. > # Error: Can't locate DBI.pm in @INC (@INC contains: > [...snip...]) at (eval 4) line 2. > # BEGIN failed--compilation aborted at (eval 4) line 2. > = > > I could easily change the "use DBI" line into a conditional "require > DBI::PurePerl" during BEGIN, but this does not fix the root of the > problem, namely that the PurePerl version of DBI never gets installed. We don't know the *root* of the problem. The error you quote above just a symptom of an earlier problem. Where do you get the 70%/30% ratio from? I'd like to see details of the specific underlying problems that cause build failures with the current release. Ideally with some indication of which are the most frequent. Tim.
RE: make test: dlopen error :can't load library ODBC.so
Maybe it is only a question of dynamic loaded libraries not included in the search path. If I remember well there is a LD_LIBRARY_PATH variable you can add locations where to search libraries to be loaded when executing the program. Cheers, Reinhard Reinhard Erich Voglmaier IT Systems Validation Manager GlaxoSmithKline Spa - Pharmaceuticals Via Fleming 2 37135 - Verona phone 39 045 921 8542 mobile 39 349 079 8094 Questa e-mail è stata spedita da GlaxoSmithKline S.p.A. unipersonale con sede in Via A. Fleming n.2, Verona - società sottoposta all'attività di direzione e coordinamento di GlaxoSmithKline plc - Reg. Imprese di Verona, codice fiscale e partita IVA n. 00212840235 - cap.soc. interamente versato Euro 65.250.000 . GSK ha adottato il proprio Codice Etico , la "carta costituzionale" che declina i principi e le norme di comportamento che l'Azienda assume nei confronti dei propri stakeholder (pazienti, medici, clienti, fornitori, dipendenti, collaboratori e partners) e con i quali intende sviluppare un rapporto fiduciario . Le informazioni contenute nella presente comunicazione possono essere riservate e sono destinate esclusivamente al destinatario. Se il messaggio è pervenuto ad un destinatario diverso da quello indicato, si prega di re-inviarlo al mittente e di cancellarlo permanentemente dal proprio computer senza leggerlo, farne copia, inoltrarlo a terzi o conservarlo. Trattandosi di e-mail aziendale, anche le eventuali risposte pervenute potrebbero essere lette da personale GSK . This e-mail was sent by GlaxoSmithKline S.p.A. sole shareholder, Via Fleming 2,Verona-Italy which is a member of the GlaxoSmithKline group of companies - Verona Register of Companies and VAT code n. 00212840235 - paid up capital Euro 65.250.000 . GSK has adopted its own Codice Etico , the "statute" in which the Company legal and ethical principles for conducting the business have been declared with respect to its own stakeholders (patients, healthcare practitioners, customers, suppliers, employees, collaborators and partners) with whom a trusty relationship has to be developed . This e-mail message may contain confidential information and is intended exclusively for the recipient. If you are not the intended recipient you are obliged to not read, copy, disclose, distribute, or copy it to any third party. If you erroneously receive this message you are obliged to return it to the sender and eliminate it permanently from your computer. Being a company e-mail, replies as well might be read by GSK employees. -Original Message- From: Chunmei Wu [mailto:chunmei...@oracle.com] Sent: 10 May 2010 04:06 To: dbi-dev@perl.org Subject: make test: dlopen error :can't load library ODBC.so Hi everyone, OS: AIX perl version: 5.0 After installed DBD-ODBC-1.21, I run 'make test', but failed 'can't load library' error: t/20SqlServer...ok 2/65install_driver(ODBC) failed: Can't load '/home/eng-sm/unixuser/claire/test/perl/DBD-ODBC-1.21/blib/arch/auto/DBD/ODBC/ODBC.so' for module DBD::ODBC: dlopen: /home/eng-sm/unixuser/claire/test/perl/DBD-ODBC-1.21/blib/arch/auto/DBD/ODBC/ODBC.so: can't load library /home/eng-sm/unixuser/claire/test/perl/DBD-ODBC-1.21/blib/arch/auto/DBD/ODBC/ODBC.so103 /home/eng-sm/unixuser/claire/test/perl/DBD-ODBC-1.21/blib/arch/auto/DBD/ODBC/ODBC.so at /vobs/siebel/src/3rdparty/perl5.8/aix/lib/5.8.0/aix/DynaLoader.pm line 229. at (eval 4) line 3 Compilation failed in require at (eval 4) line 3. Perhaps a required shared library or dll isn't installed where expected at t/20SqlServer.t line 218 But i can run ldd for this library: unixus...@dsliaa05 # > ldd /home/eng-sm/unixuser/claire/test/perl/DBD-ODBC-1.21/blib/arch/auto/DBD/ODBC/ODBC.so /home/eng-sm/unixuser/claire/test/perl/DBD-ODBC-1.21/blib/arch/auto/DBD/ODBC/ODBC.so needs: /usr/lib/libc.a(shr_64.o) /home/eng-sm/unixuser/claire/test/perl/unixodbc_install2.3.0_64/lib/libodbc.a(libodbc.so.1) /unix /usr/lib/libcrypt.a(shr_64.o) /usr/lib/libpthread.a(shr_xpg5_64.o) /usr/lib/libiconv.a(shr4_64.o) Can you help me? Thanks in advance! Thanks, Chunmei Wu
Re: make test: dlopen error :can't load library ODBC.so
On 05/10/10 08:19, Chunmei Wu wrote: Hi Martin, Reinhard and Jens, Please do not top-post Thanks for your advice. Following is related info you referred: 1> Are all the components in your chain (perl, driver manager, driver) all64 bit? [Chunmei]: The unixODBC driver and the DB2 driver are 64bit. Seems that my perl is 32bit from following info. Is this the reason for my error The chance for it is near 100% Can you use either 32-bit lib for DB2 and unixODBC or rebuild your perl using 64bit? unixus...@dsliaa05 #> file perl perl: executable (RISC System/6000) or object module [...] Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Locally applied patches: IndigoPerl Build 804 Built under aix Compiled at Feb 9 2003 13:22:48 [...] 4> I think it could be helpful (if no one else has a better proposal) to start fresh and record the entire make output in a file [Chunmei]: I did it, but I didn't get any error when run 'make': a) perl Makefile.PL Warning: LD_LIBRARY_PATH doesn't include /home/eng-sm/unixuser/claire/test/perl/unixodbc_install2.3.0_64/ [Chunmei]: the warning is strange. Even I set this environment to include this directory, it still report such warning. Meanwhile, I think AIX didn't use this environment but LIBPATH. WARNING: NO_META is not a known parameter. Please do not guess which information we need - please attache the entire log as I told you. The warning is useful to add a patch to the Makefile.PL to recognize LIBPATH on AIX, but nothing else b) make NO warning. What -L paths? What RPATH are used. Are some previous RPATH are overwritten by later options? What compiler/linker flags where used? I think, all DBD's should include the links to http://www.catb.org/~esr/faqs/smart-questions.html and http://www.chiark.greenend.org.uk/~sgtatham/bugs.html ... c) make test The error 'can't load library...' occur. 5> Looks to me like libperl.a is missing from the requirements list of ODBC.so. As long you don't have statically linked the perl runtime, this could be an issue. [Chunmei]: Following command is used to create ODBC.so: LD_RUN_PATH="/home/eng-sm/unixuser/claire/test/perl/unixodbc_install2.3.0_64/lib" ld -bhalt:4 -bM:SRE -bI:/vobs/vob_src_3rdparty/src/3rdparty/perl2exe/aix/perl2exe/perl5.8/lib/5.8.0/aix/CORE/perl.exp -bE:ODBC.exp -bnoentry -lC -lc ConvertUTF.o ODBC.o dbdimp.o unicode_helper.o -o blib/arch/auto/DBD/ODBC/ODBC.so -L/home/eng-sm/unixuser/claire/test/perl/unixodbc_install2.3.0_64/lib -lodbc No error reports during the build and the ldd also is ok. Probably. 6> Maybe it is only a question of dynamic loaded libraries not included in the search path. If I remember well there is a LD_LIBRARY_PATH variable you can add locations where to search libraries to be loaded when executing the program. [Chunmei]: AIX uses LIBPATH instead of LD_LIBRARY_PATH to search libraries. The value of $LIBPATH is "/home/eng-sm/unixuser/claire/test/perl/unixodbc_install2.3.0_64//lib:/usr/lib:/lib:/opt/IBM/db2/V9.7/lib64" in my environment. Jens
RE: make test: dlopen error :can't load library ODBC.so
Hi Martin, Reinhard and Jens, Thanks for your advice. Following is related info you referred: 1> Are all the components in your chain (perl, driver manager, driver) all64 bit? [Chunmei]: The unixODBC driver and the DB2 driver are 64bit. Seems that my perl is 32bit from following info. Is this the reason for my error unixus...@dsliaa05 # > file perl perl: executable (RISC System/6000) or object module 2> What does perl -V output? Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=aix, osvers=4.1.4.0, archname=aix uname='aix cyclops 1 4 00051664a000 ' config_args='-des -dcf_email=supp...@indigostar.com -dperladmin=supp...@indigostar.com -Dcf_by=IndigoSTAR -Uinstallusrbinperl' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=16384 -qnoansialias', optimize='-O', cppflags='' ccversion='3.1.3.3', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4 alignbytes=8, prototype=define Linker and Libraries: ld='ld', ldflags ='' libpth=/lib /usr/lib /usr/ccs/lib libs=-ldbm -lld -lm -lC -lc -lbsd -lPW perllibs=-lld -lm -lC -lc -lbsd -lPW libc=, so=a, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_aix.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -bE:/opt/lib/perl5/5.8.0/aix/CORE/perl.exp' cccdlflags=' ', lddlflags='-bhalt:4 -bM:SRE -bI:$(PERL_INC)/perl.exp -bE:$(BASEEXT).exp -bnoentry -lC -lc' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Locally applied patches: IndigoPerl Build 804 Built under aix Compiled at Feb 9 2003 13:22:48 %ENV: PERL5LIB="/vobs/siebel/src/3rdparty/perl5.8/aix/lib/site_perl/5.8.0:/vobs/siebel/src/3rdparty/perl5.8/aix/lib/site_perl/5.8.0/aix/auto/DBI/" PERLHOME="/vobs/siebel/src/3rdparty/perl5.8/aix" @INC: /vobs/siebel/src/3rdparty/perl5.8/aix/lib/site_perl/5.8.0/aix /vobs/siebel/src/3rdparty/perl5.8/aix/lib/site_perl/5.8.0 /vobs/siebel/src/3rdparty/perl5.8/aix/lib/site_perl/5.8.0/aix/auto/DBI/ /vobs/siebel/src/3rdparty/perl5.8/aix/lib/5.8.0/aix /vobs/siebel/src/3rdparty/perl5.8/aix/lib/5.8.0 /vobs/siebel/src/3rdparty/perl5.8/aix/lib/site_perl/5.8.0/aix /vobs/siebel/src/3rdparty/perl5.8/aix/lib/site_perl/5.8.0 /opt/lib/perl5/site_perl . 3> What ODBC driver manager are you using? [Chunmei]: UnixODBC 2.3.0 4> I think it could be helpful (if no one else has a better proposal) to start fresh and record the entire make output in a file [Chunmei]: I did it, but I didn't get any error when run 'make': a) perl Makefile.PL Warning: LD_LIBRARY_PATH doesn't include /home/eng-sm/unixuser/claire/test/perl/unixodbc_install2.3.0_64/ [Chunmei]: the warning is strange. Even I set this environment to include this directory, it still report such warning. Meanwhile, I think AIX didn't use this environment but LIBPATH. WARNING: NO_META is not a known parameter. b) make NO warning. c) make test The error 'can't load library...' occur. 5> Looks to me like libperl.a is missing from the requirements list of ODBC.so. As long you don't have statically linked the perl runtime, this could be an issue. [Chunmei]: Following command is used to create ODBC.so: LD_RUN_PATH="/home/eng-sm/unixuser/claire/test/perl/unixodbc_install2.3.0_64/lib" ld -bhalt:4 -bM:SRE -bI:/vobs/vob_src_3rdparty/src/3rdparty/perl2exe/aix/perl2exe/perl5.8/lib/5.8.0/aix/CORE/perl.exp -bE:ODBC.exp -bnoentry -lC -lc ConvertUTF.o ODBC.o dbdimp.o unicode_helper.o -o blib/arch/auto/DBD/ODBC/ODBC.so -L/home/eng-sm/unixuser/claire/test/perl/unixodbc_install2.3.0_64/lib -lodbc No error reports during the build and the ldd also is ok. 6> Maybe it is only a question of dynamic loaded libraries not included in the search path. If I remember well there is a LD_LIBRARY_PATH variable you can add locations where to search libraries to be loaded when executing the program. [Chunmei]: AIX uses LIBPATH instead of LD_LIBRARY_PATH to search libraries. The value of $LIBPATH is "/home/eng-sm/unixuser/claire/test/perl/unixodbc_install2.3.0_64//lib:/usr/lib:/lib:/opt/IBM/db2/V9.7/lib64" in my environment. Thanks, Chunmei Wu -Original Message- From: Jens Rehsack [mailto:rehs...@googlemail.com] Sent: 2010年5月10日 14:06 To: dbi-dev@perl.org Subject: Re: make test: dlopen error :can'
t/40profile.t bugs on NetBSD-5.99.24
Hi Tim, after resync my changes with svn repo, I regen Makefile and do "make test" again to see, if any new conflicts came in. I got errors from t/40profile.t - where I'm sure that I don't touch lib/DBI/Profile* I attach the output of the test - if it's not enough, please tell me which information I can provide or when I should debug it on my machine. Jens 40profile.log Description: Binary data
