RE: Building MySQL 5.0.18 with multithreaded DLL run-time...

Radovan Chytracek <[email protected]>
Newsgroups gmane.comp.db.mysql.windows
Organization CERN
Message-ID <[email protected]>
Hi,

    how can you avoid it when using MySQL C API in our apps DLLs?

Radovan

On Fri, 2006-03-10 at 15:42 +0100, Armin Schöffmann wrote:
> Radovan,
> against which lib to you link?
> libmysql.lib or mysqlclient.lib
> 
> libmysql.lib just contains the stubs for easier handling the dynamic imports - it does not reference runtime-calls.
> You could even ommit the static import libmysql.lib and import directly at runtime from libmysql.dll
> by LoadLibrary/ GetProcAddress.
> 
> armin. 
> 
> -----Original Message-----
> From: Radovan Chytracek [mailto:[email protected]] 
> Sent: Friday, March 10, 2006 2:53 PM
> To: Armin Schöffmann
> Cc: [email protected]
> Subject: RE: Building MySQL 5.0.18 with multithreaded DLL run-time...
> 
> Hi,
>     the issue is that when trying to link against MySQL original client library 5.0.18 we get unresolved reference to _dosmaperr call. We have found that a different run-time is being used to build it.
> In trying to build MySQL libmysql.lib & dll libs from sources using /MD we run into more unresolved symbols.
> 
> Another issue is that even for debug builds of our software stack we still use on windows only the multi-threaded DLL non-debug version but include debug information only of our SW as we don't need to debug C/C++ run-time libs :-) MySQL on the other hand uses debug version of the C/C++ run-time for its debug builds.
> 
> We try to find out a way to use 5.0.18 client libs without link error mentioned above. So far we only see the way of providing a hack using a dummy _dosmaperr() call in order to avoid it. Of course if there is way to avoid hacking MySQL sources we follow it.
> 
> Cheers
> 
>             Radovan
> 
> On Fri, 2006-03-10 at 13:14 +0100, Armin Schöffmann wrote:
> > I see no risk to link libmysql.dll dynamically against a dll importing the /MD runtime.
> > Usually, you even don't know about the runtime-imports of a foreign dll.
> > Mixing runtimes causes trouble when linking statically, but libmysql.dll is the dynamic lib.
> > Regards Armin.
> > 
> > 
> > 
> > -----Original Message-----
> > From: Radovan Chytracek [mailto:[email protected]]
> > Sent: Friday, March 10, 2006 12:01 PM
> > To: [email protected]
> > Subject: Building MySQL 5.0.18 with multithreaded DLL run-time...
> > 
> > Hi,
> > 
> >    our software requires multi-threaded DLL (/MD switch of VC++ 7.1) run-time but MySQL client & server builds only with multi-threaded (/MT) run-time. Mixing run-times leads to clear crash sooner-or-later so we would like to know if /MD based MySQL build can be achieved. We've tried to do it ourselves but we're running into link problems when building libmysql.dll and mysql client programs.
> > With original MySQL binaries we had problem to link because of _dosmaperr unresolved symbol which we even can't find a reasonable information about.
> > 
> > Any info or advice is welcomed.
> > 
> > Cheers
> > 
> >             Radovan
> > 
> > --
> > --
> > Radovan Chytracek CERN IT PSS
> > mailto:[email protected]
> > phone: +41227674578 fax: +41227669830
> > 
> > 
> --
> --
> Radovan Chytracek CERN IT PSS
> mailto:[email protected]
> phone: +41227674578 fax: +41227669830
> 
> 
> 
-- 
--
Radovan Chytracek CERN IT PSS
mailto:[email protected]
phone: +41227674578 fax: +41227669830


-- 
MySQL Windows Mailing List
For list archives: http://lists.mysql.com/win32
To unsubscribe:    http://lists.mysql.com/[email protected]
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.