Hello All,
Actually, this has been the case for some time. I've recompiled Xalan and
Xerces and had the naming conflict even with the released Xerces 1.4 and
Xalan 1.1 All versions I've tried have this issue. On the other hand, I'm
not sure why, but they are only warnings in Visual Age 5.0 compiler
(because it does several stupid things in my opinion) and we ignore them.
Up to this point, it has been working. I'm not sure why unless the QName
with the larger data element is the one that wins in the linking, and that
all function names are unique to the two classes.
I get this warning even building two shared libraries...
YMMV in that Visual Age 5.0 regularly generates TONS of duplicate symbol
warnings to the point that our development team has turned them off.
Anthony
James Berry
<jberry@critica To: Xerces C Dev
<[EMAIL PROTECTED]>
lpath.com> cc:
Subject: Re: QName conflict with
Xalan-C++
06/20/2001
01:45 PM
Please respond
to xerces-c-dev
Hi David,
I'm trying to figure out why that didn't show up in my linking between the
two last week. Is this something very new, or does this show up only during
static linking of the two?
Thanks, by the way, for the catch on the namespace processing issue. I'm
working on a Mac OS X port of Xalan C++, along with Xerces 1.5. I'd been
seeing the issue, but had assumed that it was still something busted in my
Xalan port! All is better now following Tinny's fix for that problem.
But then I'm confused, since I'm not seeing the conflict with Qname... ;)
-jdb
On 6/20/01 9:03 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> Xerces has defined a class called QName. Xalan-C++ has a class of the
same
> name and there is now a conflict with building Xalan using the latest
> Xerces.
>
> Obviously, without namespaces, we're going to continue to have collisions
> like this, if we don't have a policy for naming such classes.
>
> I mentioned in the email about the conflict with StringTokenizer that we
> have taken to using "Xalan" as a prefix for such classes. I urge the
> Xerces developer to consider doing something like this as well. The
> overhead of fixing Xalan to work around this conflict is not
insignificant,
> and I'd like to avoid it in the future. This will also help
> interoperability with other XML application as well.
>
> Dave
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
/**********************************
James D. Berry
mailto:[EMAIL PROTECTED]
vox:503.265.1213 fax:503.222.3020
**********************************/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
