Bug 171666 - unable to open shared library /usr/lib/libodbccr.1 when using SQL_CUR_USE_ODBC option
Summary: unable to open shared library /usr/lib/libodbccr.1 when using SQL_CUR_USE_ODB...
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: unixODBC   
(Show other bugs)
Version: 4.0
Hardware: i386
OS: Linux
Target Milestone: ---
: ---
Assignee: Tom Lane
QA Contact: David Lawrence
URL: http://www.rafb.net/paste/results/8li...
Depends On:
Blocks: 168429
TreeView+ depends on / blocked
Reported: 2005-10-24 22:38 UTC by jjh-redhat-bugzilla
Modified: 2013-07-03 03:06 UTC (History)
2 users (show)

Fixed In Version: RHBA-2006-0078
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-07 18:14:10 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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 22:42 UTC, jjh-redhat-bugzilla
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2006:0078 qe-ready SHIPPED_LIVE unixODBC bug fix update 2006-03-06 05:00:00 UTC

Description jjh-redhat-bugzilla 2005-10-24 22:38:56 UTC
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):

How reproducible:

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:

Additional info:

Comment 1 jjh-redhat-bugzilla 2005-10-24 22:42:53 UTC
Created attachment 120328 [details]
C file that demonstrates the packaging problem

Comment 2 Tom Lane 2005-10-25 00:07:23 UTC
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-25 00:27:28 UTC
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-25 00:43:11 UTC
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-25 01:15:19 UTC
It should work to rebuild the 2.2.11 SRPM currently being distributed for FC4 on

Unsupported, YMMV, etc, but it should work.

Comment 10 Red Hat Bugzilla 2006-03-07 18:14:10 UTC
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.


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