[unixODBC-dev] Problem loading our ODBC driver

Nick Gorham nick.gorham at easysoft.com
Fri Dec 10 12:43:56 GMT 2004

Stefan Radman wrote:

>>Ok, I remember, why now. Its linked with the "convienence" lib (thats 
>>the lc stuff) as at that point the actual driver manager libs have not
>>been installed, so if it was just a -lodbcinst it could fail. The 
>Ah, that's why. (Sings) I can see clearly now! :)
>I remember having had that problem during an RPM rebuild on a clean (no
>unixODBC installed) system.
>(stirring in emails) 
>The failure though was due to the buggy libtool version distributed with
>There is a fix for that in unixODBC-sr.spec that works for me:
># fix relink statement in .la files created by buggy bundled libtool
># prepend temporary install lib path to aid in relinking
>for la in `%{__grep} '^relink_command=' */*.la | %{__cut} -d: -f1`; do
>  %{__sed} "s,^\(relink_command=.*\.lo
>\),\1-L${RPM_BUILD_ROOT}%{_libdir} ," $la >$la.fixed
>  %{__mv} $la.fixed $la
>(stirring in logs) but I wonder if that had anything to do with the
>Never had any other problems building on a clean system.
>The problem you describe should be handled by a correctly working
>libtool automatically even when linking dynamically, right?
Maybe, I will see if the problem is still there. I seem to remember it 
works on most platforms, but there were some (SCO springs to mind) that 
had problems.

>>convienence lib, is a libtool way of looking like its linking 
>>with the 
>>lib, but actually it pulls in the objects that would make up the libs.
>It seems odd to me that a driver that is dynamically loaded by a DM
>would link some of the DM interface functions statically at compile
Its not perfect by any means, I agree.

>>I wonder, if this would be better served by splitting things 
>>up a bit, 
>I'm somewhere between pro and con.
>On one hand it might be beneficial to take the drivers out of the source
>tree completely to limit any interdependency (see odbcinstext.h:#ifdef
>UNIXODBC_SOURCE) and provide a clear interface btw driver & DM (as a
>good example for driver developers).
>Personally I do build the bundled drivers but they are put into a
>separate package.
>The drivers I use are built standalone from more recent (bleeding
>edge;-) code.
>On the other hand a change like this might require major changes to most
>spec files and build scripts (low acceptance).

Hmm, that about sums up my view as well, I will think on it, maybe add 
options to the main configure to allow the choice, between doing 
everything, by calling the additional configures, or not.


More information about the unixODBC-dev mailing list