On 15/08/12 15:32, Jeff Tate wrote:

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.

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.

If above is correct you should not need to install unixODBC separately.

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.

Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com