David,
No strong opinions either way. So in the absence
of a strong opinion, always go the easiest path.
Let's just mark as non-thread safe, and if we
get people who need it, we can review.
I'll fix configure.in - won't bother looking at
gcc version, I'll just compile up something that
breaks with 2.95.4 and -fno-elide.... If it
breaks, I'll disable, otherwise I'll leave it in.
That way, it should auto-detect in the unlikely
event that there are future problems in gcc.
The latest Debian stable release uses 2.95.4, so
for selfish reasons (my main workstation at
home is deb 3.0r1) I'd prefer 2.95.4, but I think
you are correct. I don't think we can reasonably
expect people to be still using 2.95. Debian
uses it because the primary aim is to be
completely stable. They are now migrating to
3.2.3 for the next release.
Maybe the best idea is to go instead for a Linux
variant and version that we believe is most
popular amongst the user-base.
E.g. RedHat 8.0 runs 3.2 as the base install.
(Ugly).
Should we post the question in xalan-c-users?
Cheers,
Berin
>
> From: David N Bertoni/Cambridge/IBM <[EMAIL PROTECTED]>
> Subject: Re: Re: gcc 2.95.* support
> Date: 20/02/2003 10:09:06
> To: [EMAIL PROTECTED]
>
>
>
>
>
> 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
>
>
>
>
>
This message was sent through MyMail http://www.mymail.com.au
