"ePrints Support" <[EMAIL PROTECTED]> writes:
> Hi,
>
> If you're not the right person to ask about this, sorry
> - I failed to subscribe to the mailing list (is it broken?)
> and I don't want to log this as a bug until I know that it
> is not just us being dim.
Hi Christopher,
I'm the moderator for the mailing list, and the primary (only?)
developer for the project at the moment. So I gues that would make me
the correct person...
I, too, had trouble subscribing to the list.
Try this piece of advice:
You can start a subscription for an alternate address, for example
"[EMAIL PROTECTED]", just add a hyphen and your address (with '='
instead of '@') after the command word:
<[EMAIL PROTECTED]>
Send the subscription request from a different account than the one
you used (hint it seems that apache's listserv doesn't like dynamic IP
accounts, or addresses that don't properly reverse-resolve so use a
machine with a static IP).
> I'm developing a medium size free-software application
> for generating open archives on the web. I've been using
> the perl XML::DOM library. We're almost completely commited
> to using DOM but XML::DOM is horribly inefficient.
Yes, I had to leave it for that reason as well. Xerces-1.4 is better,
and Xerces-1.5 IDOM interface is *much* better (the only problem
being, I haven't built the interface to IDOM yet :-(
> My assistant suggested Xerces-P as a drop in alternative,
Well, almost drop-in... There are some differences (the namespace for
one), but I think they are minor.
> but we've been having real trouble getting it to work. It
> dumps core everytime.
>
> Doing a bit of investigating with a debugger we found it
> is dying at some of the pthread code:
>
> --<snip>--
> #0 __pthread_mutex_lock (mutex=0x818c780) at internals.h:371
> 371 internals.h: No such file or directory.
> in internals.h
> (gdb) up
> #1 0x4034418d in XMLPlatformUtils::lockMutex (mtxHandle=0x818c780) at
>LinuxPlatformUtils.cpp:634
> 634 if (pthread_mutex_lock((pthread_mutex_t*) mtxHandle))
> --<snip>--
>
> Does xerces-p require a threaded perl (sob)?
No, not at all. It does need a working pthreads however which seems to
be your trouble. What version of Xerces-C and Xerces.pm are you using?
> We're using redhat 7.1 (upgraded machine from 6.2) and perl 5.6.1
This should be fine. Anyone else using 7.1 out there?
> Also we would like to use this as an integral component of our
> system, so we are keen to make it easy for people to install -
> currently it needs xerces-c xerces-p AND swig... any comments or
> suggestions welcome.
SWIG *should* be unnecessary. I include an already SWIG'ed version of
Xerces.pm and Xerces.C with each distribution. Someone commented that
they were having trouble, and it was trying to rebuild them anyway.
The need for xerces-c will always be there, as the underlying C++ code
is all theirs (it makes Xerces.pm faster and more memory efficient
than XML::DOM).
However, it is possible that I can bundle the Xerces-C source code and
configure Xerces.pm to create Xerces-C on the fly. That would save a
single installation. Would this be useful?
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
