On 12/7/05, Elton Hughes <[EMAIL PROTECTED]> wrote:

> On Dec 6, 2005, at 6:40 PM, Jonathan Leffler wrote:
> > Yes, with caveats.
>
> OK, this make me nervous.



The primary caveats are (1) make sure you don't mess with the version of
Perl provided with the system, and (2) either build your own Perl or make
sure that you have the compiler for the version you download.  The rest can
be managed.

> Presumably you're using Solaris 10?
>
> I work for a non-profit agency with very little money. Our 'parent'
> agency is using Solaris 8 and we are compelled to keep current with
> them. Their plans are to upgrade in the next fiscal year. We will
> follow them at that time.



OK - that explains the 11-year old machine.  Mine will be catching up on
that - it's currently about 7 years old, and running Solaris 8 at 333 MHz.


> I suggest looking hard at building your own Perl rather than using
> > the one distributed by Sun.
>
> I did download and installed the 5.8.5 binary from a site I found on
> Perl.com. I now have two Perls. One at /usr/bin, the original, the
> newer version at /usr/local/bin. This seems to work as /usr/local/bin
> is first in the PATH. Would is make more sense to replace the old
> version with the new?



No - leave /usr/bin/perl alone.  You might break something.

Having /usr/local/bin on your PATH first should be fine - I do that all the
time (well, OK, I choose Perl by setting PATH: I have to ignore
/usr/local/bin since I don't control it because it is a readonly NFS
automount, usually containing archaic software, such as Perl 5.004).

> You need to get CPAN up and running (or CPANPLUS).  That's not too hard:
> >
> > perl -MCPAN -e 'install Bundle::CPAN'


OK - I thought that should work.  Sorry for a bum steer.

Run cpan (or 'perl -MCPAN -e shell') and follow its directions.  It'll
suggest installing Bundle::CPAN.

When I try that, the system responds with "don't know what it is"
> message, followed by "Try the command i /Bundle::CPAN/" to find
> objects with matching identifiers.
>
> > Before installing DBD::Informix, you need a working version of CSDK
> > (ClientSDK).
>
> I think all of the components are working. I can access the data from
> ISQL or from the programs supplied by our parent agency. If the is an
> onstat -something I can run to check it, please let me know.


ISQL working means you have database connectivity - that is good.

You also need, explicitly, CSDK (the ESQL/C component of CSDK).

If you haven't got it, DBD::Informix will tell you - it tries to compile a
test program and won't write Makefile if you don't have a working ESQL/C
setup.

> Working means, primarily, that you can connect to an IDS database
> > whereever
> > you keep the database server, whether on the new Sun box or
> > somewhere else.
> > That piece of configuration is independent of DBD::Informix, and the
> > Makefile.PL script insists that you do it.  (Well, you can override
> > the test
> > - read the documentation; it is not recommended.)
> >
> > If you have a working CSDK, then your outline is fine.
> >
> > (Oh, I assume you have the correct C compiler for your Perl; if
> > not, rebuild
> > Perl with the compiler you do have.)
>
> we are using gcc 2.95, but since I installed the binary, I don't
> think that came into play.



It comes into play if the version of Perl was either built with the Sun
compiler  or was built with a version of GCC that is incompatible with GCC
2.95.   Most likely, you'll be OK if your new (5.8.5) Perl was built with
GCC; if it was built with the Sun compiler, now is the time to build and
install your own version of Perl.  However, GCC 2.95 is quite old (current
is 4.0.x), so if Perl was built with GCC 3.x or 4.0.x, you might conceivably
have problems, though I'd be a little surprised.  The output of 'perl -V'
will give you the information you need.

--
Jonathan Leffler <[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."

Reply via email to