Re: DB connection library and dynamic linking

Julian Amso wrote:
> 
> Thank for the different suggestions. There is bureaucratic situation of
> not me having control over the package compilation, installation on the
> machine including root access. It looks like a nice solution of the
> namespace issue.

Yes, I hope it's clear that the change I suggested touches only FreeTDS. 
Your source code and build procedure are unmodified.  

> I wonder what would happen if a recompile the application and staticly
> link the FreeTDS application and keep the remaining libraries to be
> loaded dynamically. 

The static linker will satisfy all ct-lib symbols it can from the static
library, including those you might hope would be left until run time.  

> I also found an interesting article about direct binding symbol
> references using a mapfile. 

The fundamental problem you face AIUI is that two parts of your object
code both refer to e.g. ct_connect() but want different implementations of
it.  No amount of linker hocus pocus can link some references to one
library and others to another.  

Well, that might not  be 100% true.  The linker knows two things: the
symbol name and the name of the module (the .o file) referencing it.  In
theory, the linker could distinguish based on module name, and you could
provide it a map listing which modules are to be linked to which
libraries.  

The only difficulty there is that I've never heard of such a feature.  You
might have to write your own linker.  I think renaming the symbols will be
easier, though.  ;-)

--jkl