Re: [xml] xmlParseMemory() and xmlParseDTD()

You are right, Gary. It works perfectly if I use the
static library and I link my application with

thank you again :-).


 --- Gary Pennington <Gary Pennington sun com>
escribió: > MDC A. wrote:


I was using the binary packages downloaded from
page, Gary. But I was linking against the static
library libxml2.a.
I have linked against the dynamic library and the
problem has disappeared.

Ah. I think that if you link with the static library
you must also link 
your application with -lpthread (otherwise the
support required for the 
multi-threaded library (-lxml2) is not present).

Could you try re-using the static library and adding
-lpthread to the 
compile line to see if that works?

I'd like to add some information on this to my
webpage, so I would 
appreciate your letting me know what happens if you
do the above.

Thank you very much to both of you for your time


You're welcome.


--- Gary Pennington <Gary Pennington sun com>
escribió: > Daniel Veillard wrote:

On Wed, Mar 06, 2002 at 01:07:54PM +0100, MDC A.


xmlParserError(0x160840, 0x122cf0, 0x1646c8,


0x0, 0x164afd)

  xmlParserError calls the xmlGenericError

routine which is initialized

to xmlGenericErrorDefaultFunc, with the default

xmlGenericErrorContext which

is initialized to NULL.

 xmlGenericErrorDefaultFunc(0x0, 0x12fcf8, 0x5,
0x44, 0x1646b8)

So that call is correct. 
BUT xmlGenericErrorDefaultFunc() code is:

xmlGenericErrorDefaultFunc(void *ctx

ATTRIBUTE_UNUSED, const char *msg, ...) {

  va_list args;

  if (xmlGenericErrorContext == NULL)
  xmlGenericErrorContext = (void *) stderr;

  va_start(args, msg);
  vfprintf((FILE *)xmlGenericErrorContext, msg,



Unless stderr == NULL in Solaris which would be

really really strange,

vfprintf(0x0, 0xffbef0e4, 0xfeabf9b4, 0x8,



I really don't see how the first argument to

vfprintf being passed can be


which is the problem here?

I really don't know there is something really

really strange here !

How can the problem be solved?

Take a debugger and check by single stepping,

possibly looking at

the assembly generated. I don't understand how

first argument of the

call can be NULL ! Or someone else on Solaris can

reproduce your problem

and check it for you, sorry I can't ...



To cut a long story short, I think this is a
to do with the 
configure script. The linkage to -lpthread wasn't
specified and so if 
your application was single threaded and you built
libxml2 for 
multi-threaded use, failures of this nature would

This was fixed before I reported it, but I think
that it was only fixed 
in 2.4.16.

You can check by seeing if is linked to
-lpthread, e.g.:

bash-2.03$ ldd
/usr/local/libxml/sparc/lib/ =>      
/usr/lib/ =>     /usr/lib/ =>     /usr/lib/ =>       
/usr/lib/ =>   /usr/lib/ =>     /usr/lib/ =>    /usr/lib/ =>    /usr/lib/ =>       

If it isn't linked to -lpthread, then it's broken
for use with single 
threaded apps.

The easy answer is to upgrade your version of
libxml2 to use the latest 
set of binaries that I ship from 
Alternatively, if you use an older version of
Solaris, download the 
source for 2.4.16 and build it.


Gary Pennington
Solaris Kernel Development,
Sun Microsystems
Gary Pennington sun com

Do You Yahoo!?
Yahoo! Messenger
Comunicación instantánea gratis con tu gente.


=== message truncated === 

Do You Yahoo!?
Yahoo! Messenger
Comunicación instantánea gratis con tu gente.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]