dll Hell...

["Rob.Conde" <Ro...@ai-solutions.com>]

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

Re: dll Hell...

[Vitaly Prapirny <ma...@mebius.net>]

David Bertoni wrote:
> 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.
It's not the case because of different dll names in Borland and 
Microsoft projects in the xerces sources :)

Good luck!
	Vitaly

Re: dll Hell...

[David Bertoni <db...@apache.org>]

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

RE: dll Hell...

["Rob.Conde" <Ro...@ai-solutions.com>]

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:John.Bossom@Cognos.COM] 
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:Rob.Conde@ai-solutions.com] 
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.

Re: dll Hell...

[Nicholas Bastin <ni...@gmail.com>]

On 8/2/07, Lewis G. Pringle, Jr. <le...@recordsforliving.com> wrote:
> I solved the problem by just using static linking. DLLs may have been worth
> the trouble they created when PCs came with 10MB hard disks. But they've
> almost totally outlived their usefulness (or at least are dramatically
> over-used).

It doesn't have anything to do with disk space, and has everything to
do with memory utilization.  DLLs didn't exist when PCs came with 10MB
hard disks.

> Stuff like Xerces/Xalan - implementation details of your product - not
> integration points - should probably not be using DLLs.

Because you like to waste the memory of your app users?  I run 5-6
apps that use Xalan, and I'd prefer it if that fact didn't cost me
100MB of memory because every app hoisted it into their own heap.

The *real* problem, in this case, is that two DLLs which are NOT the
same, are named the same.  Xalan built with ICU should have a
different name.

--
Nick

RE: dll Hell...

["Lewis G. Pringle, Jr." <le...@RecordsForLiving.com>]

I solved the problem by just using static linking. DLLs may have been worth
the trouble they created when PCs came with 10MB hard disks. But they've
almost totally outlived their usefulness (or at least are dramatically
over-used).

Stuff like Xerces/Xalan - implementation details of your product - not
integration points - should probably not be using DLLs.

			Lewis.


-----Original Message-----
From: Bossom, John [mailto:John.Bossom@Cognos.COM] 
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:Rob.Conde@ai-solutions.com] 
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.

RE: dll Hell...

["Bossom, John" <Jo...@Cognos.COM>]

And recompiling, of course! 

-----Original Message-----
From: Bossom, John [mailto:John.Bossom@cognos.com] 
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:Rob.Conde@ai-solutions.com]
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.

RE: dll Hell...

["Bossom, John" <Jo...@Cognos.COM>]

We solved the problem by wrapping the external interfaces with a C++
namespace. 

-----Original Message-----
From: Rob.Conde [mailto:Rob.Conde@ai-solutions.com] 
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.