Bug 171666 - unable to open shared library /usr/lib/libodbccr.1 when using SQL_CUR_USE_ODBC option
unable to open shared library /usr/lib/libodbccr.1 when using SQL_CUR_USE_ODB...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: unixODBC (Show other bugs)
4.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tom Lane
David Lawrence
http://www.rafb.net/paste/results/8li...
:
Depends On:
Blocks: 168429
  Show dependency treegraph
 
Reported: 2005-10-24 18:38 EDT by jjh-redhat-bugzilla
Modified: 2013-07-02 23:06 EDT (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2006-0078
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-07 13:14:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
C file that demonstrates the packaging problem (2.62 KB, text/plain)
2005-10-24 18:42 EDT, jjh-redhat-bugzilla
no flags Details

  None (edit)
Description jjh-redhat-bugzilla 2005-10-24 18:38:56 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

Description of problem:
When using the SQL_CUR_USE_ODBC option in the SQLSetConnectAttr() function, at execution time the following error is observed:

01000:1:0:[unixODBC][Driver Manager]Can't open cursor lib 'libodbccr' : /usr/lib/libodbccr.1: cannot open shared object file: No such file or directory

The problem was first observed in php using the odbc_connect() function with the SQL_CUR_USE_ODBC option.  This was traced back to unixODBC and it turns out to be bug in the build process for unixODBC for RHEL4.  The SHLIBEXT C macro gets set to "" instead of ".so"

Building unixODBC outside of an RPM sets the SHLIBEXT value correctly.


Version-Release number of selected component (if applicable):
unixODBC-2.2.9-1

How reproducible:
Always

Steps to Reproduce:
1. make sure a valid database configuration exists in the odbc.ini and odbcinst.ini files
2. download the C code from http://www.rafb.net/paste/results/8linQ593.txt
3. mv 8linQ593.txt odbc_test.c
3. replace the DB_NAME, DB_USER, DB_PASS macros as appropriate to a valid atabase
4. gcc  odbc_test.c -o odbc_test -lodbc
5 ./odbc_test
  

Actual Results:  ]$ ./odbc_t2 
Failed to connect

The driver reported the following diagnostics whilst running SQLDriverConnect

01000:1:0:[unixODBC][Driver Manager]Can't open cursor lib 'libodbccr' : /usr/lib/libodbccr.1: cannot open shared object file: No such file or directory


Expected Results:  Connected
Returned connection string was:
    DSN=database;UID=user;PWD=password


Additional info:
Comment 1 jjh-redhat-bugzilla 2005-10-24 18:42:53 EDT
Created attachment 120328 [details]
C file that demonstrates the packaging problem
Comment 2 Tom Lane 2005-10-24 20:07:23 EDT
Hmm, I see that indeed SHLIBEXT is set to empty during the build, but if the
code were relying on that then you'd think nothing would work at all ...

More to the point, your test program doesn't fail for me.  Perhaps it is
driver-dependent?  What exactly is in the odbc.ini and odbcinst.ini entries you
are testing with, and what is the version of the driver you are using?
Comment 3 Tom Lane 2005-10-24 20:27:28 EDT
No, I take that back --- I was testing the wrong version of unixODBC.  It does
fail with 2.2.9, but not with 2.2.11.  Not because the configure script does
things differently, but because the upstream developers patched the code to
treat SHLIBEXT = "" as meaning ".so".  They had already done this in other
places that use SHLIBEXT, but not in the cursor management code.  Pretty bizarre
way of addressing the problem if you ask me, but they didn't ask me ;-)

Anyway, bottom line is that this should be fixed in 2.2.11, which I am hoping to
update us to in RHEL4 U3 due to other open bugs.
Comment 4 jjh-redhat-bugzilla 2005-10-24 20:43:11 EDT
Thanks for your work.  Is there anyway I could get a source or binary rpm of
2.2.11 for unixODBC? or would you just suggest another method?  I need to get
this onto our systems pretty quickly.

Comment 5 Tom Lane 2005-10-24 21:15:19 EDT
It should work to rebuild the 2.2.11 SRPM currently being distributed for FC4 on
RHEL4.

Unsupported, YMMV, etc, but it should work.
Comment 10 Red Hat Bugzilla 2006-03-07 13:14:10 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2006-0078.html

Note You need to log in before you can comment on or make changes to this bug.