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

mixed C /C++

we currently use a custom libmysql.dll to workaround a handle-leak in the shared-mem-protocol,that nobody wants to fix, but it works also with the original distributions.

it's sufficient to reference the lib once. the pragma is a ms-extension forcing the linker to include the assigned lib. Alternatively you could list the lib-name as additional library in the linker options.

I observed similar linking issues with the static library mysqlclient.lib, anyway in my opinion it's preferable to use the dynamic lib - already concerning bugfixes and upgrades to the api. 

something prevents you from linking to the dll?

armin. 

-----Original Message-----
From: Radovan Chytracek [mailto:[email protected]] 
Sent: Friday, March 10, 2006 4:32 PM
To: Armin Schöffmann
Subject: RE: Building MySQL 5.0.18 with multithreaded DLL run-time...

Sorry, I have overlooked your earlier question about the libs we link against. My problem is only to link against mysqlclient.lib.
The only & single unresolved symbol is the _dosmaperr which is blocking us from complete build and the only reason we started to look at the way the MySQL client lib is built.

Radovan

On Fri, 2006-03-10 at 15:59 +0100, Armin Schöffmann wrote:
> we have several multithreaded (dlls/applications) using c-runtime from 
> which the mysql c-api is called, i statically link against 
> libmysql.lib, include the mysql-headers and that's it
> 
> #include "mysql\mysql.h" 
> #include "mysql\errmsg.h"
> [...]
> #pragma comment(lib, "libmysql.lib")
> 
> if you don't want to link the static part "libmysql.lib"
> take a look into win32 documentation for LoadLibrary and GetProcAddress.
> 
> The disadvantage in this case: you have to map each used mysql-api function by hand (GetProcAddress) and have to write an individual typedef-cast for the function-ptrs.
> 
> 
> 
> 
> -----Original Message-----
> From: Radovan Chytracek [mailto:[email protected]]
> Sent: Friday, March 10, 2006 3:46 PM
> To: Armin Schöffmann
> Cc: [email protected]
> Subject: RE: Building MySQL 5.0.18 with multithreaded DLL run-time...
> 
> 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
> 
> 
> 
--
--
Radovan Chytracek CERN IT PSS
mailto:[email protected]
phone: +41227674578 fax: +41227669830