Rob.Conde wrote:
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.
Yes, that's the best thing to do. And while you're at it, you should also
modify the C++ namespace to make it unique for your company.
Another option is to also use both libraries statically along with
modifying the C++ namespace, which will completely protect you.
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.
In a perfect world, they wouldn't have done that, since it's obviously
going to cause big problems for a library which is as ubiquitous as Xerces-C.
However, trying to sanction an "official" binary won't even work. Since
you can build the binary with multiple compilers, and the name is always
the same regardless, you could just as easily have a problem with one
company using the Microsoft compiler, while another uses the Borland compiler.
Dave
