RE: Building MySQL 5.0.18 with multithreaded DLL run-time... - Armin Schöffmann - com.mysql.lists.win32

7 messages in com.mysql.lists.win32RE: Building MySQL 5.0.18 with multit...

From	Sent On	Attachments
Radovan Chytracek	10 Mar 2006 03:00
Armin Schöffmann	10 Mar 2006 04:14
Radovan Chytracek	10 Mar 2006 05:52
Armin Schöffmann	10 Mar 2006 06:42
Radovan Chytracek	10 Mar 2006 06:45
Armin Schöffmann	10 Mar 2006 08:52
Radovan Chytracek	10 Mar 2006 09:31

Subject:	RE: Building MySQL 5.0.18 with multithreaded DLL run-time...
From:	Armin Schöffmann (armi...@aegaeon.de)
Date:	03/10/2006 08:52:53 AM
List:	com.mysql.lists.win32

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:Rado...@cern.ch] 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:Rado...@cern.ch] Sent: Friday, March 10, 2006 3:46 PM To: Armin Schöffmann Cc: win...@lists.mysql.com 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:Rado...@cern.ch] Sent: Friday, March 10, 2006 2:53 PM To: Armin Schöffmann Cc: win...@lists.mysql.com 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:Rado...@cern.ch] Sent: Friday, March 10, 2006 12:01 PM To: win...@lists.mysql.com 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