On Tue, Nov 22, 2011 at 08:12:16AM -0800, Justin Lindberg wrote: > 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.
I resign. You are obviously not reading what I am writting on purpose. -- Antoine
