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

Well, the whole story is that we have our own component plug-in
architecture which, on-demand, links dynamically our own plug-in DLLs
one of which is the plug-in providing acces to MySQL databases. The
whole system is well shielded from the implementation details of DLL/.so
loading in a cross-platform  way.

We don't want to mess-up the system by explicit loading of external libs
on a particular platform if we can build our own shared lib plug-in
directly using the external libraries.
We had already some configuration/deployment issues when we were using
UnixODBC/ODBC based implementation of our plug-in for MySQL as it
launches chain of shared libs loading during ODBC run-time
initialization.

So far we had no problem linking against the mysqlclient.lib of version
4.0.x. We recently updated external dependencies after we successfully
migrated code to mysql client version 5.0.18 on Linux and suddenly the
build crashed on Win32 platform due to the unresolved symbol (infamous
_dosmaperr). The strange thing is that the symbol is not in all of the
VC++ 7.1 run-time versions. Definitely not in the msvc(p)rt library(ies)
which we link against. It looks like the symbol reference has been
introduced only recently, see: http://lists.mysql.com/internals/32243

Looking at the patch I don't see a good reason for that undocumented
call to be used but on Google one can find that it is rather popular in
PostgreSQL community too :-)

Interesting post discussing the problem we're facing is at:
http://caml.inria.fr/pub/ml-archives/caml-
list/2000/12/13419674475a4250f4a536c670a3f7ed.en.html

After reading the post I can conclude that MySQL developer(s) made a
mistake to rely on the undocumented Win32 call instead of implementing
error code translation properly.


Cheers

             Radovan

On Fri, 2006-03-10 at 17:53 +0100, Armin Schöffmann wrote:
> 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
> 
> 
> 
-- 
--
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]