SEO

Hi,

I have successfully installed and configured InformixBI and now,
when I am installing InformixBD, I am getting the following errors:

$ perl Makefile.PL

Configuring IBM Informix Database Driver for Perl Version 2003.04
(2003-03-05) (aka DBD::Informix)
You are using DBI version 1.43 and Perl version 5.006001
Remember to actually read the README file!

Perl: perl5.006001 sun4-solaris dl_dlopen.xs
System: sunos solaris 5.8 generic sun4u sparc sunw,ultra-5_10
Compiler: gcc -O -fno-strict-aliasing -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64

Using IBM Informix CSDK Version 2.81, IBM Informix-ESQL Version
9.53.FC2R1 from /usr/informix

Beware: DBD::Informix is not yet aware of all the new IUS data types.

Assert macro will be disabled!

lib/DBD/Informix/Defaults.pm written OK
esqlvrsn.h written OK
esqlinfo.h written OK

Testing whether your Informix test environment will work...
gcc: language arch=v9 not recognized
gcc: esqltest.c: linker input file unused since linking not done
gcc: language arch=v9 not recognized
gcc: esqlc_v6.c: linker input file unused since linking not done
gcc: esqlc_v6.o: No such file or directory
gcc: language arch=v9 not recognized
gcc: language arch=v9 not recognized
Failed to link test program esqltes

For ESQL/C, I am using Sun C Compiler, not the gcc. How can, I
override this gcc compiler and force to use Sun C compiler.

Thanks
MAZ

MAZ wrote:
> I have successfully installed and configured InformixBI and now,
> when I am installing InformixBD, I am getting the following errors:
>
> $ perl Makefile.PL
>
> Configuring IBM Informix Database Driver for Perl Version 2003.04
> (2003-03-05) (aka DBD::Informix)
> You are using DBI version 1.43 and Perl version 5.006001
> Remember to actually read the README file!
>
> Perl: perl5.006001 sun4-solaris dl_dlopen.xs
> System: sunos solaris 5.8 generic sun4u sparc sunw,ultra-5_10
> Compiler: gcc -O -fno-strict-aliasing -I/usr/local/include
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
>
> Using IBM Informix CSDK Version 2.81, IBM Informix-ESQL Version
> 9.53.FC2R1 from /usr/informix
>
> Beware: DBD::Informix is not yet aware of all the new IUS data types.
>
> Assert macro will be disabled!
>
> lib/DBD/Informix/Defaults.pm written OK
> esqlvrsn.h written OK
> esqlinfo.h written OK
>
> Testing whether your Informix test environment will work...
> gcc: language arch=v9 not recognized
> gcc: esqltest.c: linker input file unused since linking not done
> gcc: language arch=v9 not recognized
> gcc: esqlc_v6.c: linker input file unused since linking not done
> gcc: esqlc_v6.o: No such file or directory
> gcc: language arch=v9 not recognized
> gcc: language arch=v9 not recognized
> Failed to link test program esqltes
>
> For ESQL/C, I am using Sun C Compiler, not the gcc. How can, I
> override this gcc compiler and force to use Sun C compiler.

Your Perl was compiled using GCC - the version isn't clear from the
information provided, but doesn't matter very much. It is next door
to impossible to rejig the Perl build process to use the Sun C
Compiler instead. At one time, there was a module for doing the
inverse operation - fixing a Perl built with Sun C Compiler so that it
could use GCC for the extensions - but I don't know whether that is
still available (it doesn't show up on CPAN as far as I can tell).

Frankly, the easiest thing to do is either rebuild and reinstall Perl
with the compiler you've actually got or get hold of a suitable
version of GCC -- the same as or similar to the one used to build
Perl. Looking at the 'perl -V' output will give you the extra
information.

Where did you get the DBI installation from? I'm surprised that
didn't run into similar issues...though, come to think of it, I'm not
completely surprised. The -xarch=v9 options come from the ESQL/C script.

....hold on...

You have a GCC - it is complaining about the Sun C options. Is your
Perl a 64-bit version? If not, you'll have problems with CSDK
2.81.FC2 (ESQL/C 9.53.FC2) because the ESQL/C library assumes a 64-bit
environment. You'd need to use 'gcc -m64' -- if it complains about
that, you've got real problems. And there is a mechanism - probably
horribly klunkk - for eliminating problematic options. Investigate
the environment in Notes/environment.variables, especially:
* DBD_INFORMIX_DEBUG_ESQLCC
* DBD_INFORMIX_DEBUG_ESQLLD
* DBD_INFORMIX_ESQLCC_REMOVE_OPTIONS_REGEX
* DBD_INFORMIX_ESQLLD_REMOVE_OPTIONS_REGEX

There are illustative uses in the notes. Since GCC was used to build
Perl, the only issue is whether you have a 32-bit or 64-bit Perl.
Given the version of Perl, I suspect you have a 32-bit build, and you
would therefore need to use the 32-bit version of CSDK. That would
also mean that you can't use shared memory connections to connect your
Perl + DBI + DBD::Informix to your 64-bit IDS (9.xx.Fyz).

[That test still pays for itself many times over. It heads off so
many problems before you get Perl directly involved it isn't true.]

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

Jonathan Leffler <jleffler@earthlink.net> wrote in message news:<41466B2D.9010504@earthlink.net>...
> MAZ wrote:
> > I have successfully installed and configured InformixBI and now,
> > when I am installing InformixBD, I am getting the following errors:
> >
> > $ perl Makefile.PL
> >
> > Configuring IBM Informix Database Driver for Perl Version 2003.04
> > (2003-03-05) (aka DBD::Informix)
> > You are using DBI version 1.43 and Perl version 5.006001
> > Remember to actually read the README file!
> >
> > Perl: perl5.006001 sun4-solaris dl_dlopen.xs
> > System: sunos solaris 5.8 generic sun4u sparc sunw,ultra-5_10
> > Compiler: gcc -O -fno-strict-aliasing -I/usr/local/include
> > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> >
> > Using IBM Informix CSDK Version 2.81, IBM Informix-ESQL Version
> > 9.53.FC2R1 from /usr/informix
> >
> > Beware: DBD::Informix is not yet aware of all the new IUS data types.
> >
> > Assert macro will be disabled!
> >
> > lib/DBD/Informix/Defaults.pm written OK
> > esqlvrsn.h written OK
> > esqlinfo.h written OK
> >
> > Testing whether your Informix test environment will work...
> > gcc: language arch=v9 not recognized
> > gcc: esqltest.c: linker input file unused since linking not done
> > gcc: language arch=v9 not recognized
> > gcc: esqlc_v6.c: linker input file unused since linking not done
> > gcc: esqlc_v6.o: No such file or directory
> > gcc: language arch=v9 not recognized
> > gcc: language arch=v9 not recognized
> > Failed to link test program esqltes
> >
> > For ESQL/C, I am using Sun C Compiler, not the gcc. How can, I
> > override this gcc compiler and force to use Sun C compiler.
>
> Your Perl was compiled using GCC - the version isn't clear from the
> information provided, but doesn't matter very much. It is next door
> to impossible to rejig the Perl build process to use the Sun C
> Compiler instead. At one time, there was a module for doing the
> inverse operation - fixing a Perl built with Sun C Compiler so that it
> could use GCC for the extensions - but I don't know whether that is
> still available (it doesn't show up on CPAN as far as I can tell).
>
> Frankly, the easiest thing to do is either rebuild and reinstall Perl
> with the compiler you've actually got or get hold of a suitable
> version of GCC -- the same as or similar to the one used to build
> Perl. Looking at the 'perl -V' output will give you the extra
> information.
>
> Where did you get the DBI installation from? I'm surprised that
> didn't run into similar issues...though, come to think of it, I'm not
> completely surprised. The -xarch=v9 options come from the ESQL/C script.
>
> ...hold on...
>
> You have a GCC - it is complaining about the Sun C options. Is your
> Perl a 64-bit version? If not, you'll have problems with CSDK
> 2.81.FC2 (ESQL/C 9.53.FC2) because the ESQL/C library assumes a 64-bit
> environment. You'd need to use 'gcc -m64' -- if it complains about
> that, you've got real problems. And there is a mechanism - probably
> horribly klunkk - for eliminating problematic options. Investigate
> the environment in Notes/environment.variables, especially:
> * DBD_INFORMIX_DEBUG_ESQLCC
> * DBD_INFORMIX_DEBUG_ESQLLD
> * DBD_INFORMIX_ESQLCC_REMOVE_OPTIONS_REGEX
> * DBD_INFORMIX_ESQLLD_REMOVE_OPTIONS_REGEX
>
> There are illustative uses in the notes. Since GCC was used to build
> Perl, the only issue is whether you have a 32-bit or 64-bit Perl.
> Given the version of Perl, I suspect you have a 32-bit build, and you
> would therefore need to use the 32-bit version of CSDK. That would
> also mean that you can't use shared memory connections to connect your
> Perl + DBI + DBD::Informix to your 64-bit IDS (9.xx.Fyz).
>
> [That test still pays for itself many times over. It heads off so
> many problems before you get Perl directly involved it isn't true.]


It seems Perl was installed with gcc compiler, below is the output of
perl -V
$ perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 1)
configuration:
Platform:
osname=solaris, osvers=2.8, archname=sun4-solaris
uname='sunos solaris 5.8 generic sun4u sparc sunw,ultra-5_10 '
config_args='-Dcc=gcc -de'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
Compiler:
cc='gcc', ccflags ='-fno-strict-aliasing -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O',
cppflags='-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='2.95.3 20010315 (release)',
gccosandvers='solaris2.8'
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
d_longlong=define, longlongsize=8, d_longdbl=define,
longdblsize=16
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, usemymalloc=y, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib '
libpth=/usr/local/lib /usr/lib /usr/ccs/lib
libs=-lsocket -lnsl -lgdbm -ldb -ldl -lm -lc
perllibs=-lsocket -lnsl -ldl -lm -lc
libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib'


Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under solaris
Compiled at Apr 26 2001 04:07:49
@INC:
/usr/local/lib/perl5/5.6.1/sun4-solaris
/usr/local/lib/perl5/5.6.1
/usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris
/usr/local/lib/perl5/site_perl/5.6.1
/usr/local/lib/perl5/site_perl

Jonathan Leffler wrote:
>>
>> Testing whether your Informix test environment will work...
>> gcc: language arch=v9 not recognized
>
> You have a GCC - it is complaining about the Sun C options. Is your
> Perl a 64-bit version? If not, you'll have problems with CSDK
> 2.81.FC2 (ESQL/C 9.53.FC2) because the ESQL/C library assumes a 64-bit
> environment. You'd need to use 'gcc -m64' -- if it complains about

I had exactly this experience a few weeks ago, and had to temporarily
install a 32 bit engine, CSDK and do a build; since I've not built 64 bit
Perl yet, and it was my first time on Solaris (smokes cigarette).

So, sounds like 64 bit perl is a no-brainer and will link to DBD::Informix.
What are the options to cause a 64 bit build of Perl, or is that too much to
expect off the top of your head? I was worried about the suggestion that
going maximal 64 bit may cause compatibility problems with some modules. If
you are happy and have experience with 64 bit perl then I'll just say YES to
all the questions next time I build?

Andrew Hamm wrote:

> Jonathan Leffler wrote:
>
>>>Testing whether your Informix test environment will work...
>>>gcc: language arch=v9 not recognized
>>
>>You have a GCC - it is complaining about the Sun C options. Is your
>>Perl a 64-bit version? If not, you'll have problems with CSDK
>>2.81.FC2 (ESQL/C 9.53.FC2) because the ESQL/C library assumes a 64-bit
>>environment. You'd need to use 'gcc -m64' -- if it complains about
>
>
> I had exactly this experience a few weeks ago, and had to temporarily
> install a 32 bit engine, CSDK and do a build; since I've not built 64 bit
> Perl yet, and it was my first time on Solaris (smokes cigarette).

Well, you didn't have to install the 32-bit server; you could have
used either oltlitcp or olipcstr connections from the 32-bit CSDK
application (aka Perl + DBI + DBD::Informix) to the 64-bit server.

No harm done - but it wasn't actually necessary unless you've got a
rule about 'only olipcshm connections' that you chose not to break.

> So, sounds like 64 bit perl is a no-brainer and will link to DBD::Informix.

Yes. I do it periodically. Last build was about 5.8.1.

> What are the options to cause a 64 bit build of Perl, or is that too much to
> expect off the top of your head?

I tell it that my C compiler is 'gcc -m64' -- so my response to which
is you C compiler is that, minus the quotes. The main reason I don't
do it all the time in 64-bit is I haven't worked out how to get all
the other libraries I use on occasion built and installed 64-bit.

> I was worried about the suggestion that
> going maximal 64 bit may cause compatibility problems with some modules.

The problem arises if you plan to use a module Xyz::Pqr that was
originally built for say Perl 5.8.2 with your new maximally 64-bit
version of Perl. Actually, that maximally 64-bit stuff really applies
to a 32-bit Perl -- not a 64-bit Perl.

> If you are happy and have experience with 64 bit perl then I'll just
> say YES to
> all the questions next time I build?

You have to know what's the correct way to address any non-ESQL/C
64-bit shared libraries. I always have to exclude /usr/local/* from
my build since /usr/local is automounted (readonly, to boot) and
contains gems such as Perl 5.004 and GCC 2.8.

Yes; I've had no serious issues with 64-bit Perl.

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/