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
