Segfault from libthr.so.

[Konstantin Belousov]

On Sat, Sep 27, 2014 at 08:55:56AM +0200, Guillaume Friloux wrote:
> On 14/09/26, Konstantin Belousov wrote:
> > So, what is the problem, from your PoV ?
> > Linking libssp after libthr causes libssp constructors run before
> > libthr initialization, which causes the behaviour you see. The libssp
> > uses something which is interposed by libthr, but still not ready at
> > the libssp init time. Your example of linking with different order
> > demostrates you the right way to treat libthr.
> > 
> > So again, what is the problem ?
> 
> Sorry to disturb you again, but i would have more access to your knowledge.
> I understand what you say, but in my case, it disturbs me a little.
> 
> Lets take this project as example : https://github.com/gfriloux/botman
> 
> As you can see, it uses an m4 macro that will force link to ssp (configure.ac:38).
> Later on, deps will be declared (configure.ac:87). One of those deps is eina.
> Eina will declare -lpthread from its .pc file.
> 
> And this is how i get to the state of having -lssp -lpthread.
So this is right order.

> In my app, i dont directly start any thread, lower libs do. So it doesnt seem
> logical to add -lpthread before declaring the deps.
> So should i just remove this m4 macro that seems to be use on quite some projects,
> so it works on BSD ?
> 
> What is the best way to do it, in your opinion ?

Just put -lpthread last in the command line (automake variable) for linker.
This should work portable on all systems I know.