Re: DBD::Informix -- Error Installing On Mac OSX

Beware: prejudices on display. You were warned.

On Sun, Nov 2, 2008 at 2:15 PM, InDeep <indeep@xxxxxxxxxx> wrote:
Clive Eisen wrote:
Clive Eisen wrote:
Jonathan Leffler wrote:

<snip>

Download Perl 5.10.0 from www.perl.com or any other appropriate
source. Compile with the Apple version of GCC - you could set the C
compiler to 'cc -m64' to ensure that Perl is built as a 64-bit system.
You'll also need to reinstall DBI - and any other modules that you
need. And don't install it in the system locations. (I keep my copy
under $HOME/perl/ -- but since I have a 32-bit PPC Mac, I don't get to
play with CSDK or IDS on it.)

Has anyone successfully built a 64 bit perl on OSX? I've tried and I
get just over 1000 errors on make test -
all relate to loading XS stuff and getting a wrong architecture error.

All I did (to be fair) was ./Configure -Dcc='cc -m64' -des

make && make test

If anyone has the magic incantation to build a 64bit perl so I can
build DBD::Informix against the 64bit SDK that would be great.

Sorry to reply to my own post, but I have solved the problem - so for
anyone else here goes

#First download perl source - I used 5.10.0
#untar or unzip as required
#cd into the perlsourcedir/hints and
rm -f darwin.sh
#then
rsync rsync://ftp.linux.activestate.com/perl-current/hints/darwin.sh .
#This gets the bleeding edge darwin hints file that finally supports a
64 bit build on OSX
cd ..
./Configure -Dcc='cc -m64' -Duse64bitall -des
make && make test && make install

#Now you have a 64bit perl in /usr/local/bin that you can link with the
64bit SDK

#Only other thing to note is that on OSX LD_LIBRARY_PATH is called
# DYLD_LIBRARY_PATH
#so you will need to do the following
export DYLD_LIBRARY_PATH=$INFORMIXDIR/lib/esql/:$INFORMIXDIR/lib/
#before running
/usr/local/bin/perl Makefile.PL
#in the DBD::Informix source dir

I thanked Clive privately by responding to a private copy of his message.
I'll now thank Clive publicly -- I do appreciate what he has done.

Thank you, Clive.


InDeep said:
Thanks for this... I got a moment to install Perl 5.10 today on my Mac Mini
using your instructions...haven't tried it on my MacBookPro just yet.

Your notes were a big help so very much appreciated! Meddling with Mac is
a bit scary since it's not widely known what to do if you screw something up.

Perl installed ok. No issues.

DBD::Informix installed but I actually had to go in and install it manually
because it fails if you don't supply a database, user and password for Informix
ahead of time.

Or have the default already setup. Yes. It does; it will; it isn't
likely to change on that score.

It would be good to see DBD::Informix set up with the following defaults or
a prompt or at least some doc to tell you to do this before running cpan:

DBD::Informix will not prompt for anything while I'm its guardian.

I hate the modules that prompt for things - they are a complete
nuisance. I don't mind modules being verbose; that's OK. I don't
mind things failing because I've not read the documentation and set
the environment correctly, as long as the module reasonably clearly
diagnoses the issue. I believe the DBD::Informix is reasonably clear
about needing to read the README file -- let me know if you disagree.

(I take it as read that if I try something from CPAN and it fails to
install but does tell me to read the README file, there are some
complex pre-requisites that I need to know about.)

Before running /usr/local/bin/perl -MCPAN -e 'install Bundle::DBD::Informix'
set your environment to something like this:

Yes, you need a working Informix environment, including a stores
database that you can both connect to and use with DBA (minimum,
RESOURCE) privileges without supplying user name or password, or you
need to set the environment variables to use it. This is part of the
README that you are emphatically encouraged to read when anything goes
wrong.

Even Mac users are expected to read the README. Sorry, but if you
don't know what the pre-requisites are, you are on a hiding to
nothing.

DBD::Informix does its best to deal with you. You have to take a
minimal step in the right direction.

export INFORMIXSERVER=demo_on
export INFORMIXDIR="/Applications/IBM/informix"
export ONCONFIG=onconfig.demo_on
export INFORMIXSQLHOSTS="/Applications/IBM/informix/etc/sqlhosts.demo_on"
export PATH=${INFORMIXDIR}/bin:${PATH}
export INFORMIXTERM=terminfo
export TERMCAP=/opt/informix/etc/termcap
export DYLD_LIBRARY_PATH=$INFORMIXDIR/lib/esql/:$INFORMIXDIR/lib/

DBD::Informix does not need ONCONFIG, INFORMIXTERM or TERMCAP set.
INFORMIXSQLHOSTS is only needed if you aren't using the standard
location ($INFORMIXDIR/etc/sqlhosts) -- that's the same everywhere.
INFORMIXDIR is only needed if you aren't using the standard location
-- that too is the same on Unix machines (/usr/informix).
INFORMIXSERVER is mandatory - period.

DYLD_LIBRARY_PATH is the analog of SHLIB_PATH or LD_LIBRARY_PATH or
LIBPATH or ... and does need to be set. Again, there is nothing
unusual in this. If you can't compile and run ESQL/C programs with
the environment you have set, you are not going to be able to compile
the Perl module, which is, when all is said and done, an ESQL/C
program.

I suppose it might be possible to detect that the variable isn't set,
but there are circumstances under which it does not have to be set
(appropriate settings in /etc/ld.so.conf on Linux, for example). So,
it is better, from my perspective, to require that people have a
working Informix environment than to test for things that might not be
needed. If you want more diagnostics after a failure to test, then
provide a patch. Do not provide a patch that is interactive; I will
not accept it.

DBD install variables:

export DBI_DBNAME=sysmaster

I've only ever used that as a last resort - if none of the more
specific DBD_INFORMIX_* environment variables are set.

export DBD_INFORMIX_DATABASE=sysmaster
export DBD_INFORMIX_USERNAME=informix
export DBD_INFORMIX_PASSWORD=informix

There is no way on earth that I am ever going to encourage anyone to
use either the sysmaster database or the informix user to install
DBD::Informix.

Absolutely none.

If anything, I would add a proscription from attempting it -- or any
sys* database.

Or how about a prompt? 8o/

No.

This way it work better since there is no stores database
installed with the IDS Developers' Edition.

It doesn't have to be a stores database -- you get to select the database.

If you read the README file.

Also the following seems to be Mac-specific:

I have had issues getting the Informix environment to work inside Perl
scripts without first using a shell environment script. I'm not sure what I'm
doing wrong. I'd like to get the Perl scripts to work without first sourcing
in an environment file.

This works fine on Linux, but on Mac it's not working...

If I dot-in the environment file, my Perl scripts connect fine to Informix
but without dotting-in the environment it just won't work. I'm not sure
what the problem is but it's definitely Mac-only.


shell settings:

export INFORMIXSERVER=demo_on
export INFORMIXDIR="/Applications/IBM/informix"
export ONCONFIG=onconfig.demo_on
export INFORMIXSQLHOSTS="/Applications/IBM/informix/etc/sqlhosts.demo_on"
export PATH=${INFORMIXDIR}/bin:${PATH}
export INFORMIXTERM=terminfo
export TERMCAP=/opt/informix/etc/termcap
export DYLD_LIBRARY_PATH=$INFORMIXDIR/lib/esql/:$INFORMIXDIR/lib/
export DBI_DBNAME=sysmaster
export DBD_INFORMIX_DATABASE=sysmaster
export DBD_INFORMIX_USERNAME=informix
export DBD_INFORMIX_PASSWORD=informix

Note that once DBD::Informix is tested, there is no further use made
of DBD_INFORMIX_DATABASE, DBD_INFORMIX_USERNAME, or
DBD_INFORMIX_PASSWORD. They are purely test artefacts.

Here's my informix.env.pl:


#!/usr/local/bin/perl
################################################################################

$ENV{'ONCONFIG'} = "onconfig.demo_on" ;
$ENV{'INFORMIXSERVER'} = "demo_on" ;
$ENV{'INFORMIXDIR'} = "/Applications/IBM/informix" ;
$ENV{'INFORMIXSQLHOSTS'} = $ENV{'INFORMIXDIR'} . "/etc/sqlhosts.demo_on" ;

$ENV{'DYLD_LIBRARY_PATH'} = $ENV{'INFORMIXDIR'} . "/lib/esql/:" . $ENV{'INFORMIXDIR'} . "/lib/" ;

$ENV{'LD_LIBRARY_PATH'} = $ENV{'DYLD_LIBRARY_PATH'} ;
$ENV{'PATH'} = $ENV{'INFORMIXDIR'} . "/bin:" . $ENV{'LD_LIBRARY_PATH'} . ":" .
$ENV{'DYLD_LIBRARY_PATH'} . ":/usr/local/lib/:" . $ENV{'PATH'} ;

$ENV{'TERMCAP'} = $ENV{'INFORMIXDIR'} . "/etc/termcap" ;
$ENV{'INFORMIXTERM'} = "terminfo" ;
$ENV{'DBI_DBNAME'} = "sysmaster" ;
$ENV{'DBD_INFORMIX_DATABASE'} = "sysmaster" ;

$DB_USER = "informix" ;
$DB_PASS = "informix" ;

To get the environment to work, you need to have the main environment
variables (INFORMIXSERVER, etc) set before you invoke DBI->connect().

The one exception to this is typically LD_LIBRARY_PATH (or, on MacOS
X, DYLD_LIBRARY_PATH); that must be set before the dynamic loader
reads the environment, because it only reads the environment once.

Now, the build process for DBD::Informix does try to build the
Informix.so (?Informix.dylib?) module with the absolute pathname of
the Informix shared libraries, unless you take steps to avoid it doing
so. So, on Linux and Solaris, you don't need LD_LIBRARY_PATH set once
DBD::Informix is built. This allows Apache and root-run processes to
use it with a minimum of fuss. I have not had a chance to check
whether that applies on MacOS X -- as I stated earlier (in a prior
email), I don't have an Intel Mac to play with at the moment. I could
find one via the office, but I don't have my own -- and yes, it hurts.


if ( $ARGV[0] ) { showenv(); }


################################################################################

sub showenv {

foreach $key (sort keys(%ENV))
{
printf( "%30s = %s\n", $key , $ENV{$key} );
}

}
1;

If you wrapped that as a module and "use'd" it or "require'd" it, you
might be OK, though you might still have the DYLD_LIBRARY_PATH issue
to address.

The exec trick that Clive showed is symptomatic of "DYLD_LIBRARY_PATH
must be set before the dynamic loader is run".

(Part of the issue here is whether it is sensible or fair to assume
that Informix environment variables should be set for every user on
the machine at all times or not. My inclination is to assume not; but
that is grounded in a plain Unix background, plus the requirement that
I can run any of half-a-dozen versions of IDS in different
INFORMIXDIRs. My requirements are not standard, though -- most people
run just one version of IDS. If you have insights into how the
Informix environment can be set sensibly on MacOS X, I'll listen.
Beware: over and above all the other prejudices showing above, I'm not
convinced that it is good to default to demo_on as the server name or
the demo sub-directory as the chunk storage location. It might be
something that would help beginners; it would probably annoy the more
experienced people. Sure as eggs are eggs, I don't use that name or
location for any length of time at all.)

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@xxxxxxxxxxxxx, jleffler@xxxxxxxxxx
Guardian of DBD::Informix v2008.0513 -- http://dbi.perl.org/
"Blessed are we who can laugh at ourselves, for we shall never cease
to be amused."
NB: Please do not use this email for correspondence.
I don't necessarily read it every week, even.
.

Relevant Pages

  • Re: DBD::Informix -- Error Installing On Mac OSX
    ... the environment correctly, as long as the module reasonably clearly ... working Informix environment than to test for things that might not be ... use either the sysmaster database or the informix user to install ...
    (comp.databases.informix)
  • Re: AGAIN: how can I install modules if Im not root?
    ... environment as both cause problems when values set for one case end up being ... claim that environment variables are bad, ... *global* variable you have just screwed up any other perl on the system. ... Likewise on make and make install command ...
    (comp.lang.perl.moderated)
  • Re: AGAIN: how can I install modules if Im not root?
    ... an environment variable for setting @INC which behaves as -Mlib ... during Perl configure. ... [Oh - and I never install manpages. ... OK - that situation mya not obtain in the environment you are thinking of, but it *can* obtain - *did* ...
    (comp.lang.perl.moderated)
  • Re: How to install module when I am not allowed to install moudule in system directory?
    ... network - the administor does not allow me install this module ... the book "SAMS Teach Yourself Perl in 24 hours" Appendix A P431. ... There's nothing stopping you from using the CPAN shell on windows. ... this environment you can always try building the modules on your own ...
    (comp.lang.perl.misc)
  • Re: How to install module when I am not allowed to install moudule in system directory?
    ... network - the administor does not allow me install this module ... the book "SAMS Teach Yourself Perl in 24 hours" Appendix A P431. ... There's nothing stopping you from using the CPAN shell on windows. ... this environment you can always try building the modules on your own ...
    (comp.lang.perl.misc)