Re: DB connection library and dynamic linking

John Gavin <[email protected]>
Newsgroups gmane.comp.db.tds.freetds
Message-ID <[email protected]>
Maybe you could do something with the dlopen/dlsym calls, open up one or the 
other libraries at runtime and bind the calls in the DLL to an alias in a facade 
module.




________________________________
From: James K. Lowden <[email protected]>
To: FreeTDS Development Group <[email protected]>
Sent: Sun, September 26, 2010 4:11:45 PM
Subject: Re: [freetds] 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
_______________________________________________
FreeTDS mailing list
[email protected]
http://lists.ibiblio.org/mailman/listinfo/freetds
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.