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:Radovan.Chytracek@cern.ch
phone: +41227674578 fax: +41227669830


--
MySQL Windows Mailing List
For list archives: http://lists.mysql.com/win32
To unsubscribe: http://lists.mysql.com/win32?unsub=gcdmw-win32@m.gmane.org

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

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:Radovan.Chytracek@cern.ch]=20
Sent: Friday, March 10, 2006 12:01 PM
To: win32@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

--
--
Radovan Chytracek CERN IT PSS
mailto:Radovan.Chytracek@cern.ch
phone: +41227674578 fax: +41227669830


--=20
MySQL Windows Mailing List
For list archives: http://lists.mysql.com/win32
To unsubscribe: =
http://lists.mysql.com/win32?unsub=3Darmin.schoeffmann@aegae on.de




--
MySQL Windows Mailing List
For list archives: http://lists.mysql.com/win32
To unsubscribe: http://lists.mysql.com/win32?unsub=3Dgcdmw-win32@m.gmane.org

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 th=
e /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.
>=20
>=20
>=20
> -----Original Message-----
> From: Radovan Chytracek [mailto:Radovan.Chytracek@cern.ch]=20
> Sent: Friday, March 10, 2006 12:01 PM
> To: win32@lists.mysql.com
> Subject: Building MySQL 5.0.18 with multithreaded DLL run-time...
>=20
> Hi,
>=20
> 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-ti=
me. 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 ours=
elves but we're running into link problems when building libmysql.dll and m=
ysql 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.
>=20
> Any info or advice is welcomed.
>=20
> Cheers
>=20
> Radovan
>=20
> --
> --
> Radovan Chytracek CERN IT PSS
> mailto:Radovan.Chytracek@cern.ch
> phone: +41227674578 fax: +41227669830
>=20
>=20
--=20
--
Radovan Chytracek CERN IT PSS
mailto:Radovan.Chytracek@cern.ch
phone: +41227674578 fax: +41227669830


--
MySQL Windows Mailing List
For list archives: http://lists.mysql.com/win32
To unsubscribe: http://lists.mysql.com/win32?unsub=3Dgcdmw-win32@m.gmane.org

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

UmFkb3ZhbiwNCmFnYWluc3Qgd2hpY2ggbGliIHRvIHlvdSBsaW5rPw0KbGli bXlzcWwubGliIG9y
IG15c3FsY2xpZW50LmxpYg0KDQpsaWJteXNxbC5saWIganVzdCBjb250YWlu cyB0aGUgc3R1YnMg
Zm9yIGVhc2llciBoYW5kbGluZyB0aGUgZHluYW1pYyBpbXBvcnRzIC0gaXQg ZG9lcyBub3QgcmVm
ZXJlbmNlIHJ1bnRpbWUtY2FsbHMuDQpZb3UgY291bGQgZXZlbiBvbW1pdCB0 aGUgc3RhdGljIGlt
cG9ydCBsaWJteXNxbC5saWIgYW5kIGltcG9ydCBkaXJlY3RseSBhdCBydW50 aW1lIGZyb20gbGli
bXlzcWwuZGxsDQpieSBMb2FkTGlicmFyeS8gR2V0UHJvY0FkZHJlc3MuDQoN CmFybWluLiANCg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJhZG92YW4gQ2h5 dHJhY2VrIFttYWls
dG86UmFkb3Zhbi5DaHl0cmFjZWtAY2Vybi5jaF0gDQpTZW50OiBGcmlkYXks IE1hcmNoIDEwLCAy
MDA2IDI6NTMgUE0NClRvOiBBcm1pbiBTY2jDtmZmbWFubg0KQ2M6IHdpbjMy QGxpc3RzLm15c3Fs
LmNvbQ0KU3ViamVjdDogUkU6IEJ1aWxkaW5nIE15U1FMIDUuMC4xOCB3aXRo IG11bHRpdGhyZWFk
ZWQgRExMIHJ1bi10aW1lLi4uDQoNCkhpLA0KICAgIHRoZSBpc3N1ZSBpcyB0 aGF0IHdoZW4gdHJ5
aW5nIHRvIGxpbmsgYWdhaW5zdCBNeVNRTCBvcmlnaW5hbCBjbGllbnQgbGli cmFyeSA1LjAuMTgg
d2UgZ2V0IHVucmVzb2x2ZWQgcmVmZXJlbmNlIHRvIF9kb3NtYXBlcnIgY2Fs bC4gV2UgaGF2ZSBm
b3VuZCB0aGF0IGEgZGlmZmVyZW50IHJ1bi10aW1lIGlzIGJlaW5nIHVzZWQg dG8gYnVpbGQgaXQu
DQpJbiB0cnlpbmcgdG8gYnVpbGQgTXlTUUwgbGlibXlzcWwubGliICYgZGxs IGxpYnMgZnJvbSBz
b3VyY2VzIHVzaW5nIC9NRCB3ZSBydW4gaW50byBtb3JlIHVucmVzb2x2ZWQg c3ltYm9scy4NCg0K
QW5vdGhlciBpc3N1ZSBpcyB0aGF0IGV2ZW4gZm9yIGRlYnVnIGJ1aWxkcyBv ZiBvdXIgc29mdHdh
cmUgc3RhY2sgd2Ugc3RpbGwgdXNlIG9uIHdpbmRvd3Mgb25seSB0aGUgbXVs dGktdGhyZWFkZWQg
RExMIG5vbi1kZWJ1ZyB2ZXJzaW9uIGJ1dCBpbmNsdWRlIGRlYnVnIGluZm9y bWF0aW9uIG9ubHkg
b2Ygb3VyIFNXIGFzIHdlIGRvbid0IG5lZWQgdG8gZGVidWcgQy9DKysgcnVu LXRpbWUgbGlicyA6
LSkgTXlTUUwgb24gdGhlIG90aGVyIGhhbmQgdXNlcyBkZWJ1ZyB2ZXJzaW9u IG9mIHRoZSBDL0Mr
KyBydW4tdGltZSBmb3IgaXRzIGRlYnVnIGJ1aWxkcy4NCg0KV2UgdHJ5IHRv IGZpbmQgb3V0IGEg
d2F5IHRvIHVzZSA1LjAuMTggY2xpZW50IGxpYnMgd2l0aG91dCBsaW5rIGVy cm9yIG1lbnRpb25l
ZCBhYm92ZS4gU28gZmFyIHdlIG9ubHkgc2VlIHRoZSB3YXkgb2YgcHJvdmlk aW5nIGEgaGFjayB1
c2luZyBhIGR1bW15IF9kb3NtYXBlcnIoKSBjYWxsIGluIG9yZGVyIHRvIGF2 b2lkIGl0LiBPZiBj
b3Vyc2UgaWYgdGhlcmUgaXMgd2F5IHRvIGF2b2lkIGhhY2tpbmcgTXlTUUwg c291cmNlcyB3ZSBm
b2xsb3cgaXQuDQoNCkNoZWVycw0KDQogICAgICAgICAgICBSYWRvdmFuDQoN Ck9uIEZyaSwgMjAw
Ni0wMy0xMCBhdCAxMzoxNCArMDEwMCwgQXJtaW4gU2Now7ZmZm1hbm4gd3Jv dGU6DQo+IEkgc2Vl
IG5vIHJpc2sgdG8gbGluayBsaWJteXNxbC5kbGwgZHluYW1pY2FsbHkgYWdh aW5zdCBhIGRsbCBp
bXBvcnRpbmcgdGhlIC9NRCBydW50aW1lLg0KPiBVc3VhbGx5LCB5b3UgZXZl biBkb24ndCBrbm93
IGFib3V0IHRoZSBydW50aW1lLWltcG9ydHMgb2YgYSBmb3JlaWduIGRsbC4N Cj4gTWl4aW5nIHJ1
bnRpbWVzIGNhdXNlcyB0cm91YmxlIHdoZW4gbGlua2luZyBzdGF0aWNhbGx5 LCBidXQgbGlibXlz
cWwuZGxsIGlzIHRoZSBkeW5hbWljIGxpYi4NCj4gUmVnYXJkcyBBcm1pbi4N Cj4gDQo+IA0KPiAN
Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUmFkb3Zh biBDaHl0cmFjZWsg
W21haWx0bzpSYWRvdmFuLkNoeXRyYWNla0BjZXJuLmNoXQ0KPiBTZW50OiBG cmlkYXksIE1hcmNo
IDEwLCAyMDA2IDEyOjAxIFBNDQo+IFRvOiB3aW4zMkBsaXN0cy5teXNxbC5j b20NCj4gU3ViamVj
dDogQnVpbGRpbmcgTXlTUUwgNS4wLjE4IHdpdGggbXVsdGl0aHJlYWRlZCBE TEwgcnVuLXRpbWUu
Li4NCj4gDQo+IEhpLA0KPiANCj4gICAgb3VyIHNvZnR3YXJlIHJlcXVpcmVz IG11bHRpLXRocmVh
ZGVkIERMTCAoL01EIHN3aXRjaCBvZiBWQysrIDcuMSkgcnVuLXRpbWUgYnV0 IE15U1FMIGNsaWVu
dCAmIHNlcnZlciBidWlsZHMgb25seSB3aXRoIG11bHRpLXRocmVhZGVkICgv TVQpIHJ1bi10aW1l
LiBNaXhpbmcgcnVuLXRpbWVzIGxlYWRzIHRvIGNsZWFyIGNyYXNoIHNvb25l ci1vci1sYXRlciBz
byB3ZSB3b3VsZCBsaWtlIHRvIGtub3cgaWYgL01EIGJhc2VkIE15U1FMIGJ1 aWxkIGNhbiBiZSBh
Y2hpZXZlZC4gV2UndmUgdHJpZWQgdG8gZG8gaXQgb3Vyc2VsdmVzIGJ1dCB3 ZSdyZSBydW5uaW5n
IGludG8gbGluayBwcm9ibGVtcyB3aGVuIGJ1aWxkaW5nIGxpYm15c3FsLmRs bCBhbmQgbXlzcWwg
Y2xpZW50IHByb2dyYW1zLg0KPiBXaXRoIG9yaWdpbmFsIE15U1FMIGJpbmFy aWVzIHdlIGhhZCBw
cm9ibGVtIHRvIGxpbmsgYmVjYXVzZSBvZiBfZG9zbWFwZXJyIHVucmVzb2x2 ZWQgc3ltYm9sIHdo
aWNoIHdlIGV2ZW4gY2FuJ3QgZmluZCBhIHJlYXNvbmFibGUgaW5mb3JtYXRp b24gYWJvdXQuDQo+
IA0KPiBBbnkgaW5mbyBvciBhZHZpY2UgaXMgd2VsY29tZWQuDQo+IA0KPiBD aGVlcnMNCj4gDQo+
ICAgICAgICAgICAgIFJhZG92YW4NCj4gDQo+IC0tDQo+IC0tDQo+IFJhZG92 YW4gQ2h5dHJhY2Vr
IENFUk4gSVQgUFNTDQo+IG1haWx0bzpSYWRvdmFuLkNoeXRyYWNla0BjZXJu LmNoDQo+IHBob25l
OiArNDEyMjc2NzQ1NzggZmF4OiArNDEyMjc2Njk4MzANCj4gDQo+IA0KLS0N Ci0tDQpSYWRvdmFu
IENoeXRyYWNlayBDRVJOIElUIFBTUw0KbWFpbHRvOlJhZG92YW4uQ2h5dHJh Y2VrQGNlcm4uY2gN
CnBob25lOiArNDEyMjc2NzQ1NzggZmF4OiArNDEyMjc2Njk4MzANCg0KDQoN Cg==

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
>=20
> libmysql.lib just contains the stubs for easier handling the dynamic impo=
rts - it does not reference runtime-calls.
> You could even ommit the static import libmysql.lib and import directly a=
t runtime from libmysql.dll
> by LoadLibrary/ GetProcAddress.
>=20
> armin.=20
>=20
> -----Original Message-----
> From: Radovan Chytracek [mailto:Radovan.Chytracek@cern.ch]=20
> Sent: Friday, March 10, 2006 2:53 PM
> To: Armin Schöffmann
> Cc: win32@lists.mysql.com
> Subject: RE: Building MySQL 5.0.18 with multithreaded DLL run-time...
>=20
> Hi,
> the issue is that when trying to link against MySQL original client l=
ibrary 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 w=
e run into more unresolved symbols.
>=20
> Another issue is that even for debug builds of our software stack we stil=
l 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 l=
ibs :-) MySQL on the other hand uses debug version of the C/C++ run-time fo=
r its debug builds.
>=20
> We try to find out a way to use 5.0.18 client libs without link error men=
tioned 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.
>=20
> Cheers
>=20
> Radovan
>=20
> 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.dl=
l is the dynamic lib.
> > Regards Armin.
> >=20
> >=20
> >=20
> > -----Original Message-----
> > From: Radovan Chytracek [mailto:Radovan.Chytracek@cern.ch]
> > Sent: Friday, March 10, 2006 12:01 PM
> > To: win32@lists.mysql.com
> > Subject: Building MySQL 5.0.18 with multithreaded DLL run-time...
> >=20
> > Hi,
> >=20
> > our software requires multi-threaded DLL (/MD switch of VC++ 7.1) ru=
n-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 lik=
e to know if /MD based MySQL build can be achieved. We've tried to do it ou=
rselves 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 _dosmape=
rr unresolved symbol which we even can't find a reasonable information abou=
t.
> >=20
> > Any info or advice is welcomed.
> >=20
> > Cheers
> >=20
> > Radovan
> >=20
> > --
> > --
> > Radovan Chytracek CERN IT PSS
> > mailto:Radovan.Chytracek@cern.ch
> > phone: +41227674578 fax: +41227669830
> >=20
> >=20
> --
> --
> Radovan Chytracek CERN IT PSS
> mailto:Radovan.Chytracek@cern.ch
> phone: +41227674578 fax: +41227669830
>=20
>=20
>=20
--=20
--
Radovan Chytracek CERN IT PSS
mailto:Radovan.Chytracek@cern.ch
phone: +41227674578 fax: +41227669830


--
MySQL Windows Mailing List
For list archives: http://lists.mysql.com/win32
To unsubscribe: http://lists.mysql.com/win32?unsub=3Dgcdmw-win32@m.gmane.org

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

bWl4ZWQgQyAvQysrDQoNCndlIGN1cnJlbnRseSB1c2UgYSBjdXN0b20gbGli bXlzcWwuZGxsIHRv
IHdvcmthcm91bmQgYSBoYW5kbGUtbGVhayBpbiB0aGUgc2hhcmVkLW1lbS1w cm90b2NvbCx0aGF0
IG5vYm9keSB3YW50cyB0byBmaXgsIGJ1dCBpdCB3b3JrcyBhbHNvIHdpdGgg dGhlIG9yaWdpbmFs
IGRpc3RyaWJ1dGlvbnMuDQoNCml0J3Mgc3VmZmljaWVudCB0byByZWZlcmVu Y2UgdGhlIGxpYiBv
bmNlLiB0aGUgcHJhZ21hIGlzIGEgbXMtZXh0ZW5zaW9uIGZvcmNpbmcgdGhl IGxpbmtlciB0byBp
bmNsdWRlIHRoZSBhc3NpZ25lZCBsaWIuIEFsdGVybmF0aXZlbHkgeW91IGNv dWxkIGxpc3QgdGhl
IGxpYi1uYW1lIGFzIGFkZGl0aW9uYWwgbGlicmFyeSBpbiB0aGUgbGlua2Vy IG9wdGlvbnMuDQoN
Ckkgb2JzZXJ2ZWQgc2ltaWxhciBsaW5raW5nIGlzc3VlcyB3aXRoIHRoZSBz dGF0aWMgbGlicmFy
eSBteXNxbGNsaWVudC5saWIsIGFueXdheSBpbiBteSBvcGluaW9uIGl0J3Mg cHJlZmVyYWJsZSB0
byB1c2UgdGhlIGR5bmFtaWMgbGliIC0gYWxyZWFkeSBjb25jZXJuaW5nIGJ1 Z2ZpeGVzIGFuZCB1
cGdyYWRlcyB0byB0aGUgYXBpLiANCg0Kc29tZXRoaW5nIHByZXZlbnRzIHlv dSBmcm9tIGxpbmtp
bmcgdG8gdGhlIGRsbD8NCg0KYXJtaW4uIA0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0K
RnJvbTogUmFkb3ZhbiBDaHl0cmFjZWsgW21haWx0bzpSYWRvdmFuLkNoeXRy YWNla0BjZXJuLmNo
XSANClNlbnQ6IEZyaWRheSwgTWFyY2ggMTAsIDIwMDYgNDozMiBQTQ0KVG86 IEFybWluIFNjaMO2
ZmZtYW5uDQpTdWJqZWN0OiBSRTogQnVpbGRpbmcgTXlTUUwgNS4wLjE4IHdp dGggbXVsdGl0aHJl
YWRlZCBETEwgcnVuLXRpbWUuLi4NCg0KU29ycnksIEkgaGF2ZSBvdmVybG9v a2VkIHlvdXIgZWFy
bGllciBxdWVzdGlvbiBhYm91dCB0aGUgbGlicyB3ZSBsaW5rIGFnYWluc3Qu IE15IHByb2JsZW0g
aXMgb25seSB0byBsaW5rIGFnYWluc3QgbXlzcWxjbGllbnQubGliLg0KVGhl IG9ubHkgJiBzaW5n
bGUgdW5yZXNvbHZlZCBzeW1ib2wgaXMgdGhlIF9kb3NtYXBlcnIgd2hpY2gg aXMgYmxvY2tpbmcg
dXMgZnJvbSBjb21wbGV0ZSBidWlsZCBhbmQgdGhlIG9ubHkgcmVhc29uIHdl IHN0YXJ0ZWQgdG8g
bG9vayBhdCB0aGUgd2F5IHRoZSBNeVNRTCBjbGllbnQgbGliIGlzIGJ1aWx0 Lg0KDQpSYWRvdmFu
DQoNCk9uIEZyaSwgMjAwNi0wMy0xMCBhdCAxNTo1OSArMDEwMCwgQXJtaW4g U2Now7ZmZm1hbm4g
d3JvdGU6DQo+IHdlIGhhdmUgc2V2ZXJhbCBtdWx0aXRocmVhZGVkIChkbGxz L2FwcGxpY2F0aW9u
cykgdXNpbmcgYy1ydW50aW1lIGZyb20gDQo+IHdoaWNoIHRoZSBteXNxbCBj LWFwaSBpcyBjYWxs
ZWQsIGkgc3RhdGljYWxseSBsaW5rIGFnYWluc3QgDQo+IGxpYm15c3FsLmxp YiwgaW5jbHVkZSB0
aGUgbXlzcWwtaGVhZGVycyBhbmQgdGhhdCdzIGl0DQo+IA0KPiAjaW5jbHVk ZSAibXlzcWxcbXlz
cWwuaCIgDQo+ICNpbmNsdWRlICJteXNxbFxlcnJtc2cuaCINCj4gWy4uLl0N Cj4gI3ByYWdtYSBj
b21tZW50KGxpYiwgImxpYm15c3FsLmxpYiIpDQo+IA0KPiBpZiB5b3UgZG9u J3Qgd2FudCB0byBs
aW5rIHRoZSBzdGF0aWMgcGFydCAibGlibXlzcWwubGliIg0KPiB0YWtlIGEg bG9vayBpbnRvIHdp
bjMyIGRvY3VtZW50YXRpb24gZm9yIExvYWRMaWJyYXJ5IGFuZCBHZXRQcm9j QWRkcmVzcy4NCj4g
DQo+IFRoZSBkaXNhZHZhbnRhZ2UgaW4gdGhpcyBjYXNlOiB5b3UgaGF2ZSB0 byBtYXAgZWFjaCB1
c2VkIG15c3FsLWFwaSBmdW5jdGlvbiBieSBoYW5kIChHZXRQcm9jQWRkcmVz cykgYW5kIGhhdmUg
dG8gd3JpdGUgYW4gaW5kaXZpZHVhbCB0eXBlZGVmLWNhc3QgZm9yIHRoZSBm dW5jdGlvbi1wdHJz
Lg0KPiANCj4gDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTog
UmFkb3ZhbiBDaHl0cmFjZWsgW21haWx0bzpSYWRvdmFuLkNoeXRyYWNla0Bj ZXJuLmNoXQ0KPiBT
ZW50OiBGcmlkYXksIE1hcmNoIDEwLCAyMDA2IDM6NDYgUE0NCj4gVG86IEFy bWluIFNjaMO2ZmZt
YW5uDQo+IENjOiB3aW4zMkBsaXN0cy5teXNxbC5jb20NCj4gU3ViamVjdDog UkU6IEJ1aWxkaW5n
IE15U1FMIDUuMC4xOCB3aXRoIG11bHRpdGhyZWFkZWQgRExMIHJ1bi10aW1l Li4uDQo+IA0KPiBI
aSwNCj4gDQo+ICAgICBob3cgY2FuIHlvdSBhdm9pZCBpdCB3aGVuIHVzaW5n IE15U1FMIEMgQVBJ
IGluIG91ciBhcHBzIERMTHM/DQo+IA0KPiBSYWRvdmFuDQo+IA0KPiBPbiBG cmksIDIwMDYtMDMt
MTAgYXQgMTU6NDIgKzAxMDAsIEFybWluIFNjaMO2ZmZtYW5uIHdyb3RlOg0K PiA+IFJhZG92YW4s
DQo+ID4gYWdhaW5zdCB3aGljaCBsaWIgdG8geW91IGxpbms/DQo+ID4gbGli bXlzcWwubGliIG9y
IG15c3FsY2xpZW50LmxpYg0KPiA+IA0KPiA+IGxpYm15c3FsLmxpYiBqdXN0 IGNvbnRhaW5zIHRo
ZSBzdHVicyBmb3IgZWFzaWVyIGhhbmRsaW5nIHRoZSBkeW5hbWljIGltcG9y dHMgLSBpdCBkb2Vz
IG5vdCByZWZlcmVuY2UgcnVudGltZS1jYWxscy4NCj4gPiBZb3UgY291bGQg ZXZlbiBvbW1pdCB0
aGUgc3RhdGljIGltcG9ydCBsaWJteXNxbC5saWIgYW5kIGltcG9ydCANCj4g PiBkaXJlY3RseSBh
dCBydW50aW1lIGZyb20gbGlibXlzcWwuZGxsIGJ5IExvYWRMaWJyYXJ5LyBH ZXRQcm9jQWRkcmVz
cy4NCj4gPiANCj4gPiBhcm1pbi4gDQo+ID4gDQo+ID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0t
LS0NCj4gPiBGcm9tOiBSYWRvdmFuIENoeXRyYWNlayBbbWFpbHRvOlJhZG92 YW4uQ2h5dHJhY2Vr
QGNlcm4uY2hdDQo+ID4gU2VudDogRnJpZGF5LCBNYXJjaCAxMCwgMjAwNiAy OjUzIFBNDQo+ID4g
VG86IEFybWluIFNjaMO2ZmZtYW5uDQo+ID4gQ2M6IHdpbjMyQGxpc3RzLm15 c3FsLmNvbQ0KPiA+
IFN1YmplY3Q6IFJFOiBCdWlsZGluZyBNeVNRTCA1LjAuMTggd2l0aCBtdWx0 aXRocmVhZGVkIERM
TCBydW4tdGltZS4uLg0KPiA+IA0KPiA+IEhpLA0KPiA+ICAgICB0aGUgaXNz dWUgaXMgdGhhdCB3
aGVuIHRyeWluZyB0byBsaW5rIGFnYWluc3QgTXlTUUwgb3JpZ2luYWwgY2xp ZW50IGxpYnJhcnkg
NS4wLjE4IHdlIGdldCB1bnJlc29sdmVkIHJlZmVyZW5jZSB0byBfZG9zbWFw ZXJyIGNhbGwuIFdl
IGhhdmUgZm91bmQgdGhhdCBhIGRpZmZlcmVudCBydW4tdGltZSBpcyBiZWlu ZyB1c2VkIHRvIGJ1
aWxkIGl0Lg0KPiA+IEluIHRyeWluZyB0byBidWlsZCBNeVNRTCBsaWJteXNx bC5saWIgJiBkbGwg
bGlicyBmcm9tIHNvdXJjZXMgdXNpbmcgL01EIHdlIHJ1biBpbnRvIG1vcmUg dW5yZXNvbHZlZCBz
eW1ib2xzLg0KPiA+IA0KPiA+IEFub3RoZXIgaXNzdWUgaXMgdGhhdCBldmVu IGZvciBkZWJ1ZyBi
dWlsZHMgb2Ygb3VyIHNvZnR3YXJlIHN0YWNrIHdlIHN0aWxsIHVzZSBvbiB3 aW5kb3dzIG9ubHkg
dGhlIG11bHRpLXRocmVhZGVkIERMTCBub24tZGVidWcgdmVyc2lvbiBidXQg aW5jbHVkZSBkZWJ1
ZyBpbmZvcm1hdGlvbiBvbmx5IG9mIG91ciBTVyBhcyB3ZSBkb24ndCBuZWVk IHRvIGRlYnVnIEMv
QysrIHJ1bi10aW1lIGxpYnMgOi0pIE15U1FMIG9uIHRoZSBvdGhlciBoYW5k IHVzZXMgZGVidWcg
dmVyc2lvbiBvZiB0aGUgQy9DKysgcnVuLXRpbWUgZm9yIGl0cyBkZWJ1ZyBi dWlsZHMuDQo+ID4g
DQo+ID4gV2UgdHJ5IHRvIGZpbmQgb3V0IGEgd2F5IHRvIHVzZSA1LjAuMTgg Y2xpZW50IGxpYnMg
d2l0aG91dCBsaW5rIGVycm9yIG1lbnRpb25lZCBhYm92ZS4gU28gZmFyIHdl IG9ubHkgc2VlIHRo
ZSB3YXkgb2YgcHJvdmlkaW5nIGEgaGFjayB1c2luZyBhIGR1bW15IF9kb3Nt YXBlcnIoKSBjYWxs
IGluIG9yZGVyIHRvIGF2b2lkIGl0LiBPZiBjb3Vyc2UgaWYgdGhlcmUgaXMg d2F5IHRvIGF2b2lk
IGhhY2tpbmcgTXlTUUwgc291cmNlcyB3ZSBmb2xsb3cgaXQuDQo+ID4gDQo+ ID4gQ2hlZXJzDQo+
ID4gDQo+ID4gICAgICAgICAgICAgUmFkb3Zhbg0KPiA+IA0KPiA+IE9uIEZy aSwgMjAwNi0wMy0x
MCBhdCAxMzoxNCArMDEwMCwgQXJtaW4gU2Now7ZmZm1hbm4gd3JvdGU6DQo+ ID4gPiBJIHNlZSBu
byByaXNrIHRvIGxpbmsgbGlibXlzcWwuZGxsIGR5bmFtaWNhbGx5IGFnYWlu c3QgYSBkbGwgaW1w
b3J0aW5nIHRoZSAvTUQgcnVudGltZS4NCj4gPiA+IFVzdWFsbHksIHlvdSBl dmVuIGRvbid0IGtu
b3cgYWJvdXQgdGhlIHJ1bnRpbWUtaW1wb3J0cyBvZiBhIGZvcmVpZ24gZGxs Lg0KPiA+ID4gTWl4
aW5nIHJ1bnRpbWVzIGNhdXNlcyB0cm91YmxlIHdoZW4gbGlua2luZyBzdGF0 aWNhbGx5LCBidXQg
bGlibXlzcWwuZGxsIGlzIHRoZSBkeW5hbWljIGxpYi4NCj4gPiA+IFJlZ2Fy ZHMgQXJtaW4uDQo+
ID4gPiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0K
PiA+ID4gRnJvbTogUmFkb3ZhbiBDaHl0cmFjZWsgW21haWx0bzpSYWRvdmFu LkNoeXRyYWNla0Bj
ZXJuLmNoXQ0KPiA+ID4gU2VudDogRnJpZGF5LCBNYXJjaCAxMCwgMjAwNiAx MjowMSBQTQ0KPiA+
ID4gVG86IHdpbjMyQGxpc3RzLm15c3FsLmNvbQ0KPiA+ID4gU3ViamVjdDog QnVpbGRpbmcgTXlT
UUwgNS4wLjE4IHdpdGggbXVsdGl0aHJlYWRlZCBETEwgcnVuLXRpbWUuLi4N Cj4gPiA+IA0KPiA+
ID4gSGksDQo+ID4gPiANCj4gPiA+ICAgIG91ciBzb2Z0d2FyZSByZXF1aXJl cyBtdWx0aS10aHJl
YWRlZCBETEwgKC9NRCBzd2l0Y2ggb2YgVkMrKyA3LjEpIHJ1bi10aW1lIGJ1 dCBNeVNRTCBjbGll
bnQgJiBzZXJ2ZXIgYnVpbGRzIG9ubHkgd2l0aCBtdWx0aS10aHJlYWRlZCAo L01UKSBydW4tdGlt
ZS4gTWl4aW5nIHJ1bi10aW1lcyBsZWFkcyB0byBjbGVhciBjcmFzaCBzb29u ZXItb3ItbGF0ZXIg
c28gd2Ugd291bGQgbGlrZSB0byBrbm93IGlmIC9NRCBiYXNlZCBNeVNRTCBi dWlsZCBjYW4gYmUg
YWNoaWV2ZWQuIFdlJ3ZlIHRyaWVkIHRvIGRvIGl0IG91cnNlbHZlcyBidXQg d2UncmUgcnVubmlu
ZyBpbnRvIGxpbmsgcHJvYmxlbXMgd2hlbiBidWlsZGluZyBsaWJteXNxbC5k bGwgYW5kIG15c3Fs
IGNsaWVudCBwcm9ncmFtcy4NCj4gPiA+IFdpdGggb3JpZ2luYWwgTXlTUUwg YmluYXJpZXMgd2Ug
aGFkIHByb2JsZW0gdG8gbGluayBiZWNhdXNlIG9mIF9kb3NtYXBlcnIgdW5y ZXNvbHZlZCBzeW1i
b2wgd2hpY2ggd2UgZXZlbiBjYW4ndCBmaW5kIGEgcmVhc29uYWJsZSBpbmZv cm1hdGlvbiBhYm91
dC4NCj4gPiA+IA0KPiA+ID4gQW55IGluZm8gb3IgYWR2aWNlIGlzIHdlbGNv bWVkLg0KPiA+ID4g
DQo+ID4gPiBDaGVlcnMNCj4gPiA+IA0KPiA+ID4gICAgICAgICAgICAgUmFk b3Zhbg0KPiA+ID4g
DQo+ID4gPiAtLQ0KPiA+ID4gLS0NCj4gPiA+IFJhZG92YW4gQ2h5dHJhY2Vr IENFUk4gSVQgUFNT
DQo+ID4gPiBtYWlsdG86UmFkb3Zhbi5DaHl0cmFjZWtAY2Vybi5jaA0KPiA+ ID4gcGhvbmU6ICs0
MTIyNzY3NDU3OCBmYXg6ICs0MTIyNzY2OTgzMA0KPiA+ID4gDQo+ID4gPiAN Cj4gPiAtLQ0KPiA+
IC0tDQo+ID4gUmFkb3ZhbiBDaHl0cmFjZWsgQ0VSTiBJVCBQU1MNCj4gPiBt YWlsdG86UmFkb3Zh
bi5DaHl0cmFjZWtAY2Vybi5jaA0KPiA+IHBob25lOiArNDEyMjc2NzQ1Nzgg ZmF4OiArNDEyMjc2
Njk4MzANCj4gPiANCj4gPiANCj4gPiANCj4gLS0NCj4gLS0NCj4gUmFkb3Zh biBDaHl0cmFjZWsg
Q0VSTiBJVCBQU1MNCj4gbWFpbHRvOlJhZG92YW4uQ2h5dHJhY2VrQGNlcm4u Y2gNCj4gcGhvbmU6
ICs0MTIyNzY3NDU3OCBmYXg6ICs0MTIyNzY2OTgzMA0KPiANCj4gDQo+IA0K LS0NCi0tDQpSYWRv
dmFuIENoeXRyYWNlayBDRVJOIElUIFBTUw0KbWFpbHRvOlJhZG92YW4uQ2h5 dHJhY2VrQGNlcm4u
Y2gNCnBob25lOiArNDEyMjc2NzQ1NzggZmF4OiArNDEyMjc2Njk4MzANCg0K DQoNCg==

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++
>=20
> 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 o=
riginal distributions.
>=20
> it's sufficient to reference the lib once. the pragma is a ms-extension f=
orcing the linker to include the assigned lib. Alternatively you could list=
the lib-name as additional library in the linker options.
>=20
> I observed similar linking issues with the static library mysqlclient.lib=
, anyway in my opinion it's preferable to use the dynamic lib - already con=
cerning bugfixes and upgrades to the api.=20
>=20
> something prevents you from linking to the dll?
>=20
> armin.=20
>=20
> -----Original Message-----
> From: Radovan Chytracek [mailto:Radovan.Chytracek@cern.ch]=20
> Sent: Friday, March 10, 2006 4:32 PM
> To: Armin Schöffmann
> Subject: RE: Building MySQL 5.0.18 with multithreaded DLL run-time...
>=20
> Sorry, I have overlooked your earlier question about the libs we link aga=
inst. My problem is only to link against mysqlclient.lib.
> The only & single unresolved symbol is the _dosmaperr which is blocking u=
s from complete build and the only reason we started to look at the way the=
MySQL client lib is built.
>=20
> Radovan
>=20
> On Fri, 2006-03-10 at 15:59 +0100, Armin Schöffmann wrote:
> > we have several multithreaded (dlls/applications) using c-runtime from=20
> > which the mysql c-api is called, i statically link against=20
> > libmysql.lib, include the mysql-headers and that's it
> >=20
> > #include "mysql\mysql.h"=20
> > #include "mysql\errmsg.h"
> > [...]
> > #pragma comment(lib, "libmysql.lib")
> >=20
> > if you don't want to link the static part "libmysql.lib"
> > take a look into win32 documentation for LoadLibrary and GetProcAddress=
..
> >=20
> > The disadvantage in this case: you have to map each used mysql-api func=
tion by hand (GetProcAddress) and have to write an individual typedef-cast =
for the function-ptrs.
> >=20
> >=20
> >=20
> >=20
> > -----Original Message-----
> > From: Radovan Chytracek [mailto:Radovan.Chytracek@cern.ch]
> > Sent: Friday, March 10, 2006 3:46 PM
> > To: Armin Schöffmann
> > Cc: win32@lists.mysql.com
> > Subject: RE: Building MySQL 5.0.18 with multithreaded DLL run-time...
> >=20
> > Hi,
> >=20
> > how can you avoid it when using MySQL C API in our apps DLLs?
> >=20
> > Radovan
> >=20
> > 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
> > >=20
> > > 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=20
> > > directly at runtime from libmysql.dll by LoadLibrary/ GetProcAddress.
> > >=20
> > > armin.=20
> > >=20
> > > -----Original Message-----
> > > From: Radovan Chytracek [mailto:Radovan.Chytracek@cern.ch]
> > > Sent: Friday, March 10, 2006 2:53 PM
> > > To: Armin Schöffmann
> > > Cc: win32@lists.mysql.com
> > > Subject: RE: Building MySQL 5.0.18 with multithreaded DLL run-time...
> > >=20
> > > Hi,
> > > the issue is that when trying to link against MySQL original clie=
nt library 5.0.18 we get unresolved reference to _dosmaperr call. We have f=
ound 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.
> > >=20
> > > 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 incl=
ude debug information only of our SW as we don't need to debug C/C++ run-ti=
me libs :-) MySQL on the other hand uses debug version of the C/C++ run-tim=
e for its debug builds.
> > >=20
> > > 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 du=
mmy _dosmaperr() call in order to avoid it. Of course if there is way to av=
oid hacking MySQL sources we follow it.
> > >=20
> > > Cheers
> > >=20
> > > Radovan
> > >=20
> > > 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 import=
ing 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 libmysq=
l.dll is the dynamic lib.
> > > > Regards Armin.
> > > >=20
> > > >=20
> > > >=20
> > > > -----Original Message-----
> > > > From: Radovan Chytracek [mailto:Radovan.Chytracek@cern.ch]
> > > > Sent: Friday, March 10, 2006 12:01 PM
> > > > To: win32@lists.mysql.com
> > > > Subject: Building MySQL 5.0.18 with multithreaded DLL run-time...
> > > >=20
> > > > Hi,
> > > >=20
> > > > 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 i=
t 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 _dos=
maperr unresolved symbol which we even can't find a reasonable information =
about.
> > > >=20
> > > > Any info or advice is welcomed.
> > > >=20
> > > > Cheers
> > > >=20
> > > > Radovan
> > > >=20
> > > > --
> > > > --
> > > > Radovan Chytracek CERN IT PSS
> > > > mailto:Radovan.Chytracek@cern.ch
> > > > phone: +41227674578 fax: +41227669830
> > > >=20
> > > >=20
> > > --
> > > --
> > > Radovan Chytracek CERN IT PSS
> > > mailto:Radovan.Chytracek@cern.ch
> > > phone: +41227674578 fax: +41227669830
> > >=20
> > >=20
> > >=20
> > --
> > --
> > Radovan Chytracek CERN IT PSS
> > mailto:Radovan.Chytracek@cern.ch
> > phone: +41227674578 fax: +41227669830
> >=20
> >=20
> >=20
> --
> --
> Radovan Chytracek CERN IT PSS
> mailto:Radovan.Chytracek@cern.ch
> phone: +41227674578 fax: +41227669830
>=20
>=20
>=20
--=20
--
Radovan Chytracek CERN IT PSS
mailto:Radovan.Chytracek@cern.ch
phone: +41227674578 fax: +41227669830


--
MySQL Windows Mailing List
For list archives: http://lists.mysql.com/win32
To unsubscribe: http://lists.mysql.com/win32?unsub=3Dgcdmw-win32@m.gmane.org