Hide Forgot
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:
Created attachment 120328 [details] C file that demonstrates the packaging problem
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?
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.
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.
It should work to rebuild the 2.2.11 SRPM currently being distributed for FC4 on RHEL4. Unsupported, YMMV, etc, but it should work.
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