Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Help please with DBD::ODBC on SUSE-Linux
73 views
Skip to first unread message
Martin J. Evans
Aug 15, 2012, 4:06:20 AM8/15/12
to Jeff Tate, dbi-...@perl.org
On 14/08/12 19:05, Jeff Tate wrote:
> I am trying to build a private perl with ODBC connection to a
> Teradata database on SUSE-Linux. Perl build with no errors, DBI
> installed clean, DBD::ODBC compiles seemingly cleanly, but fails
> almost all the tests. So, help will be gratefully accepted.
>
> The attached shows:
>
> ·Relevant environment
Out of interest, why did you choose to use the ODBC driver manager in /opt//teradata/client/ODBC_64 instead of unixODBC installed from a suse package?
> ·Results of ODBC adhoc connect test
>
> oSuccessful
>
> oDeliberately not successful, as it shows driver identification tags
>
> ·cpan results
>
> oget
>
> omake
>
> otest
>
> I installed CPAN::Reporter, so I expect (though am not sure as this
> is new to me) that reports have been posted.
> Thanx in advance for any and all insights (per the admonition, I
> looked for a README.linux to review, but there wasn’t one)
>
> Jeff Tate
So running make test results in a segfault. You have a 64 bit machine and from the names of the dirs where teradata is installed I'm guessing it too is 64 bit shared objects. However, there is nothing in the c compilation which sets the size of SQLLEN and SQLULEN which are /usually/ 64 bits on 64 bit linux and 32 bits on 32 bit linux. If DBD::ODBC was built with 32 bit SQLLEN/SQLULEN and teradata and the driver manager were built with 64 bit SQLLEN/SQLULEN I can well imagine it would end up seg faulting - this is my guess.
Does the /opt/teradata tree contain an odbcinst binary? If it does run /path/odbcinst -j and post the output. If it does not, compile and run the following C code and post the output:
put the following in x.c file:
#include <stdio.h>
#include <sql.h>
main() {
printf("size of SQLLEN is %d\n", sizeof(SQLLEN));
}
compile with:
cc -I/opt/teradata/client/ODBC_64/include x.c
run with ./a.out
What does it output?
The background is that MS changed the ODBC spec when they released 64 bit windows and changed some ODBC APIs to use SQLLEN/SQLULEN when before they used SQLINTEGER/SQLUINTEGER. The former are 32/64 bit depending on architecture and the later are always 32 bit. Before they did this 64 bit Unix existed for ages and stuck to the existing API which was using SQLINTEGERs. This led to confusion and situations like I expect you've hit.
Basically, DBD::ODBC needs to know the size of SQLLEN and it normally does this by running:
odbc_config --cflags
-DHAVE_UNISTD_H -DHAVE_PWD_H -DHAVE_SYS_TYPES_H -DHAVE_LONG_LONG -DSIZEOF_LONG_INT=4 -I/home/martin/unixODBC-2.3.1/include
and adding those flags to the cc line (note the above came from a 32bit machine). However, I cannot know you are really using unixODBC as I've no idea what came with teradata in those dirs.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
> I am trying to build a private perl with ODBC connection to a
> Teradata database on SUSE-Linux. Perl build with no errors, DBI
> installed clean, DBD::ODBC compiles seemingly cleanly, but fails
> almost all the tests. So, help will be gratefully accepted.
>
> The attached shows:
>
> ·Relevant environment
Out of interest, why did you choose to use the ODBC driver manager in /opt//teradata/client/ODBC_64 instead of unixODBC installed from a suse package?
> ·Results of ODBC adhoc connect test
>
> oSuccessful
>
> oDeliberately not successful, as it shows driver identification tags
>
> ·cpan results
>
> oget
>
> omake
>
> otest
>
> I installed CPAN::Reporter, so I expect (though am not sure as this
> is new to me) that reports have been posted.
> Thanx in advance for any and all insights (per the admonition, I
> looked for a README.linux to review, but there wasn’t one)
>
> Jeff Tate
So running make test results in a segfault. You have a 64 bit machine and from the names of the dirs where teradata is installed I'm guessing it too is 64 bit shared objects. However, there is nothing in the c compilation which sets the size of SQLLEN and SQLULEN which are /usually/ 64 bits on 64 bit linux and 32 bits on 32 bit linux. If DBD::ODBC was built with 32 bit SQLLEN/SQLULEN and teradata and the driver manager were built with 64 bit SQLLEN/SQLULEN I can well imagine it would end up seg faulting - this is my guess.
Does the /opt/teradata tree contain an odbcinst binary? If it does run /path/odbcinst -j and post the output. If it does not, compile and run the following C code and post the output:
put the following in x.c file:
#include <stdio.h>
#include <sql.h>
main() {
printf("size of SQLLEN is %d\n", sizeof(SQLLEN));
}
compile with:
cc -I/opt/teradata/client/ODBC_64/include x.c
run with ./a.out
What does it output?
The background is that MS changed the ODBC spec when they released 64 bit windows and changed some ODBC APIs to use SQLLEN/SQLULEN when before they used SQLINTEGER/SQLUINTEGER. The former are 32/64 bit depending on architecture and the later are always 32 bit. Before they did this 64 bit Unix existed for ages and stuck to the existing API which was using SQLINTEGERs. This led to confusion and situations like I expect you've hit.
Basically, DBD::ODBC needs to know the size of SQLLEN and it normally does this by running:
odbc_config --cflags
-DHAVE_UNISTD_H -DHAVE_PWD_H -DHAVE_SYS_TYPES_H -DHAVE_LONG_LONG -DSIZEOF_LONG_INT=4 -I/home/martin/unixODBC-2.3.1/include
and adding those flags to the cc line (note the above came from a 32bit machine). However, I cannot know you are really using unixODBC as I've no idea what came with teradata in those dirs.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
Jeff Tate
Aug 15, 2012, 10:32:50 AM8/15/12
to Martin J. Evans, dbi-...@perl.org
Couldn't find odbcinst. Compiled test code as instructed. Result of a.out
is:
size of SQLLEN is 8
As for decision to install Teradata odbc rather than SUSE odbc, that was
made by the sysadmin team. I am just a user. I will however ask them if
there is the possibility to install unixodbc - is that target neutral or is
there some additional work they would have to do to enable a Teradata
connection.
Thanx
-----Original Message-----
From: Martin J. Evans [mailto:martin...@easysoft.com]
Sent: Wednesday, August 15, 2012 4:06 AM
To: Jeff Tate
Cc: dbi-...@perl.org
Subject: Re: Help please with DBD::ODBC on SUSE-Linux
On 14/08/12 19:05, Jeff Tate wrote:
> I am trying to build a private perl with ODBC connection to a Teradata
> database on SUSE-Linux. Perl build with no errors, DBI installed
> clean, DBD::ODBC compiles seemingly cleanly, but fails almost all the
> tests. So, help will be gratefully accepted.
>
> The attached shows:
>
> .Relevant environment
Out of interest, why did you choose to use the ODBC driver manager in
/opt//teradata/client/ODBC_64 instead of unixODBC installed from a suse
package?
> .Results of ODBC adhoc connect test
>
> oSuccessful
>
> oDeliberately not successful, as it shows driver identification tags
>
> .cpan results
<http://www.easysoft.com> http://www.easysoft.com
is:
size of SQLLEN is 8
As for decision to install Teradata odbc rather than SUSE odbc, that was
made by the sysadmin team. I am just a user. I will however ask them if
there is the possibility to install unixodbc - is that target neutral or is
there some additional work they would have to do to enable a Teradata
connection.
Thanx
-----Original Message-----
From: Martin J. Evans [mailto:martin...@easysoft.com]
Sent: Wednesday, August 15, 2012 4:06 AM
To: Jeff Tate
Cc: dbi-...@perl.org
Subject: Re: Help please with DBD::ODBC on SUSE-Linux
On 14/08/12 19:05, Jeff Tate wrote:
> I am trying to build a private perl with ODBC connection to a Teradata
> database on SUSE-Linux. Perl build with no errors, DBI installed
> clean, DBD::ODBC compiles seemingly cleanly, but fails almost all the
> tests. So, help will be gratefully accepted.
>
> The attached shows:
>
Out of interest, why did you choose to use the ODBC driver manager in
/opt//teradata/client/ODBC_64 instead of unixODBC installed from a suse
package?
>
> oSuccessful
>
> oDeliberately not successful, as it shows driver identification tags
>
Jeff Tate
Aug 15, 2012, 10:41:10 AM8/15/12
to Martin J. Evans, dbi-...@perl.org
Checked at unixodbc.org, and there is no mention of Teradata, so perhaps
that's why it's not installed.
that's why it's not installed.
Martin J. Evans
Aug 15, 2012, 10:50:28 AM8/15/12
to Jeff Tate, dbi-...@perl.org
On 15/08/12 15:32, Jeff Tate wrote:
> Couldn't find odbcinst. Compiled test code as instructed. Result of a.out
> is:
>
>
>
> size of SQLLEN is 8
Ok, so this /should be/ good. It means that compiling DBD::ODBC with those header files means SQLLEN and SQLULEN are 8 bytes in size and one /would hope/ if teradata was compiled the same way it was also using SQLLEN/SQLULEN of 8 bytes. If this is the case my guess is wrong.
> Couldn't find odbcinst. Compiled test code as instructed. Result of a.out
> is:
>
>
>
> size of SQLLEN is 8
BTW, I spoke to lead developer for unixODBC and he thinks the ODBC driver manager that comes with teradata might actually be unixODBC as he had some contact with teradata some time ago.
>
> As for decision to install Teradata odbc rather than SUSE odbc, that was
> made by the sysadmin team. I am just a user. I will however ask them if
> there is the possibility to install unixodbc - is that target neutral or is
> there some additional work they would have to do to enable a Teradata
> connection.
So, the problem remains why is this segfaulting - it gets harder now. I'm kind of tempted to say "ask teradata" but I'll try and give you some suggestions so we might try and track it down.
t/03dbatt.t was the first test to fail so we'll start with this one. Assuming it is unixODBC you are using edit your odbcinst.ini file (/opt/teradata/client/ODBC_64/odbcinst.ini assuming you still have ODBCINSTINI set as in your first post) and at the top add:
[ODBC]
Trace=yes
TraceFile=/tmp/unixodbc.log
Now go to the dir where you are building and running DBD::ODBC test suite and do:
prove -vb t/03dbatt.t
If you are using unixODBC it should write something to /tmp/unixodbc.log. If it does post the last 100 lines.
Do:
which perl
which should output something like:
/usr/bin/perl
then assuming you have gdb (or install it) do:
gdb /usr/bin/perl <---- replace with which output
and at the prompt do:
run -Iblib/lib -Iblib/arch t/03dbatt.t
when it crashes type "bt" for a back trace and post it.
Even if we cannot get a clue from this it will be useful if you go to teradata.
Jeff Tate
Aug 15, 2012, 1:25:24 PM8/15/12
to Martin J. Evans, dbi-...@perl.org
Step 1) added ODBC trace information to odbcinst.ini (made my own copy
(system file)) and change $ODBCINST to address
NO output produced in trace file
Step 2) running test under gdb
Linux:puTest> gdb `which perl`
GNU gdb (GDB) SUSE (7.3-0.6.1)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-suse-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /DCH/homedch/localPerl/bin/perl...done.
(gdb) run -lblib/lib -lblib/arch t/03dbatt.t
Starting program: /DCH/homedch/localPerl/bin/perl -lblib/lib -lblib/arch
t/03dbatt.t
Missing separate debuginfo for /lib64/ld-linux-x86-64.so.2
Try: zypper install -C
"debuginfo(build-id)=c1807b5762068e6c5f4a6a0ed48d9d4469965351"
Missing separate debuginfo for /lib64/libnsl.so.1
Try: zypper install -C
"debuginfo(build-id)=bdcf485f96de50e19ebd8f6fb7660cb60e2ff194"
Missing separate debuginfo for /lib64/libdl.so.2
Try: zypper install -C
"debuginfo(build-id)=f607b21f9a513c99bba9539050c01236d19bf22b"
Missing separate debuginfo for /lib64/libm.so.6
Try: zypper install -C
"debuginfo(build-id)=4e9fa1a2c1141fc0123a142783efd044c40bdaaf"
Missing separate debuginfo for /lib64/libcrypt.so.1
Try: zypper install -C
"debuginfo(build-id)=d31bcb7f5e935044d4678350887dfbb33aa1722b"
Missing separate debuginfo for /lib64/libutil.so.1
Try: zypper install -C
"debuginfo(build-id)=e43269d9649d86bcd7ba19a0823d7f86a6f21af3"
Missing separate debuginfo for /lib64/libc.so.6
Try: zypper install -C
"debuginfo(build-id)=f7b8fc2bc1d68899a2cb561ac8e16092228223e3"
Unrecognized switch: -blib/lib (-h will show valid options).
[Inferior 1 (process 1226) exited with code 035]
(gdb) bt
No stack.
(gdb)
Thanx
-----Original Message-----
From: Martin J. Evans [mailto:martin...@easysoft.com]
Sent: Wednesday, August 15, 2012 10:50 AM
To: Jeff Tate
Cc: dbi-...@perl.org
Subject: Re: Help please with DBD::ODBC on SUSE-Linux
<http://www.easysoft.com> http://www.easysoft.com
(system file)) and change $ODBCINST to address
NO output produced in trace file
Step 2) running test under gdb
Linux:puTest> gdb `which perl`
GNU gdb (GDB) SUSE (7.3-0.6.1)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-suse-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /DCH/homedch/localPerl/bin/perl...done.
(gdb) run -lblib/lib -lblib/arch t/03dbatt.t
Starting program: /DCH/homedch/localPerl/bin/perl -lblib/lib -lblib/arch
t/03dbatt.t
Missing separate debuginfo for /lib64/ld-linux-x86-64.so.2
Try: zypper install -C
"debuginfo(build-id)=c1807b5762068e6c5f4a6a0ed48d9d4469965351"
Missing separate debuginfo for /lib64/libnsl.so.1
Try: zypper install -C
"debuginfo(build-id)=bdcf485f96de50e19ebd8f6fb7660cb60e2ff194"
Missing separate debuginfo for /lib64/libdl.so.2
Try: zypper install -C
"debuginfo(build-id)=f607b21f9a513c99bba9539050c01236d19bf22b"
Missing separate debuginfo for /lib64/libm.so.6
Try: zypper install -C
"debuginfo(build-id)=4e9fa1a2c1141fc0123a142783efd044c40bdaaf"
Missing separate debuginfo for /lib64/libcrypt.so.1
Try: zypper install -C
"debuginfo(build-id)=d31bcb7f5e935044d4678350887dfbb33aa1722b"
Missing separate debuginfo for /lib64/libutil.so.1
Try: zypper install -C
"debuginfo(build-id)=e43269d9649d86bcd7ba19a0823d7f86a6f21af3"
Missing separate debuginfo for /lib64/libc.so.6
Try: zypper install -C
"debuginfo(build-id)=f7b8fc2bc1d68899a2cb561ac8e16092228223e3"
Unrecognized switch: -blib/lib (-h will show valid options).
[Inferior 1 (process 1226) exited with code 035]
(gdb) bt
No stack.
(gdb)
Thanx
-----Original Message-----
From: Martin J. Evans [mailto:martin...@easysoft.com]
Sent: Wednesday, August 15, 2012 10:50 AM
To: Jeff Tate
Cc: dbi-...@perl.org
Subject: Re: Help please with DBD::ODBC on SUSE-Linux
Martin J. Evans
Aug 15, 2012, 1:29:46 PM8/15/12
to dbi-...@perl.org
On 15/08/2012 18:25, Jeff Tate wrote:
> Step 1) added ODBC trace information to odbcinst.ini (made my own copy
> (system file)) and change $ODBCINST to address
>
> NO output produced in trace file
>
>
>
> Step 2) running test under gdb
>
> Linux:puTest> gdb `which perl`
>
> GNU gdb (GDB) SUSE (7.3-0.6.1)
>
> Copyright (C) 2011 Free Software Foundation, Inc.
>
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
>
> This is free software: you are free to change and redistribute it.
>
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
>
> and "show warranty" for details.
>
> This GDB was configured as "x86_64-suse-linux".
>
> For bug reporting instructions, please see:
>
> <http://www.gnu.org/software/gdb/bugs/>...
>
> Reading symbols from /DCH/homedch/localPerl/bin/perl...done.
>
> (gdb) run -lblib/lib -lblib/arch t/03dbatt.t
That should be -Iblib/lib -Iblib/arch
> Step 1) added ODBC trace information to odbcinst.ini (made my own copy
> (system file)) and change $ODBCINST to address
>
> NO output produced in trace file
>
>
>
> Step 2) running test under gdb
>
> Linux:puTest> gdb `which perl`
>
> GNU gdb (GDB) SUSE (7.3-0.6.1)
>
> Copyright (C) 2011 Free Software Foundation, Inc.
>
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
>
> This is free software: you are free to change and redistribute it.
>
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
>
> and "show warranty" for details.
>
> This GDB was configured as "x86_64-suse-linux".
>
> For bug reporting instructions, please see:
>
> <http://www.gnu.org/software/gdb/bugs/>...
>
> Reading symbols from /DCH/homedch/localPerl/bin/perl...done.
>
> (gdb) run -lblib/lib -lblib/arch t/03dbatt.t
i.e., -I is an uppercase i not a 1
Martin
Martin J. Evans
Aug 15, 2012, 1:33:25 PM8/15/12
to dbi-...@perl.org
On 15/08/2012 18:25, Jeff Tate wrote:
>
>
> Step 1) added ODBC trace information to odbcinst.ini (made my own
> copy (system file)) and change $ODBCINST to address
>
> NO output produced in trace file
>
>
That suggests you are NOT using unixODBC as the ODBC driver manager.
> copy (system file)) and change $ODBCINST to address
>
> NO output produced in trace file
>
>
Therefore this increases the places where the problem may be as I've not
tried whatever driver manager comes with teradata.
Martin
Martin Gainty
Aug 15, 2012, 2:16:58 PM8/15/12
to Martin Evans, dbi-...@perl.org
If you are using MySQL
any ability to use native JDBC driver
http://dev.mysql.com/downloads/connector/j/2.0.html
or its slower bridge equivalent
ODBC2JDBC?
http://lists.mysql.com/maxdb/25919
Martin
> Date: Wed, 15 Aug 2012 18:33:25 +0100
> From: martin...@easysoft.com
> To: dbi-...@perl.org
> Subject: Re: Help please with DBD::ODBC on SUSE-Linux
>
>
Martin J. Evans
Sep 29, 2012, 6:34:39 AM9/29/12
to Jeff Tate, dbi-...@perl.org
On 28/09/2012 23:54, Jeff Tate wrote:
>
> I have got back to the task. I have installed an openSUSE virtual
> machine (matches the production server) and then installed Teradata
> GSS, ICU, CLIV2 and ODBC -packages. I have verified that the drivers
> function by installing the Teradata navigator and successfully getting
> data over ODBC.
>
> This time, when I run cpan test DBD::ODBC, I get an undefined symbol
> error (SQLFetch) from dynaloader trying to load ODBC.so. I have
> attached the full build and test trace from the cpan session.
>
> Thanx for any help.
>
> ------------------------------------------------------------------------
The make did not find unixODBC or iodbc via odbc_config or iodbc_config.
It then looked in standard places for it and finally in your "ODBCHOME
/opt/teradata/client/ODBC_64". It seemed to find iODBC libraries and
headers in ODBCHOME and built against it but there was no SQLFetch symbol.
As I said before, I've not tried DBD::ODBC against an iODBC that comes
with Teradata. However, I have had problems with missing symbols in
iODBC before. I'd install the unixODBC dev and bin packages, unset
ODBCHOME and run perl Makefile.PL -x. That should build fine then you
need to add your driver to the /etc/odbcinst.ini and put a DSN in the
/etc/odbc.ini.
Unfortunately I cannot be of much help as to what settings teradata
needs in the DSN. Basically, you need to find your teradata ODBC driver
shared object and add to your odbcinst.ini file something like:
[ODBC]
Trace=yes
TraceFile=/tmp/unixodbc.log
[teradata]
Description = Teradata ODBC driver
Driver = /path/to/teradata/odbc/driver/shared_object.so
Your /etc/odbc.ini should look something like:
[my_teradata_dsn]
Driver = teradata
some_attribute = some_value
another_attribute = another_value
Then you should use
isql -v my_teradata_dsn username password
Once that works build DBD::ODBC setting DBI_DSN=dbi:ODBC:my_terdata_dsn,
DBI_USER=username, DBI_PASS=password and run a make test.
Martin
>
> I have got back to the task. I have installed an openSUSE virtual
> machine (matches the production server) and then installed Teradata
> GSS, ICU, CLIV2 and ODBC -packages. I have verified that the drivers
> function by installing the Teradata navigator and successfully getting
> data over ODBC.
>
> This time, when I run cpan test DBD::ODBC, I get an undefined symbol
> error (SQLFetch) from dynaloader trying to load ODBC.so. I have
> attached the full build and test trace from the cpan session.
>
> Thanx for any help.
>
> ------------------------------------------------------------------------
>
> From: Martin J. Evans [mailto:martin...@easysoft.com]
> Sent: Wednesday, August 15, 2012 1:33 PM
> To: dbi-...@perl.org
> Subject: Re: Help please with DBD::ODBC on SUSE-Linux
>
> From: Martin J. Evans [mailto:martin...@easysoft.com]
> Sent: Wednesday, August 15, 2012 1:33 PM
> To: dbi-...@perl.org
> Subject: Re: Help please with DBD::ODBC on SUSE-Linux
>
It then looked in standard places for it and finally in your "ODBCHOME
/opt/teradata/client/ODBC_64". It seemed to find iODBC libraries and
headers in ODBCHOME and built against it but there was no SQLFetch symbol.
As I said before, I've not tried DBD::ODBC against an iODBC that comes
with Teradata. However, I have had problems with missing symbols in
iODBC before. I'd install the unixODBC dev and bin packages, unset
ODBCHOME and run perl Makefile.PL -x. That should build fine then you
need to add your driver to the /etc/odbcinst.ini and put a DSN in the
/etc/odbc.ini.
Unfortunately I cannot be of much help as to what settings teradata
needs in the DSN. Basically, you need to find your teradata ODBC driver
shared object and add to your odbcinst.ini file something like:
[ODBC]
Trace=yes
TraceFile=/tmp/unixodbc.log
[teradata]
Description = Teradata ODBC driver
Driver = /path/to/teradata/odbc/driver/shared_object.so
Your /etc/odbc.ini should look something like:
[my_teradata_dsn]
Driver = teradata
some_attribute = some_value
another_attribute = another_value
Then you should use
isql -v my_teradata_dsn username password
Once that works build DBD::ODBC setting DBI_DSN=dbi:ODBC:my_terdata_dsn,
DBI_USER=username, DBI_PASS=password and run a make test.
Martin
0 new messages