GNOME Bugzilla – Bug 112144
Threads support breaks certain applications
Last modified: 2009-08-15 18:40:50 UTC
On FreeBSD 4.x, shared libraries cannot be linked with -pthread. That is, there is no resulting libc_r link in the final .so. This causes a problem when building subsequent libraries or applications with libxml2 support. For example, one cannot build mod_php on FreeBSD 4.x with DOMXML without disabling threads in libxml2. Sure, I can tune the port to disable threads by default (which I probably will have to do), but I don't want to run the risk of breaking future applications that depend on libxml2 thread support. If I may, I'd like to propose a second library (e.g. libxml2_r) that would contain the threads API. Applications that need libxml2 threads could link against this as well as -pthread. This is similar to how openldap does things. Note, I set the version to 2.5.2 because there was no 2.5.7. This problem started occurring after threads support was enabled by default in 2.5.7.
> On FreeBSD 4.x, shared libraries cannot be linked with -pthread. Sounds like a problem of FreeBSD not libxml2 > For example, one cannot build mod_php on FreeBSD 4.x with DOMXML > without disabling threads in libxml2. Why ? xml2-config --libs should report -L/usr/lib -lxml2 -lz -lpthread -lm or something similar. If the libraries cannot be linked dynamically that should alt least be possible statically. And for very specific problems like this then disable threads. I don't want to maintain 2 libraries just because one architecture has a problem. Either the people packaging on that architecture solve the problem (either in their loader or by using specific configure flag on that platform), or we change the configure default for that platform, but I don't have the time to maintain 2 libraries. Daniel
Just rereading your initial post again, I don't think a thread specific part can be separated. Libxml2 uses libxml2, and the threads support when running threaded is needed within the library. So independantly of the workload associated with your proposal, this really could not work either due to purely technical dependancies. Maybe the simplest is at the OS packaging level to build 2 shared libraries, one with thread and one without (I would take - as indicated - specific configure patches) but it sounds to me that something need to be fixed/improved instead at the framework level. Daniel
I will have to do this if apps come out that require the threads API. FreeBSD 4.x cannot have libc_r linked into shared libs due to symbol conflicts in libc. This is fixed in 5.x (where -lc_r can be specified directly instead of -pthread). It is highly unlikely that this will change. Right now, the PHP breakage outways the need for mandatory threads since there are no apps using that API. I was thinking I would create a slave port that depends on libxml2 (sans threads) that builds the threads API into a shared library, and links to libxml2.so. It sounds like that may not be possible, so I may have to create a distinct port that installs a libxml2_r.so with the full API. In either event, I will need another configure script (e.g. xml2_r-config) to drive ports that may need this.