You are viewing a plain text version of this content. The canonical link for it is here.
Posted to p-dev@xerces.apache.org by Simon Stevenson <si...@bbc.co.uk> on 2001/07/31 16:38:23 UTC
Solaris build of xerces-p failing
we have downloaded xerces-c1_5_1-SolCC.tar
and the example binaries appear to work fine. (we set xercescroot etc...)
we then downloaded xerces perl wrapper 1.5.3
(both latest stable versions)
we had to rejig Makefile.PL to pick up the 1.5.1 library but that seemed OK
the perl Makefile.PL goes thru OK.
then in make we get the following:
Xerces.C: In function `void _wrap_SAXParser_getScanner(CV *)':
Xerces.C:16016: no matching function for call to `SAXParser::getScanner ()'
Xerces.C: In function `void _wrap_DOMParser_getScanner(CV *)':
Xerces.C:17663: no matching function for call to `DOMParser::getScanner ()'
Xerces.C: In function `void _wrap_IDOMParser_getScanner(CV *)':
Xerces.C:19492: no matching function for call to `IDOMParser::getScanner ()'
make: *** [Xerces.o] Error 1
We can't seem to find these functions in our distribution.
Simon Stevenson
Interactive Software Engineer
Interactive F&L
Room 2422
This e-mail, and any attachment, is confidential. If you have received
it in error, please delete it from your system, do not use or disclose
the information in any way, and notify me immediately. The contents of
this message may contain personal views which are not the views of the
BBC, unless specifically stated.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org
Re: Red Hat 7.1 build requirements; maybe...
Posted by Terje Bless <li...@pobox.com>.
On 01.08.01 at 23:32, Jason E. Stewart <ja...@openinformatics.com> wrote:
>Check out t/EntityResolver.t for an example of using XML Catalog. This is
>pretty rudimentary, but it does what you asked for (ask and ye shall
>recieve ;-)
Thanks jas, that's exactly what I was looking for!
>The one I looked at was:
>
>http://home.ccil.org/~cowan/XML/XCatalog.html
Thanks. I managed to find an up-to-date spec at OASIS (published yesterday,
no less!) which differs pretty heavily from that early draft. When I can
scrape together the time I'm going to look into writing support for the
full spec (though possibly just a subset at first) for Xerces-P (no
guarantees tho´).
I'm thinking a module like XML::Xerces::<EntityResolver> (suggestions for
name to use gratefully appreciated! ;D) that you init and get back a
resolver you can feed to Xerces which in turn takes a FPI or SI and returns
an InputSource.
Suggestions for namespace to use and API details welcome! :-)
I'll probably ask a bunch of Stupid Questions here until I figure out what
I need of how to interact with Xerces. Apologies in advance if I try your
patience. :-)
I'll post details when I have time and code -- :-) -- but you may want to
consider whether or not you want this for Xerces-P -- and whether it would
be sample code or a companion module -- because that will influence how I
design this beastie. Are there any license issues I should be aware of?
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org
Re: XML Catalogs in Xerces (was: Red Hat 7.1 build requirements; maybe...)
Posted by Terje Bless <li...@pobox.com>.
On 04.08.01 at 19:28, Jason E. Stewart <ja...@openinformatics.com> wrote:
>How about XML::Xerces::Catalog?
Sure. I was hung up on the EntityRevolverResolutionCamelCaps thingie;
::Catalog was just too simple and obvious at the time. :-)
>No problem, as long as you have it by tomorrow ;-)
*grumble* I will now have to get you for this. :-)
--
I have lobbied for the update and improvement of SGML. I've done it for years.
I consider it the jewel for which XML is a setting. It does deserve a bit or
polishing now and then. -- Len Bullard <cl...@ingr.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org
Re: XML Catalogs in Xerces (was: Red Hat 7.1 build requirements; maybe...)
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Terje Bless" <li...@pobox.com> writes:
> On 04.08.01 at 11:11, Jason E. Stewart <ja...@openinformatics.com>
> wrote:
>
> Ok, I'm building something as XML::Xerces::EM -- for lack of a better name
> -- but renaming it or munging the code in other ways shouldn't be a problem
> once something is actually implemented.
How about XML::Xerces::Catalog?
> Oh, ok. I was under the impression that DOM did not preserve order and that
> if current accessors did it was incidental to the implementation. If DOM is
> supposed to preserve order then I guess the accessors are deliberately
> written do do so too. No?
Correct. The only thing DOM does not guarantee order for is
attributes of a given element: they are inherently unordered according
to the spec.
> Well, I was going to go for a lazy recursive decent parser, but then they
> went and changed the semantics overnight (literally; from the Aug. 1st
> draft to the Aug. 2nd draft! ;D) so instead of first-match it now has
> longest-match semantics. I suspect these in combination makes a full parse
> necessary.
>
> OTOH, I'm not too worried if the first cut isn't 100% up to the spec. It's
> still a draft and they need thre interopoerable implementations from OASIS
> members before it progresses to final version. There's time to fine tune it
> -- or unbreak it :-) -- afterwards.
Right. My feeling is get something that works, even if it only covers
part of the spec, and then refine it (you'll notice how many releases
of Xerces.pm I've had in the past two months ;-)
> >I'm glad that you're working on this Terje. When we add support for this,
> >Xerces.pm is likely to be the only Perl module to have support for it.
>
> "...but no pressure, ok?" :-)
No problem, as long as you have it by tomorrow ;-)
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org
Re: XML Catalogs in Xerces (was: Red Hat 7.1 build requirements; maybe...)
Posted by Terje Bless <li...@pobox.com>.
On 04.08.01 at 11:11, Jason E. Stewart <ja...@openinformatics.com> wrote:
>Here's the email that talks about xerces-j support for XML Catalog:
>
>http://marc.theaimsgroup.com/?l=xerces-j-dev&m=98272746310789&w=2
Ok, I was looking at
<URL:http://lists.xml.org/archives/xml-dev/200004/msg00127.html>.
>Here's a very nice article by Norm Walsh about the whole issue, with
>pointers to the Java classes:
>
>http://www.arbortext.com/html/issue%5Fthree.html
Ah, thanks!
>So, as far as I can tell, the answer to #2 is 'No', Xerces-c doesn't
>have support for XML Catalog, so we'll have to add it to Xerces.pm
Ok, I'm building something as XML::Xerces::EM -- for lack of a better name
-- but renaming it or munging the code in other ways shouldn't be a problem
once something is actually implemented.
>I'm assuming that the XML Catalog draft you're looking at is:
>
>http://www.oasis-open.org/committees/entity/spec-2001-08-02.html
Yeah. I was looking things up on my Linux box and sending email from my
Mac; I'd meant to include references for everything, but lazyness got the
better of me. :-)
>No, DOM preserves order. The tree structure that it builds in memory,
>exactly models the underlying structure of the document. So you can
>traverse the DOM tree using a tree walker and get the exact same thing
>you would using SAX.
>
>The importance question I had was whether the DOM accessor methods,
>like getElementsByTagName() preserved order, and given a simple test
>it appears that they do.
Oh, ok. I was under the impression that DOM did not preserve order and that
if current accessors did it was incidental to the implementation. If DOM is
supposed to preserve order then I guess the accessors are deliberately
written do do so too. No?
>There is another important issue, though. I suspected that they needed
>to be handled in order, but to get something out with 1.5.4 I just
>dumped each element collection into a hash table (one for PUBLIC ids,
>and another for SYSTEM ids). This might not work. I'll have to think
>about it once I read the spec.
Well, I was going to go for a lazy recursive decent parser, but then they
went and changed the semantics overnight (literally; from the Aug. 1st
draft to the Aug. 2nd draft! ;D) so instead of first-match it now has
longest-match semantics. I suspect these in combination makes a full parse
necessary.
OTOH, I'm not too worried if the first cut isn't 100% up to the spec. It's
still a draft and they need thre interopoerable implementations from OASIS
members before it progresses to final version. There's time to fine tune it
-- or unbreak it :-) -- afterwards.
>I'm glad that you're working on this Terje. When we add support for this,
>Xerces.pm is likely to be the only Perl module to have support for it.
"...but no pressure, ok?" :-)
As should be obvious I'm in somewhat over my head. I'm betting on solving
this by a "Swim or Drown" philosophy. :-)
>I'm not much of a SAX person, but as far as I can tell, no. The only
>issue is that SAX1 might be better supported by Xerces.pm. I can't say
>that for certain, but I just don't have very many tests in place for
>SAX2.
Ok, if I can use DOM I see no particular reason to go with SAX here.
Thanks for the help, jas!
--
>For all I know they probably have standards on
>which direction to put the thread on a bolt.
That would be ISO 261:1973. -- John Cowan <co...@ccil.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org
Re: XML Catalogs in Xerces (was: Red Hat 7.1 build requirements; maybe...)
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Terje Bless" <li...@pobox.com> writes:
> Ok. I dug around XML-Deviant and XML-Dev archives a little, and I
> came across a curious reference from April Y2K or so that claims
> Xerces (-J, presumably) supports EntityResolution using XML Catalogs
> of the Cowan variety.
>
> Question: Is this correct?
>
> Question: Does Xerces-C++ -- and, by extension, Xerces-P -- do that?
Here's the email that talks about xerces-j support for XML Catalog:
http://marc.theaimsgroup.com/?l=xerces-j-dev&m=98272746310789&w=2
So the answer to #1 seems to be "Yes".
Here's a very nice article by Norm Walsh about the whole issue, with
pointers to the Java classes:
http://www.arbortext.com/html/issue%5Fthree.html
However, for xerces-c this is as close as we get:
http://marc.theaimsgroup.com/?l=xerces-c-dev&m=97966491924777&w=2
So, as far as I can tell, the answer to #2 is 'No', Xerces-c doesn't
have support for XML Catalog, so we'll have to add it to Xerces.pm
> I'm guessing that the answer to the former is "Yes" but the answer
> to the latter is "No", or you would have used that instead of
> futzing with your own version using DOMParse in EntityResolver.t.
>
> Given that, I'm continuing to tinker with my own Entity Manager in Perl.
>
> A little study has also revealed that OASIS has a running Committee
> on Entity Resolution using XML Catalogs that is about to publish a
> final specification for the mechanism using a significantly
> different (from the Cowant draft) syntax.
>
> Question: Is it safe to assume that Xerces-* has not been updated to
> use the new OASIS (draft) specification?
I'm assuming that the XML Catalog draft you're looking at is:
http://www.oasis-open.org/committees/entity/spec-2001-08-02.html
Nothing on my searches found anything that indicated either xerces-c/j
have begun to use this spec.
> Another issue is that the above specification seems to require that XML
> Catalogs be processed sequentially (i.e. the physical order in the file is
> significant).
>
> Question: Will this require the use of SAX rather then DOM
> interfaces?
No, DOM preserves order. The tree structure that it builds in memory,
exactly models the underlying structure of the document. So you can
traverse the DOM tree using a tree walker and get the exact same thing
you would using SAX.
The importance question I had was whether the DOM accessor methods,
like getElementsByTagName() preserved order, and given a simple test
it appears that they do. So given:
<top>
<foo att="one"/>
<foo att="two"/>
<foo att="three"/>
</top>
gives:
DB<9> @e = $doc->getElementsByTagName('foo')
DB<10> x map {$_->getAttribute('att')} @e
0 'one'
1 'two'
2 'three'
There is another important issue, though. I suspected that they needed
to be handled in order, but to get something out with 1.5.4 I just
dumped each element collection into a hash table (one for PUBLIC ids,
and another for SYSTEM ids). This might not work. I'll have to think
about it once I read the spec.
> And as if I hadn't exposed enough of my ignorance on the subject yet;
> is there any reason to use SAX1 for new applications instead of SAX2? :-)
I'm not much of a SAX person, but as far as I can tell, no. The only
issue is that SAX1 might be better supported by Xerces.pm. I can't say
that for certain, but I just don't have very many tests in place for
SAX2.
I'm glad that you're working on this Terje. When we add support for
this, Xerces.pm is likely to be the only Perl module to have support
for it.
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org
XML Catalogs in Xerces (was: Red Hat 7.1 build requirements; maybe...)
Posted by Terje Bless <li...@pobox.com>.
On 01.08.01 at 23:32, Jason E. Stewart <ja...@openinformatics.com> wrote:
>Check out t/EntityResolver.t for an example of using XML Catalog. This
>is pretty rudimentary, but it does what you asked for (ask and ye
>shall recieve ;-)
>
>> Oh, and does anyone have a URL for a definition of an "XML Catalog"? I
>> haven't been able to find a spec for it and the implication is that they
>> aren't the same as ISO SGML Open Catalogs?
>
>The one I looked at was:
>
>http://home.ccil.org/~cowan/XML/XCatalog.html
Ok. I dug around XML-Deviant and XML-Dev archives a little, and I came
across a curious reference from April Y2K or so that claims Xerces (-J,
presumably) supports EntityResolution using XML Catalogs of the Cowan
variety.
Question: Is this correct?
Question: Does Xerces-C++ -- and, by extension, Xerces-P -- do that?
I'm guessing that the answer to the former is "Yes" but the answer to the
latter is "No", or you would have used that instead of futzing with your
own version using DOMParse in EntityResolver.t.
Given that, I'm continuing to tinker with my own Entity Manager in Perl.
A little study has also revealed that OASIS has a running Committee on
Entity Resolution using XML Catalogs that is about to publish a final
specification for the mechanism using a significantly different (from the
Cowant draft) syntax.
Question: Is it safe to assume that Xerces-* has not been updated to
use the new OASIS (draft) specification?
Another issue is that the above specification seems to require that XML
Catalogs be processed sequentially (i.e. the physical order in the file is
significant).
Question: Will this require the use of SAX rather then DOM interfaces?
And as if I hadn't exposed enough of my ignorance on the subject yet;
is there any reason to use SAX1 for new applications instead of SAX2? :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org
Re: Red Hat 7.1 build requirements; maybe...
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Terje Bless" <li...@tss.no> writes:
> On 01.08.01 at 20:26, Jason E. Stewart <ja...@openinformatics.com> wrote:
> >
> >Happily, the EntityResolver interface finally works!!! I'm releasing
> >Xerces.pm-1.5.4 tonight which will have support for Xerces-C-1.5.1 and the
> >new EntityResolver interface.
>
> It wouldn't also happen to have an example of using it that I could grab as
> a starting point? Nothing fancy; just enough to, say, DOMCount a stock
> XHTML 1.0 document (flat DTD)? Grab the FPI at an appropriate moment, do
> whatever magic is necessary to create and «hand back an InputSource», and
> then proceede based on that?
>
> Considering that I'll need this for basically _everything_, it's not
> entirely unlikely I'll implement some level of Catalog support as a first
> step while learning Xerces-P. Full Extended SGML Open Catalogs if I can
> pull it off (it may be beyond me tho´). I'd be happy to contribute that
> code back if it pans out and you want it BTW.
Check out t/EntityResolver.t for an example of using XML Catalog. This
is pretty rudimentary, but it does what you asked for (ask and ye
shall recieve ;-)
> Oh, and does anyone have a URL for a definition of an "XML Catalog"? I
> haven't been able to find a spec for it and the implication is that they
> aren't the same as ISO SGML Open Catalogs?
The one I looked at was:
http://home.ccil.org/~cowan/XML/XCatalog.html
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org
Re: Red Hat 7.1 build requirements; maybe...
Posted by Terje Bless <li...@tss.no>.
On 01.08.01 at 20:26, Jason E. Stewart <ja...@openinformatics.com> wrote:
>You are currently not subscribed to the list, this isn't a problem, it
>just means that all your emails have to come to me first, and then I
>approve them, and then they go to the list. Since it seems like you're
>going to be sending a few emails, you may want to subscribe (send an
>empty message to xerces-p-dev-subscribe@xml.apache.org).
Ooops! Sorry about that. I'm in the process of switching to a new email
address and I guess I goofed on Xerces-P-Dev. I'll switch over to the new
address. Sorry for the extra work Jason!
>Sadly, XML Catalogs are not part of Xerces. To do this you will need to
>implement an EntityResolver, that grabs the publicId and hands back an
>InputSource for the DTD.
>
>Happily, the EntityResolver interface finally works!!! I'm releasing
>Xerces.pm-1.5.4 tonight which will have support for Xerces-C-1.5.1 and the
>new EntityResolver interface.
It wouldn't also happen to have an example of using it that I could grab as
a starting point? Nothing fancy; just enough to, say, DOMCount a stock
XHTML 1.0 document (flat DTD)? Grab the FPI at an appropriate moment, do
whatever magic is necessary to create and «hand back an InputSource», and
then proceede based on that?
Considering that I'll need this for basically _everything_, it's not
entirely unlikely I'll implement some level of Catalog support as a first
step while learning Xerces-P. Full Extended SGML Open Catalogs if I can
pull it off (it may be beyond me tho´). I'd be happy to contribute that
code back if it pans out and you want it BTW.
Oh, and does anyone have a URL for a definition of an "XML Catalog"? I
haven't been able to find a spec for it and the implication is that they
aren't the same as ISO SGML Open Catalogs?
OH, another random idea off the top of my head: You should put out a
request for sampe code in a prominent place in the README to encourage
users to submit sample code to the project. Short of good documentation,
sample code is the best way to learn the details of a new «library» IMO.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org
Re: Red Hat 7.1 build requirements; maybe... (was: Solaris build of xerces-p failing)
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
Hej Terje,
You are currently not subscribed to the list, this isn't a problem, it
just means that all your emails have to come to me first, and then I
approve them, and then they go to the list. Since it seems like you're
going to be sending a few emails, you may want to subscribe (send an
empty message to xerces-p-dev-subscribe@xml.apache.org).
If you don't want to, that's fine with me, too.
"Terje Bless" <li...@pobox.com> writes:
> On 01.08.01 at 14:12, Jason E. Stewart <ja...@openinformatics.com> wrote:
>
> First Stupid Question: Why is it complaining about http URLs? Doesn't
> Xerces support HTTP for resolving System Identifiers? Come to think of it,
> doesn't it support SGML Open Catalogs (XML Catalogs?) to lookup FPIs?
>
> I'm going to be using this to Validate stuff like XHTML and MathML; the FPI
> and SI are going to be "Well Known", out of my control, and require a
> network operation unless I can tell Xerces to use a local catalog to
> resolve it (and to "OVERRIDE YES").
Sadly, XML Catalogs are not part of Xerces. To do this you will need
to implement an EntityResolver, that grabs the publicId and hands back
an InputSource for the DTD.
Happily, the EntityResolver interface finally works!!! I'm releasing
Xerces.pm-1.5.4 tonight which will have support for Xerces-C-1.5.1 and
the new EntityResolver interface.
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org
Re: Red Hat 7.1 build requirements; maybe... (was: Solaris build of xerces-p failing)
Posted by Terje Bless <li...@pobox.com>.
On 01.08.01 at 14:12, Jason E. Stewart <ja...@openinformatics.com> wrote:
>I guess I never asked to see what the compile problem was... Sorry.
I guess I should have taken the huge honking "hint" when it died on a
unresolved symbol: pthread_mutex_destroy. :-)
>If make test runs and you get all tests successful, then you have a
>fully working copy of Xerces.pm, congratulations!
Cool! Now to find some time to play with it so I can figure it out and
complain about specific bits of the documentation instead of just
complaining in general... :-)
First Stupid Question: Why is it complaining about http URLs? Doesn't
Xerces support HTTP for resolving System Identifiers? Come to think of it,
doesn't it support SGML Open Catalogs (XML Catalogs?) to lookup FPIs?
I'm going to be using this to Validate stuff like XHTML and MathML; the FPI
and SI are going to be "Well Known", out of my control, and require a
network operation unless I can tell Xerces to use a local catalog to
resolve it (and to "OVERRIDE YES").
Am I going to have to dig into the API docs to set this up? Implement an
Entity Manager in higher-level code?
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org
Re: Red Hat 7.1 build requirements; maybe... (was: Solaris build of xerces-p failing)
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Terje Bless" <li...@pobox.com> writes:
> On 01.08.01 at 08:00, Terje Bless <li...@pobox.com> wrote:
>
> >*sigh* I was afraid of that. Guess there's nothing for it but to go ahead
> >and try to build a private copy for Xerces-P. :-(
>
> And since that didn't work, I decided to try Voodoo... :-)
>
> With standard Red Hat 7.1 Perl 5.6.0, I modified Makefile.PL to add
> "-lpthread" to the flags and whaddayaknow; it builds!
[snip]
> Does anyone else on Red Hat 7.1 with compile troubles want to try
> that and see if it really /is/ that simple? I see Makefile.PL
> originally specified -lpthread, but it was commented out for some
> reason, so there may well be something blindingly obvious that I'm
> missing here.
I guess I never asked to see what the compile problem was... Sorry.
I accidentally removed -lpthread in an attempt to force MakeMaker to
find -lxerces, and die if it couldn't find it. I never put it back :-(
If make test runs and you get all tests successful, then you have a
fully working copy of Xerces.pm, congratulations!
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org
Red Hat 7.1 build requirements; maybe... (was: Solaris build of xerces-p failing)
Posted by Terje Bless <li...@pobox.com>.
On 01.08.01 at 08:00, Terje Bless <li...@pobox.com> wrote:
>*sigh* I was afraid of that. Guess there's nothing for it but to go ahead
>and try to build a private copy for Xerces-P. :-(
And since that didn't work, I decided to try Voodoo... :-)
With standard Red Hat 7.1 Perl 5.6.0, I modified Makefile.PL to add
"-lpthread" to the flags and whaddayaknow; it builds!
And the tests run fine...
And I'm even able to get DOMCount.pl running... (37, right?) :-)
IOW: To get Xerces-P 1.5.3 to build on Red Hat 7.1 requires:
1) Xerces-C 1.5.0 built from source.
2) $LIBS .= " -lpthread"; in Makefile.PL.
OTOH, that sounds suspiciously simple so I won't be the least bit surprised
if it turns out my installation is borken afterall... Or that I did
something in my sleep that was what /really/ made it build.. Or maybe the
cat walked across the keyboard... Pessimist? Moi? :-)
Does anyone else on Red Hat 7.1 with compile troubles want to try that and
see if it really /is/ that simple? I see Makefile.PL originally specified
-lpthread, but it was commented out for some reason, so there may well be
something blindingly obvious that I'm missing here.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org
Re: Solaris build of xerces-p failing
Posted by Terje Bless <li...@pobox.com>.
On 31.07.01 at 22:51, Jason E. Stewart <ja...@openinformatics.com> wrote:
>Unfortunately, the problem with RedHat 7.1 seems to be with the perl
>binary they distribute. Not matter what I tried, I couldn't get it to
>build Xerces.pm. The binary for 7.1 emits bogus compile lines for
>gcc that don't work for Xerces. As soon as I built perl from source, I
>had no trouble.
*sigh* I was afraid of that. Guess there's nothing for it but to go ahead
and try to build a private copy for Xerces-P. :-(
BTW, I note that my Perl was built against linux 2.2.17-smp -- which sounds
suspciously like Red Hat 7.0 with patches to me -- whereas Red Hat 7.1
includes linux 2.4.2. I assume there goes differences in glibc, gcc, and
kernel headers (for, say, networking constants) with this difference. What
was your Perl built with and what does the new version say?
5.6.0 or 5.6.1 BTW?
I'm picking 5.6.0 off my friendly neighbourhood CPAN mirror as I'm typing.
I'll build it with defaults, except $prefix, and let you know how that
goes. (and what diffs there is in "perl -V" output).
>PS. Building perl from source is simpler than building xerces.
Sure. It's not building it; it's installing it without messing up @INC and
without /getting/ it messed up by the next Red Hat update that Red Carpet
pushes onto my box. :-|
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org
Re: Solaris build of xerces-p failing
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Terje Bless" <li...@pobox.com> writes:
> On 31.07.01 at 09:15, Jason E. Stewart <ja...@openinformatics.com> wrote:
>
> > http://marc.theaimsgroup.com/?l=xerces-p-dev&r=1&w=2
> >
> >The short answer is Xerces-C-1.5.1 changed the Parser interface, use
> >Xerces-C-1.5 until I make the next release of Xerces.pm.
>
> I just tried building Xerces-P on Red Hat Linux 7.1 against Xerces-C 1.5.0
> and 1.5.1, and against both source and binary distributions of Xerces-C. No
> matter which combination I try I get either a «no matching function» during
> build, or a core during «make test». I haven't tried building with the
> compat-egcs compilers yet (RH 6.2 compatibility versions) and I'm not
> planning on rebuilding my Perl any time soon (as was suggested at one point
> on the list).
>
> Are these problems both likely to disappear with the next release of
> Xerces-P or do you need anything to pin either of them down?
Hej Terje,
Unfortunately, the problem with RedHat 7.1 seems to be with the perl
binary they distribute. Not matter what I tried, I couldn't get it to
build Xerces.pm. The binary for 7.1 emits bogus compile lines for
gcc that don't work for Xerces. As soon as I built perl from source, I
had no trouble.
jas.
PS. Building perl from source is simpler than building xerces. just
hit enter whenever configure asks you a question, and install it
wherever you wish, i.e. your home directory.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org
Re: Solaris build of xerces-p failing
Posted by Terje Bless <li...@pobox.com>.
On 31.07.01 at 09:15, Jason E. Stewart <ja...@openinformatics.com> wrote:
> http://marc.theaimsgroup.com/?l=xerces-p-dev&r=1&w=2
>
>The short answer is Xerces-C-1.5.1 changed the Parser interface, use
>Xerces-C-1.5 until I make the next release of Xerces.pm.
I just tried building Xerces-P on Red Hat Linux 7.1 against Xerces-C 1.5.0
and 1.5.1, and against both source and binary distributions of Xerces-C. No
matter which combination I try I get either a «no matching function» during
build, or a core during «make test». I haven't tried building with the
compat-egcs compilers yet (RH 6.2 compatibility versions) and I'm not
planning on rebuilding my Perl any time soon (as was suggested at one point
on the list).
Are these problems both likely to disappear with the next release of
Xerces-P or do you need anything to pin either of them down?
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org
Re: Solaris build of xerces-p failing
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Simon Stevenson" <si...@bbc.co.uk> writes:
> we have downloaded xerces-c1_5_1-SolCC.tar and the example binaries
> appear to work fine. (we set xercescroot etc...)
>
> we then downloaded xerces perl wrapper 1.5.3
Hi Simon,
You can find an explanation of this in the list archive:
http://marc.theaimsgroup.com/?l=xerces-p-dev&r=1&w=2
The short answer is Xerces-C-1.5.1 changed the Parser interface, use
Xerces-C-1.5 until I make the next release of Xerces.pm.
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org