Hi Jonathan,
Thank you for your response.
the DBD I was referring to was DBD::Sybase. I had an earlier post to
the list titled..
trouble loading DBD::Sybase 1.05 on tiger, MacOSX 10.4.4
The original post contains a complete copy of the output from the both
the DBi and DBD::Sybase perl Makefile.pm, make, and make test.
If an upgraded version of perl with DBI and DBD loaded remains
functional under Tiger, then I may be able to copy the relevent files
over to a Tiger machine; although I would like be able to do an install
on the tiger machine directly.
Again, thanks for your help,
terry
Jonathan Leffler wrote:
On 2/6/06, Terence J. Young, D.C. <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi Jonathan
We have loaded Tiger onto several machines here.
My production machine still uses 10.39 and I am afraid to upgrade
because of the problems we are seeing trying to install the DBI
and DBD
modules onto our upgraded tiger machines.
On my notebook at home, I upgraded to 10.4 over the weekend. I
already
had DBI and DBD installed in perl on the 10.39 MacOSX. It ported
well.
However, I tried doing the perl Makefile.pm <http://Makefile.pm>,
make and make test as a
user and have seen some errors I don't remember seeing when I run the
same on macOsX 10.39. In particular..
I see the following when executing make test against the DBI install
files (version 4.8)
boehme:~/DBi-1.48 boehme$ make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e"
"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/01basics............ok
4/131 skipped: developer tests
t/02dbidrv............ok
t/03handle............ok
t/04mods..............ok
t/05thrclone..........ok
t/06attrs.............ok
t/07kids..............ok
t/08keeperr...........ok
t/09trace.............ok
t/10examp.............ok
t/11fetch.............ok
t/14utf8..............ok
t/15array.............ok
t/20meta..............ok
t/30subclass..........ok
t/40profile...........ok
t/41prof_dump.........ok
t/42prof_data.........ok
t/50dbm...............ok 15/33Argument "2.121_02" isn't numeric in
subroutine entry at /System/Library/Perl/Extras/5.8.6/MLDBM/
Serializer/Data/Dumper.pm line 5
That's a minor problem (the test passed, after all) and is apparently
because you have a non-official release of some piece of software
(2.121_02 of something) instead of a full release version (no
underscore). The same failure occurs with the Pure Perl test zz50dbm.
That is not something I'd worry about - unless you are sure you're
using the functionality. And, even then, I'd probably not worry about it.
....other stuff here
t/zvpp_10examp........ok
39/253 skipped: various reasons
t/zvpp_11fetch........ok 16/16Warning: something's wrong at t/
zvpp_11fetch.t line 3.
......other stuff here
t/zvpp_50dbm..........ok 15/33Argument " 2.121_02" isn't numeric in
subroutine entry at /System/Library/Perl/Extras/5.8.6/MLDBM/
Serializer/Data/Dumper.pm line 5
t/zvpp_50dbm..........ok
t/zvpp_60preparse.....skipped
all skipped: preparse not supported for DBI::PurePerl
t/zvpp_80proxy........skipped
all skipped: modules required for proxy are probably not
installed (e.g., RPC/PlClient.pm)
All tests successful, 8 tests and 133 subtests skipped.
Files=43, Tests=2244, 35 wallclock secs ( 22.14 cusr + 3.75 csys =
25.89 CPU)
PERL_DL_NONLAZY=1 /usr/bin/perl "-Iblib/lib" "-Iblib/arch" test.pl
test.pl
DBI test application $Revision: 11.7 $
Switch: DBI 1.48 by Tim Bunce, 1.48
Available Drivers: DBM, ExampleP, File, Proxy, Sponge
dbi:ExampleP:: testing 5 sets of 20 connections:
Connecting... 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Disconnecting...
Connecting... 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Disconnecting...
Connecting... 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Disconnecting...
Connecting... 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Disconnecting...
Connecting... 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Disconnecting...
Made 100 connections in 0 wallclock secs ( 0.04 usr + 0.00 sys =
0.04 CPU)
Testing handle creation speed...
6060 NullP sth/s perl 5.008006 darwin-thread-multi-2level (gcc 3.3
-Os)
test.pl done
Notice that the last line refs gcc 3.3; but the makefile refs CC to cc
which is a symlink to gcc-4.0.
It took me a while to spot what you were referring to - but yes, I do
see that.
If this was C++, then we'd have a lot to worry about. Given that it
is C, you probably don't.
Certainly, the tests all passed - you got two warnings, but those are
most likely related to a non-DBI/DBD module. I would install and use
the compiled code without qualms.
I tried modifying the CC ref to gcc-3.3 in the makefile; but it
made no
difference.
It is essentially impossible (OK; I exaggerate; too hard to be worth
bothering with) to change the compiler used by Perl. You're better
off rebuilding from scratch (it'll be quicker). Or dinking with the
setup s
Are the errors I am seeing in the make test harmless??
Yes - 99.7% probability.
When I do the make Makefile.pm <http://Makefile.pm> , make and
make test against DBD1.05_2 and
DBD1.07, my make test totally fails.
There is no module DBD -- there might be a DBD::Xyz for any of a large
number of different values of Xyz. You should identify the actual
database driver (DBD) precisely.
I believe if perl had DBi and DBD already installed before
upgrading to
Tiger, they remain functional ( I have yet to test this; but I
believe
it to be so). However, I can't upgrade them or install them on a
machine that doesn't have them after upgrading to Tiger. i am not
sure
if the problems installing the DBD don't have something to do with the
install of DBI silently going bad.
Are you using the system-supplied Perl? Can you choose not to? If
so, you can install stuff easily enough.
If you feel you must use and modify the system Perl (not something I'd
risk doing - I'd far rather have my own version for my purposes,
leaving the system version to the system for its purposes), then you
may have problems if you can't recompile on the target system. In
theory, if you can work out which files were compiled, you can copy
those to the relevant place on the target. In practice, this isn't as
easy as maybe it should be; Perl doesn't really have a utility built
into ExtUtils::MakeMaker for creating an image of the built module
ready for installation on an arbitrary number of target machines -
with or without relocation of the Perl directories.
Jonathan Leffler wrote:
>On 2/6/06, Terence J. Young, D.C. < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
>
>>I am have trouble loading DBI, and DBD modules on Tiger. I
upgraded to
>>tiger from 10.3.9.
>>
>>perl -V indicates that perl was complied from gcc 3.3xxx. Is
there a
>>problem trying to do an install of DBI using gcc 4.0??
>>
>>The tiger Developer files come with both gcc 3.3 and gcc4.0. If
I have
>>to use gcc-3.3, how do I execute the perl Makefile.pm
<http://Makefile.pm>, make and make
>>test against DBI to use gcc-3.3 instead of gcc-4.0
>>
>>Both cc and gcc symlinks to gcc-4.0 in /usr/bin.
>
>What sort of trouble? I don't have access to my 10.4.4 machine
from the
>office, but I have my own version of Perl and I don't think I
rebuilt it
>after installing Tiger - nor have I run into trouble with
it. What I don't
>recall is which version of gcc I used to build it; I have
sometimes upgraded
>GCC independently of Apple's code (though I'm currently using
Xcode 2.2).
>
>If you need to use gcc-3.3 instead, but Perl identifies its
compiler (in
>'perl -V' output) as 'gcc', then you'll have to rework thing so
that gcc
>maps to gcc-3.3 -- either by creating a symlink gcc in (for example)
>$HOME/bin (assuming $HOME/bin appears before /usr/bin on your
PATH) or by
>replacing the symlink in /usr/bin at least temporarily.
--
Jonathan Leffler <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> #include <disclaimer.h>
Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org
"I don't suffer from insanity - I enjoy every minute of it."
