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 Christopher Gutteridge <cj...@ecs.soton.ac.uk> on 2001/07/02 15:05:21 UTC
Problem running xerces-p : pthreads?
I'm running a non-pthreads version of perl, and so I'm getting
an error when xerces attempts to call the mutex_lock.
Would it be possible to make the perl module Xerces.so statically
linked against pthreads if the perl install isn't? Would this work?
Or could it check at runtime and dynamically load pthreads?
Or as a rather ick last resource, if you're compiling it for
a non threaded perl could you just add in a mutex_lock dummy functions
(and for any other that xerces-c uses). I believe (hand not on heart)
that xerces is only using these to be thread safe, and an unthreaded
perl will be pretty damn thread safe.
It took me a while to figure out what's going on, so it's possible that
this is causing trouble for other people too.
(or maybe I've just missed a vital config option <grin>)
--
Christopher Gutteridge -- cjg@ecs.soton.ac.uk -- +44 (0)23 8059 4833
Now Playing: "Private goes public" from 99.9F0 - Suzanne Vega
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org
Re: Problem running xerces-p : pthreads?
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
Don't know what to say Christopher. It seems like we're using the same
system, but it works for me. Notice that it is definately not a
threaded perl (usethreads=undef).
I'm assuming that you built Xerces-C from source? This was all I needed
to do to get it to work.
jas.
Here's my config:
uname -a
Linux genomics.biochem.uci.edu 2.2.18 #7 SMP Thu Mar 22 14:18:12 PST 2001 i686 unknown
gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81)
perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
Platform:
osname=linux, osvers=2.2.18, archname=i686-linux-ld
uname='linux genomics.biochem.uci.edu 2.2.18 #7 smp thu mar 22 14:18:12 pst 2001 i686 unknown '
config_args=''
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=define
Compiler:
cc='gcc', ccflags ='-fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-fno-strict-aliasing'
ccversion='', gccversion='2.96 20000731 (Red Hat Linux 7.1 2.96-81)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='long double', nvsize=12, Off_t='off_t', lseeksize=8
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lndbm -lgdbm -ldl -lm -lc -lposix -lcrypt -lutil
perllibs=-lnsl -ldl -lm -lc -lposix -lcrypt -lutil
libc=/lib/libc-2.2.2.so, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: USE_LONG_DOUBLE USE_LARGE_FILES
Built under linux
Compiled at May 9 2001 12:24:02
@INC:
/usr/local/lib/perl5/5.6.1/i686-linux-ld
/usr/local/lib/perl5/5.6.1
/usr/local/lib/perl5/site_perl/5.6.1/i686-linux-ld
/usr/local/lib/perl5/site_perl/5.6.1
/usr/local/lib/perl5/site_perl
"Christopher Gutteridge" <cj...@ecs.soton.ac.uk> writes:
> > * perl -V
> Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
> Platform:
> osname=linux, osvers=2.4.0-0.99.11, archname=i686-linux
> uname='linux lemur 2.4.0-0.99.11 #1 wed jan 24 16:07:17 est 2001 i686 unknown '
> config_args=''
> hint=recommended, useposix=true, d_sigaction=define
> usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
> useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
> use64bitint=undef use64bitall=undef uselongdouble=undef
> Compiler:
> cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
> optimize='-O2',
> cppflags='-fno-strict-aliasing -I/usr/local/include'
> ccversion='', gccversion='2.96 20000731 (Red Hat Linux 7.0)', gccosandvers=''
> intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
> d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
> ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
> alignbytes=4, usemymalloc=n, prototype=define
> Linker and Libraries:
> ld='cc', ldflags =' -L/usr/local/lib'
> libpth=/usr/local/lib /lib /usr/lib
> libs=-lnsl -lndbm -lgdbm -ldl -lm -lc -lcrypt -lutil
> perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil
> libc=/lib/libc-2.2.1.so, so=so, useshrplib=false, libperl=libperl.a
> Dynamic Linking:
> dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
> cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
>
>
> > * gcc -v
> Characteristics of this binary (from libperl):
> Compile-time options: USE_LARGE_FILES
> Built under linux
> Compiled at May 25 2001 11:19:00
> @INC:
> /usr/local/lib/perl5/5.6.1/i686-linux
> /usr/local/lib/perl5/5.6.1
> /usr/local/lib/perl5/site_perl/5.6.1/i686-linux
> /usr/local/lib/perl5/site_perl/5.6.1
> /usr/local/lib/perl5/site_perl
> .
>
>
> > * uname -a
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
> gcc version 2.96 20000731 (Red Hat Linux 7.0)
>
> > If linux what distribution are you running?
> Redhat 7.1 (update from 6.2, not installed as 7.1)
>
> Linux lemur 2.4.0-0.99.11 #1 Wed Jan 24 16:07:17 EST 2001 i686 unknown
>
> On Mon, Jul 02, 2001 at 10:08:58AM -0600, Jason E. Stewart wrote:
> > "Christopher Gutteridge" <cj...@ecs.soton.ac.uk> writes:
> >
> > > I'm running a non-pthreads version of perl, and so I'm getting an
> > > error when xerces attempts to call the mutex_lock.
> >
> > Hi Christopher,
> >
> > This is the second time I've heard this, so I'm becoming a
> > believer...
> >
> > I am *not* running a threaded perl and Xerces works fine for me. The
> > Makefile forces -lpthread to be included on the link line, so this
> > should work. I don't know what is causing it to fail.
> >
> > Could you do a
> >
> >
> > > Would it be possible to make the perl module Xerces.so statically
> > > linked against pthreads if the perl install isn't? Would this work?
> > > Or could it check at runtime and dynamically load pthreads?
> >
> > No matter how much I delve into dynamic loading, I just can't seem to
> > grasp all the issues involved. Meaning in this case, I can't really
> > answer your question with 100% certainty.
> >
> > If -lpthreads was used during the link phase, then the answer really
> > ought to be: yes the linker will go out and load pthreads for you...
> >
> > And yes, you should be able to force inclusion of the pthread methods into
> > Xerces.so. The compiler/linker option is of course different for each
> > compiler/linker combo and I'm not sure it's one of the ones that perl
> > tracks. For GNU ld it is --whole-archive:
> >
> > --whole-archive
> > For each archive mentioned on the command line af
> > ter the --whole-archive option, include every ob
> > ject file in the archive in the link, rather than
> > searching the archive for the required object
> > files. This is normally used to turn an archive
> > file into a shared library, forcing every object to
> > be included in the resulting shared library.
> >
> > Try that manually in your link and see what happens.
> >
> > > Or as a rather ick last resource, if you're compiling it for a non
> > > threaded perl could you just add in a mutex_lock dummy functions
> > > (and for any other that xerces-c uses). I believe (hand not on
> > > heart) that xerces is only using these to be thread safe, and an
> > > unthreaded perl will be pretty damn thread safe.
> >
> > I'd like to figure out why it's not working the way it should.
> >
> > > It took me a while to figure out what's going on, so it's possible
> > > that this is causing trouble for other people too.
> >
> > Your second in line on this one, which probably means there are others
> > that tried it and failed and didn't bother to post to the list.
> >
> > > (or maybe I've just missed a vital config option <grin>)
> >
> > Oh, yeah --DWIM ...
> >
> > (Do What I Mean)
> >
> > jas.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-p-dev-help@xml.apache.org
>
> --
> Christopher Gutteridge -- cjg@ecs.soton.ac.uk -- +44 (0)23 8059 4833
> It is not how you look at life, as much as how many ways.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-p-dev-help@xml.apache.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: Problem running xerces-p : pthreads?
Posted by Christopher Gutteridge <cj...@ecs.soton.ac.uk>.
> * perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
Platform:
osname=linux, osvers=2.4.0-0.99.11, archname=i686-linux
uname='linux lemur 2.4.0-0.99.11 #1 wed jan 24 16:07:17 est 2001 i686 unknown '
config_args=''
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='2.96 20000731 (Red Hat Linux 7.0)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lndbm -lgdbm -ldl -lm -lc -lcrypt -lutil
perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil
libc=/lib/libc-2.2.1.so, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
> * gcc -v
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under linux
Compiled at May 25 2001 11:19:00
@INC:
/usr/local/lib/perl5/5.6.1/i686-linux
/usr/local/lib/perl5/5.6.1
/usr/local/lib/perl5/site_perl/5.6.1/i686-linux
/usr/local/lib/perl5/site_perl/5.6.1
/usr/local/lib/perl5/site_perl
.
> * uname -a
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.0)
> If linux what distribution are you running?
Redhat 7.1 (update from 6.2, not installed as 7.1)
Linux lemur 2.4.0-0.99.11 #1 Wed Jan 24 16:07:17 EST 2001 i686 unknown
On Mon, Jul 02, 2001 at 10:08:58AM -0600, Jason E. Stewart wrote:
> "Christopher Gutteridge" <cj...@ecs.soton.ac.uk> writes:
>
> > I'm running a non-pthreads version of perl, and so I'm getting an
> > error when xerces attempts to call the mutex_lock.
>
> Hi Christopher,
>
> This is the second time I've heard this, so I'm becoming a
> believer...
>
> I am *not* running a threaded perl and Xerces works fine for me. The
> Makefile forces -lpthread to be included on the link line, so this
> should work. I don't know what is causing it to fail.
>
> Could you do a
>
>
> > Would it be possible to make the perl module Xerces.so statically
> > linked against pthreads if the perl install isn't? Would this work?
> > Or could it check at runtime and dynamically load pthreads?
>
> No matter how much I delve into dynamic loading, I just can't seem to
> grasp all the issues involved. Meaning in this case, I can't really
> answer your question with 100% certainty.
>
> If -lpthreads was used during the link phase, then the answer really
> ought to be: yes the linker will go out and load pthreads for you...
>
> And yes, you should be able to force inclusion of the pthread methods into
> Xerces.so. The compiler/linker option is of course different for each
> compiler/linker combo and I'm not sure it's one of the ones that perl
> tracks. For GNU ld it is --whole-archive:
>
> --whole-archive
> For each archive mentioned on the command line af
> ter the --whole-archive option, include every ob
> ject file in the archive in the link, rather than
> searching the archive for the required object
> files. This is normally used to turn an archive
> file into a shared library, forcing every object to
> be included in the resulting shared library.
>
> Try that manually in your link and see what happens.
>
> > Or as a rather ick last resource, if you're compiling it for a non
> > threaded perl could you just add in a mutex_lock dummy functions
> > (and for any other that xerces-c uses). I believe (hand not on
> > heart) that xerces is only using these to be thread safe, and an
> > unthreaded perl will be pretty damn thread safe.
>
> I'd like to figure out why it's not working the way it should.
>
> > It took me a while to figure out what's going on, so it's possible
> > that this is causing trouble for other people too.
>
> Your second in line on this one, which probably means there are others
> that tried it and failed and didn't bother to post to the list.
>
> > (or maybe I've just missed a vital config option <grin>)
>
> Oh, yeah --DWIM ...
>
> (Do What I Mean)
>
> jas.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-p-dev-help@xml.apache.org
--
Christopher Gutteridge -- cjg@ecs.soton.ac.uk -- +44 (0)23 8059 4833
It is not how you look at life, as much as how many ways.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org
Re: Problem running xerces-p : pthreads?
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Christopher Gutteridge" <cj...@ecs.soton.ac.uk> writes:
> I'm running a non-pthreads version of perl, and so I'm getting an
> error when xerces attempts to call the mutex_lock.
Hi Christopher,
This is the second time I've heard this, so I'm becoming a
believer...
I am *not* running a threaded perl and Xerces works fine for me. The
Makefile forces -lpthread to be included on the link line, so this
should work. I don't know what is causing it to fail.
Could you do a
* perl -V
* gcc -v
* uname -a
If linux what distribution are you running?
> Would it be possible to make the perl module Xerces.so statically
> linked against pthreads if the perl install isn't? Would this work?
> Or could it check at runtime and dynamically load pthreads?
No matter how much I delve into dynamic loading, I just can't seem to
grasp all the issues involved. Meaning in this case, I can't really
answer your question with 100% certainty.
If -lpthreads was used during the link phase, then the answer really
ought to be: yes the linker will go out and load pthreads for you...
And yes, you should be able to force inclusion of the pthread methods into
Xerces.so. The compiler/linker option is of course different for each
compiler/linker combo and I'm not sure it's one of the ones that perl
tracks. For GNU ld it is --whole-archive:
--whole-archive
For each archive mentioned on the command line af
ter the --whole-archive option, include every ob
ject file in the archive in the link, rather than
searching the archive for the required object
files. This is normally used to turn an archive
file into a shared library, forcing every object to
be included in the resulting shared library.
Try that manually in your link and see what happens.
> Or as a rather ick last resource, if you're compiling it for a non
> threaded perl could you just add in a mutex_lock dummy functions
> (and for any other that xerces-c uses). I believe (hand not on
> heart) that xerces is only using these to be thread safe, and an
> unthreaded perl will be pretty damn thread safe.
I'd like to figure out why it's not working the way it should.
> It took me a while to figure out what's going on, so it's possible
> that this is causing trouble for other people too.
Your second in line on this one, which probably means there are others
that tried it and failed and didn't bother to post to the list.
> (or maybe I've just missed a vital config option <grin>)
Oh, yeah --DWIM ...
(Do What I Mean)
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org