Re: [xml] Segfault because of unresolved pthread functions

[Neil Jacobson <neilgj yahoo com>]

I managed to come up with a work-around for this issue that was necessary because I am stuck using this particular (older) version of libxml2 (v2.6.31).  I changed my link switches for including libpthread from

 

-lpthread

 

To:

 

-Wl,--whole-archive -lpthread -Wl,--no-whole-archive

 

The obvious downside is that the entire archive is included in your static image resulting in some executable bloat but it does work.

Now everybody knows.

---

From: Neil Jacobson <neilgj yahoo com>
To: xml gnome org
Sent: Wed, November 4, 2009 6:45:08 PM
Subject: Segfault because of unresolved pthread functions

I found this posting on the archive.  There was no resolution to it but now I have the exact same issue.  It is well described here so I will reproduce that description (along with the response) [I also note that I was using v2.6.20 without issue but ws forced to upgrade to v2.6.31 and that's when this appeared]  Can anyone help?

 

 

On Mon, Jul 28, 2008 at 10:05:28AM +0100, Rachael Churchill wrote:

> My program built with libxml2 is segfaulting at line 434 of threads.c:

> 

> pthread_mutex_lock(&global_init_lock);

> 

> It seems that the function pthread_mutex_lock has been given address 0 

> by the linker, so when this function gets called it calls address 0 and 

> crashes.

> 

> I discovered
 that in threads.c, various pthread functions are redeclared 

> with __attribute((weak)), which suppresses ld's warning that the symbol 

> is unresolved. So the executable gets built anyway, with the function 

> address set to 0, and crashes.

>  

> If I build my program without -lpthread, I get unresolved symbol errors 

> for pthread_cond_wait and pthread_cond_destroy.

> 

> I tried
 turning off --with-threads in the libxml2 build configuration, 

> but I still get unresolved symbol errors for the above pthread 

> functions. It looks like the #ifdefs which preprocess out those 

> functions in threads.c are conditional on the presence of pthread.h on 

> the system, rather than on the config option --without-threads.

> 

> Do you have any suggestions for making this work, i.e. build and not 

> crash? (Preferably --with-threads, but failing that --without-threads 

> will do.)

That code has been around for years without problems, and embedded in

many OSes, there is a possibility of remaining bugs but i have built

libxml2 without thread dependancy for years without problems on linux,

and the library is being used on the desktop, then linked with threads

without problems for that loong too. So both have been exercised quite

a lot, I'm really surprized you managed to have a problem with this now.

  What version, what OS, what
 toolchain are you using ? 

Daniel