On 11/21/11 23:04, Antoine Jacoutot wrote:
On Mon, Nov 21, 2011 at 06:11:48PM -0800, Justin Lindberg wrote:
The problem is that the shared object library
/usr/local/lib/libgthread-2.0.so.2800.0
or
/usr/local/lib/libgthread-2.0.so.2992.0
as it is by now in -CURRENT
tries to execute function calls that are implemented in
/usr/lib/libpthread.so.13.1
These calls will continue to segfault unless libgthread-2.0 is linked
with "-lpthread", or equivalently, "--library=pthread"
Again, *NO*.
Link your executable with -pthread and stop trying to add -lpthread to all
libraries, that is not how it works.
I am not adding -lpthread to all my libraries, and I am not
trying to rebuild anything right now. I am trying to figure out
why the binaries released in 5.0 as well as recent snapshots,
namely
/usr/local/lib/libgthread-2.0.so.2800.0
and
/usr/local/lib/libgthread-2.0.so.2992.0
are segfaulting when they try to call the pthread functions,
and why manually relinking one of them with -lpthread,
without recompiling it, suddenly makes it work.
If /usr/lib/libpthread.so.13.1 doesn't show up when you run ldd,
then libgthread-2.0 was not linked properly.
Wrong, libpthread is never recorded in so libs when using -pthread and linking
with -lpthread is not the proper way on OpenBSD for a whole bunch of reasons.
For the last time, you have to link your executable with -pthread.
In that case, either -pthread is trying to link that particular
library statically rather than dynamically, or it's trying to
do something new and wonderful that is broken and not yet very
well documented.
My particular machine is a two-processor i7 with hyperthreading
that runs four pipelines of instructions.
