[unixODBC-dev] Re: Symbol name collision between unixODBC and driver

Nick Gorham nick at lurcher.org
Thu Nov 3 19:27:38 GMT 2005


Marc Herbert wrote:

>Nick Gorham <nick at lurcher.org> writes:
>
>  
>
>>>I am afraid this is an FAQ but... would you have a pointer giving more
>>>details about how this linking magic goes? I mean, how come the names
>>>do not clash?
>>>
>>>      
>>>
>>Basically becaus ethe driver manager is linked into the app, and at
>>run time the drivers are linked in dynamically, and the addresses of
>>the entry points are extracted. Have a look at dlopen and dlsys, and
>>take a look at the DM code, its all in there.
>>    
>>
>
>Thanks! [quick look] Uh, looks scary...
>
>Do the symbols have the same name so some people can shortcut the
>driver manager and hardwire a driver with minimum effort?
>
>Or was it designed like this just to scare away non- dlopen() experts? :-)
>  
>
That I don't know, in the windows case, that the way it was, and 
unixODBC and iODBC followed the same. No real reason why not, though it 
can cause the occasional confusion.

>
>  
>
>>Its the main point of ODBC, Your app is liniked against the driver
>>manager, then at a later date the user can add additional drivers as
>>required.
>>    
>>
>
>Sure, but this does not look enough to force all those symbols to have
>the same name whatever the layer is.
>
>  
>
It doesn't, but they have to be the same for all drivers, or the driver 
manager would need to know what the names were for each driver. As its 
is usinf the same names measn that the DM can be ignored and the app 
linked directly if required, and it means the Dm knows exactly what 
symbol to load, AND it means I can write a driver, that can be used on 
all the driver managers *nix/windows and OS2 from the same code base, no 
real difference between them.

At the end of the day there is no reason why the same names shouldn't be 
used, and a lot of advantages if they are,

-- 
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.unixodbc.org/pipermail/unixodbc-dev/attachments/20051103/294e0fe2/attachment.html>


More information about the unixODBC-dev mailing list