Perl Install DBI 7.3.1 Solaris x86

How are you upgrading from SPARC to x86?

It seems like you copied some libraries from SPARC to x86 which will not work.

You need to do a fresh install of 7.3.1 on x86 and move any movable customizations over.

How are you upgrading from SPARC to x86?

It seems like you copied some libraries from SPARC to x86 which will not work.

You need to do a fresh install of 7.3.1 on x86 and move any movable customizations over.

We have done a fresh install. The old server was SPARC and the new server is x86. At this time it has been completed and we've moved iw-home/iw-perl/site/lib perl modules including DBI from the old server to the new server.

Something is wrong though with perl DBI on the new server and its not functioning. IT is also having issues re-installing DBI on the new server.

I have confirmed that the one being used is in the site/lib directory.

perldoc -l DBI

... we've moved iw-home/iw-perl/site/lib perl modules including DBI from the old server to the new server.
...

You moved SPARC binaries (shared libraries, mentioned in the error) to an x86 platform. That won't fly. You need to remove the files you moved and install DBI by hand.

If you go into the site/lib directory, type file path/to/some.so

you should see a difference between the SPARC and the x86 shared libraries.

This should produce the wrong answer:

file /Interwoven/TeamSite/iw-perl/site/lib/auto/DBI/DBI.so

You moved SPARC binaries (shared libraries, mentioned in the error) to an x86 platform. That won't fly. You need to remove the files you moved and install DBI by hand.

If you go into the site/lib directory, type file path/to/some.so

you should see a difference between the SPARC and the x86 shared libraries.

This should produce the wrong answer:

file /Interwoven/TeamSite/iw-perl/site/lib/auto/DBI/DBI.so

Right, I suspected that as well. The problem is we're having trouble re-installing this module on x86. We also need to install DBD Smiley Surprised

DBC which likely has the same issue.

Is there anything we need to do to be able to install and compile custom perl modules on 7.3.1 x86? Certain compiler etc...

Perl DBI install was always a pain. You likely need gc++ or a developer environment in general. This is more of a Perl issue on x86 than a TS issue, so you may want to broaden your search (google and Perlmonks), that being said it is also possible you found a TS bug (if 7.3.1 delivered an incorrect .so)

I would first see if you can identify (likely with file) the correct and incorrect .so files in iw-perl/

There should be a DBI module in

IWHOME/iw-perl/vendor/lib

which should work.

I believe you can utilize basic ODBC directives with the basic DBI module without having to install (compile/install) any other DBI or DBD modules.

If you need to call DB-specific methods, then you need the appropriate DBD module, and then you'll need to download / compile / install it -- for the most part you should look carefully at the README documents associated with those modules.

You can also try using DBI: Smiley Tongue

urePerl (which I believe comes with the iwperl distribution) - however, I'm not sure that helps you any if you need DB-specific methods from a DB-specific DBD module.

There should be a DBI module in
IWHOME/iw-perl/vendor/lib
which should work.

I believe you can utilize basic ODBC directives with the basic DBI module without having to install (compile/install) any other DBI or DBD modules.

If you need to call DB-specific methods, then you need the appropriate DBD module, and then you'll need to download / compile / install it -- for the most part you should look carefully at the README documents associated with those modules.

You can also try using DBI:urePerl (which I believe comes with the iwperl distribution) - however, I'm not sure that helps you any if you need DB-specific methods from a DB-specific DBD module.

I don't believe DBI is installed there as there is no DBI.pm in the iw-perl/vendor/lib directory.

Our installation previously has DBI installed under iw-perl/site/lib. We are using ''easysoft" and DBD Smiley Surprised

DBC to connect to a MS-SQL database.

We have installed DBI but now we have other issues. I received this error when trying to start search and search index today on the new system. I believe this to be related to the install of DBI.

ld.so.1: ps: fatal: /lib/libc.so.1: wrong ELF class: ELFCLASS32

IIRC, on Windows DBI came preinstalled with TS, however Linux it was not. Probably due to device drivers.

IIRC, on Windows DBI came preinstalled with TS, however Linux it was not. Probably due to device drivers.

We were finally able to compile the lib using the gcc compiler which had to be pathed to explicitly otherwise another compiler was being used. The other issue noted above "ld.so.1: ps: fatal: /lib/libc.so.1: wrong ELF class: ELFCLASS32" was due to a symbolic link that got changed during the compile of perl DBI. I don't know the details. If I get them I will post for the greater good.

We still have DBD Smiley Surprised

DBC to install, hopefully that goes smoothly.....

We now have DBI, DBI Smiley Surprised

DBC installed. The problem we have now is that CGI and DCT scripts that connect to the database are failing with this error.

"install_driver(ODBC) failed: Can't load '/Interwoven/TeamSite/iw-perl/site/lib/auto/DBD/ODBC/ODBC.so' for module DBD: Smiley Surprised

DBC: ld.so.1: perl: fatal: libodbc.so.1: open failed: No such file or directory at /Interwoven/TeamSite/iw-perl/lib/DynaLoader.pm line 229.
at (eval 3) line 3
Compilation failed in require at (eval 3) line 3.
Perhaps a required shared library or dll isn't installed where expected"

The files do exist. The same script when run through the command line will work but when run as an <inline /> does not work.

The files do exist. The same script when run through the command line will work but when run as an <inline /> does not work.

Tim - that's a classic, and you've been around long enough to know that.
Inline scripts do not have the same environment variables accessible to them as when running from the command line - therefore you need to compare the list and values of environment variables in both situations to figure out what you need to hard-code (within a BEGIN block) in the script.

For the CGI - you either need to hard code the information (BEGIN block) or pass-it-through (modification of the iw-webd/conf/iwwebd.conf.template)

Try searching this forum for the word BEGIN

you will see some examples of what Ghoti is talking about

Tim - that's a classic, and you've been around long enough to know that.
Inline scripts do not have the same environment variables accessible to them as when running from the command line - therefore you need to compare the list and values of environment variables in both situations to figure out what you need to hard-code (within a BEGIN block) in the script.

For the CGI - you either need to hard code the information (BEGIN block) or pass-it-through (modification of the iw-webd/conf/iwwebd.conf.template)

In our current environment this is not necessary. I was hoping to recreate the same configuration on the new server but it has been a long time since we have done a clean install and what was done to elegantly remedy this issue was not well documented.

Will the "modification of the iw-webd/conf/iwwebd.conf.template" solution solve the issue for just CGI scripts? How would I solve it for <inline/> scripts globally?

Will the "modification of the iw-webd/conf/iwwebd.conf.template" solution solve the issue for just CGI scripts?

Yea this will not help in with the inlines.

How would I solve it for <inline/> scripts globally?

The only way to solve this globally would be to use Perl Modules for the query and include it there. But if you are calling db->open directly, then you will be making a lot of changes.

Yea this will not help in with the inlines.

The only way to solve this globally would be to use Perl Modules for the query and include it there. But if you are calling db->open directly, then you will be making a lot of changes.

When I output @INC through either executing the inline script through the command line or launching a form through the ui that uses the same script as an <inline/>the @INC variables are all intact.

/Interwoven/TeamSite/iw-perl/lib
/Interwoven/TeamSite/iw-perl/site/lib
/Interwoven/TeamSite/iw-perl/vendor/lib

I would think if finding a perl module was the issue these directives would cover this problem as the error complains about being able to find a file in /Interwoven/TeamSite/iw-perl/site/lib

@INC is the same on the production system where everything is working as expected.

@INC is for Perl modules - the problem you're having (or so you indicated) was with shared libraries not being found - those are usually on something like a LIBPATH environment variable - again - look for the posts regarding the use of BEGIN blocks and go through the exercise of dumping them out from both the command line and the script - and compare / contrast the information.

@INC is for Perl modules - the problem you're having (or so you indicated) was with shared libraries not being found - those are usually on something like a LIBPATH environment variable - again - look for the posts regarding the use of BEGIN blocks and go through the exercise of dumping them out from both the command line and the script - and compare / contrast the information.

I had done this already. Adding the following did not fix the issue for the inline commands. Again, I'm having the same issue with CGI.

BEGIN {
$ENV{"LD_LIBRARY_PATH"} = "/usr/local/easysoft...........
$ENV{"PATH"} = "/Interwoven/TeamSite/iw-perl/.........
}

I had done this already. Adding the following did not fix the issue for the inline commands. Again, I'm having the same issue with CGI.

BEGIN {
$ENV{"LD_LIBRARY_PATH"} = "/usr/local/easysoft...........
$ENV{"PATH"} = "/Interwoven/TeamSite/iw-perl/.........
}

Ah well, you never indicated that you had done this - can we safely assume that these values are set identically to those that show up when you run the script from the command line or through other means when it works? Does it work through other means?

Is the problem still the libraries (as opposed to Perl modules) or has the manifestation of the problem changed since you last posted?

For the CGI perl script - I recommend adding (if you don't have it already):

use CGI::Carp qw(fatalsToBrowser);

That way the error message will show up in the browser and you can copy/paste it into the forums.

I think the problem has to be with locating the libraries. When executing the <inline/> script through the command line it works perfectly.

When executing the CGI through the command line Smiley Happy

it works perfectly

When executing the <inline/> launching a form through the UI the error is sent right to the browser anyway. When executing a CGI I get the errors through the iw-home/local/logs/iwui/error.log

The core of the error is.

"install_driver(ODBC) failed: Can't load '/Interwoven/TeamSite/iw-perl/site/lib/auto/DBD/ODBC/ODBC.so' for module DBD: Smiley Surprised

DBC:
ld.so.1: perl: fatal: libodbc.so.1: open failed: No such file or directory at /Interwoven/TeamSite/iw-perl/lib/DynaLoader.pm
line 229. at (eval 121) line 3 Compilation failed in require at (eval 121) line 3. Perhaps a required shared library or dll isn't installed where expected at...." the rest is script specific.

OK, then try to change the LD_LIBRARY_PATH system wide

create a file (something like)

/etc/ld.so.conf.d/iwperl.conf

and put this in it:

/usr/local/easysoft...........
(I assume this is where the .so is)

You will probably need a reboot.

[...]
The core of the error is.

"install_driver(ODBC) failed: Can't load '/Interwoven/TeamSite/iw-perl/site/lib/auto/DBD/ODBC/ODBC.so' for module DBD:DBC:
ld.so.1: perl: fatal: libodbc.so.1: open failed: No such file or directory at /Interwoven/TeamSite/iw-perl/lib/DynaLoader.pm
line 229. at (eval 121) line 3 Compilation failed in require at (eval 121) line 3. Perhaps a required shared library or dll isn't installed where expected at...." the rest is script specific.

Before following nipper's suggestion - which theoretically could break something else - can you please do the following and post the results:

ls -l /Interwoven/TeamSite/iw-perl/site/lib/auto/DBD/ODBC/ODBC.so
file /Interwoven/TeamSite/iw-perl/site/lib/auto/DBD/ODBC/ODBC.so
ldd /Interwoven/TeamSite/iw-perl/site/lib/auto/DBD/ODBC/ODBC.so

Before following nipper's suggestion - which theoretically could break something else - can you please do the following and post the results:
ls -l /Interwoven/TeamSite/iw-perl/site/lib/auto/DBD/ODBC/ODBC.so
file /Interwoven/TeamSite/iw-perl/site/lib/auto/DBD/ODBC/ODBC.so
ldd /Interwoven/TeamSite/iw-perl/site/lib/auto/DBD/ODBC/ODBC.so

Here you go...

-r-xr-xr-x 1 root root 147300 Jan 11 17:30 /Interwoven/TeamSite/iw-perl/site/lib/auto/DBD/ODBC/ODBC.so*

/Interwoven/TeamSite/iw-perl/site/lib/auto/DBD/ODBC/ODBC.so: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped, no debugging information available

libodbc.so.1 => /usr/local/easysoft/unixODBC/lib/libodbc.so.1
libc.so.1 => /lib/libc.so.1
libdl.so.1 => /lib/libdl.so.1
libthread.so.1 => /lib/libthread.so.1
libm.so.2 => /lib/libm.so.2

Here you go...

-r-xr-xr-x 1 root root 147300 Jan 11 17:30 /Interwoven/TeamSite/iw-perl/site/lib/auto/DBD/ODBC/ODBC.so*

/Interwoven/TeamSite/iw-perl/site/lib/auto/DBD/ODBC/ODBC.so: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped, no debugging information available

libodbc.so.1 => /usr/local/easysoft/unixODBC/lib/libodbc.so.1
libc.so.1 => /lib/libc.so.1
libdl.so.1 => /lib/libdl.so.1
libthread.so.1 => /lib/libthread.so.1
libm.so.2 => /lib/libm.so.2

Is this a 32-bit or 64-bit system that you're on? That might play a part in the issue. Also - check the permissions and such (ls -l ...; file ...) on the other libraries.

I'm just taking guesses - not sure exactly where this might lead to, if anywhere - but it's worth eliminating variables while trying to figure out what's wrong.