Segfault from libthr.so.

Guillaume Friloux guillaume at friloux.me
Sat Sep 27 06:52:44 UTC 2014


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.
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 ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20140927/7f10edbc/attachment.sig>


More information about the freebsd-threads mailing list