Hey John,
Not sure how that helps? Windows is only going to load one
"xerces-c_2_6.dll" into a process...so whichever it loads, you're screwed?
Or am I misunderstanding?
Rob
-----Original Message-----
From: Bossom, John [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 02, 2007 6:19 PM
To: xalan-c-users@xml.apache.org
Subject: RE: dll Hell...
We solved the problem by wrapping the external interfaces with a C++
namespace.
-----Original Message-----
From: Rob.Conde [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 02, 2007 6:16 PM
To: xalan-c-users@xml.apache.org
Subject: dll Hell...
Hey guys,
I've run into a situation with xerces, but I thought I'd bring
it up here because it applies equally. Currently we're using xerces 2.6
and xalan
1.9 because we're using vs2005 and don't want to release with
"unofficial"
versions (i.e. the trunks). Those xerces 2.6 and xalan 1.9 are built
with
vs2003 due to the well known build problems with xalan and vs2005. So
the name of our xerces dll, as default, is "xerces-c_2_6.dll". Our
application integrates with Matlab via their API. It turns out they're
also using xerces. Also, version 2.6. Our application and Matlab were
happily co-existing until the latest version of Matlab was released. The
problem? It appears they decided to recompile xerces using vs2005.
Probably among other things, this changes "unsigned short const *" to
"wchar_t const *" which windows recognizes differently when trying to
resolve dynamically linked methods. In addition, their dll is built
using ICU. Despite these differences, their dll is also named
"xerces-c_2_6.dll"...I'm sure you see where I'm going. Our app loads up,
loading our version of the xerces dll...then we load the matlab dll...it
tries to load its xerces dll, but gets ours instead. It can't resolve
certain methods and fails.
As I understand it, the only good solution is to rebuild the
xerces/xalan libraries naming them something like
MyCompanyXerces_2_6.dll etc. and then relink our application to those
new libraries.
I'd appreciate opinions on this. It seems to me that it should be
encouraged do this renaming exercise whenever building the xerces/xalan
libraries yourself. In other words, only the "official" xerces binary
should be named "xerces-c_2_6.dll". Of course, this issue isn't isolated
to xerces/xalan and perhaps it was just a matter of time before we ran
into this. But the fact that a company as big as Mathworks(Matlab)
failed to anticipate this issue makes me feel that perhaps something
more proactive can be done.
Or maybe I'm missing something?
Robert Conde
This message may contain privileged and/or confidential information.
If you have received this e-mail in error or are not the intended recipient,
you may not use, copy, disseminate or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so. Thank you.
