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]