Hi Berin,
The bug is that string pools are not synchronized, so getting names and
values from nodes will not be synchronized. It can be done (it's
implemented for the old bridge using XercesLiaisonXalanDOMStringPool), but
I'm wondering if it's even worthwhile. Multithreaded performance will not
be very good because of the synchronization cost, and you can use Xalan's
source tree if you really want this. On the other hand, we supported it
with the old wrapper and the implementation is pretty trivial. I'm
ambivalent, so maybe you have a strong opinion?
I agree the second option using the configure script is the way to go. Do
you want to give it a shot? If so, you should double-check that configure
and configure.in are in synch. I'll admit I've been in the habit of just
editing configure and configure.in rather than re-generating configure from
configure.in. (I'm very bad...) I think gcc 3.1 is the first version that
needs the new option.
This also brings up the tough decision about what version of gcc we use for
the release. Xerces is using the Intel compiler for their release, and I
don't want to do that for ours. That means we have to build and distribute
Xerces with our Linux distribution, but it does allow us to choose the
compiler version. I'm tempted to say we go with 3.2.2, since that's the
latest stable release. 3.2.1 seems like a bad idea, since it had some
regressions and 3.2.1 binaries will not be compatible with 3.2.2+. On the
other hand, I do think the 2.95 series is getting a bit long in the tooth,
so I'd rather not go that way.
Dave
<[EMAIL PROTECTED]
om.au> To: [EMAIL PROTECTED]
cc: (bcc: David N
Bertoni/Cambridge/IBM)
02/19/2003 01:59 Subject: Re: Re: gcc 2.95.* support
PM
Please respond
to xalan-dev
Dave,
What's the bug? I can see cases where it would
be extremely useful to have multiple threads
processing a single input document, but you could
probably meet the requirement using the Xalan
DOM. From your comment below, I'd guess it's not
an easy fix?
On the 2.95.x support - I can see two options.
1. Put something in runConfigure that runs gcc
to determine a version number, and then use that
to define some variable that can be set in
Makefile.in.
2. Put the same change in the linux section of
configure.in to quickly run gcc with a small
input source that uses the templates and will
break with -fno-elide-constructors. Then set
the variables accordingly.
Personally I'd go with the second, even though
the history up until now appears to have been to
go with checks in runConfigure.
I don't think it's a hard thing to add in either
case.
My call would be number 2.
Cheers,
Berin
>
> From: David N Bertoni/Cambridge/IBM <[EMAIL PROTECTED]>
> Subject: Re: gcc 2.95.* support
> Date: 20/02/2003 3:28:06
> To: [EMAIL PROTECTED]
>
>
>
>
>
> Hi Berin,
>
> Weird, the using declarations broke 2.95.3? Thanks for catching that!
>
> I think we should still support those versions, but as you said, it will
> require some ugly stuff. What did you have in mind?
>
> By the way, I just realized there's a thread-safety bug in the new Xerces
> wrapper. I'm thinking maybe we can just declare it not thread-safe
rather
> than fix the problem. I'm not sure how valuable that "feature" is any
way.
> What do you think?
>
> Dave
>
>
>
>
> Berin Lautenbach
> <[EMAIL PROTECTED] To: Xalan Developers
<[EMAIL PROTECTED]>
> om.au> cc: (bcc: David N
Bertoni/Cambridge/IBM)
> Subject: gcc 2.95.*
support
> 02/19/2003 01:23
> AM
> Please respond
> to xalan-dev
>
>
>
>
> David,
>
> What's the feeling on support for 2.95.3/4 in 1.5? I've just checked in
> a change to the GCC include file to disable "using" declerations for gcc
> < 3 as this appears to break the XPath Function headers. (Now compiles
> again!)
>
> However there is still the problem in the Makefile which is going to be
> interesting to work around. (Although we can do something fancy in
> runConfigure if we have to as a short term fix - ugly.)
>
> Cheers,
> Berin
>
>
>
>
>
This message was sent through MyMail http://www.mymail.com.au
