[unixODBC-dev] Problem loading our ODBC driver

Stefan Radman Stefan.Radman at CTBTO.ORG
Fri Dec 10 12:13:29 GMT 2004


> 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
unixODBC.
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
Done
=====
(stirring in logs) but I wonder if that had anything to do with the
drivers
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?

> 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
time.

> 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).

Stefan
> -----Original Message-----
> From: unixodbc-dev-bounces at easysoft.com 
> [mailto:unixodbc-dev-bounces at easysoft.com] On Behalf Of Nick Gorham
> Sent: Friday, 10 December, 2004 11:16
> To: Development issues and topics for unixODBC
> Subject: Re: [unixODBC-dev] Problem loading our ODBC driver
> 
> 
> Stefan Radman wrote:
> 
> >Maybe. What was the purpose of all that lib*lc stuff and 
> static linking?
> >  
> >
> 
> 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 
> 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.
> 
> I wonder, if this would be better served by splitting things 
> up a bit, 
> maybe having the main driver manager and support libs in one 
> part of the 
> build, and the drivers, and setup libs in another, and a 
> third with all 
> the apps in.
> 
> What do people think about this, It may well make some things 
> (like the 
> above problem) simpler, and make it simpiler when (as Peter is now) 
> additional drivers come along.
> 
> I will see what the thought out there is, and if its positive, I will 
> set about this over the comming holidays.
> 
> -- 
> Nick
> _______________________________________________
> unixODBC-dev mailing list
> unixODBC-dev at easysoft.com
> http://mail.easysoft.com/mailman/listinfo/unixodbc-dev
> 




More information about the unixODBC-dev mailing list