Do you know if this is documented in Release Notes or Known Issues or
somewhere?
thanks,
B
Daniel Eischen wrote:
On Thu, 11 Sep 2008, Barry Andrews wrote:
Hi All,
I have a multi-threaded library that is linked against libpthread.
When I
load this lib into a tclsh process on FreeBSD, I
On Fri, Sep 12, 2008 at 07:41:14AM -0400, Barry Andrews wrote:
Do you know if this is documented in Release Notes or Known Issues or
somewhere?
Why would it be an issue? gcc -pthread and libpthread linking is
documented pretty much everywhere on the web. There isn't anything
broken about
I don't understand. If it was not broken, then why did it change in later
FreeBSD versions?
On Fri, Sep 12, 2008 at 9:10 AM, Jeremy Chadwick [EMAIL PROTECTED] wrote:
On Fri, Sep 12, 2008 at 07:41:14AM -0400, Barry Andrews wrote:
Do you know if this is documented in Release Notes or Known
On Fri, Sep 12, 2008 at 09:26:37AM -0400, Barry Andrews wrote:
I don't understand. If it was not broken, then why did it change in later
FreeBSD versions?
I should be more explicit: the threading library and implementations
have changed over time. There was libc_r, then there was libthr, then
Thanks for the links! But I'm not sure what any of this has to do with
this particular issue. I have an exe that does not use threads that
loads a lib that is linked with libpthread. Why does different threading
implementations affect what I am seeing here? Is there no way for this
to work in
On Fri, Sep 12, 2008 at 11:00:18AM -0400, Barry Andrews wrote:
Thanks for the links! But I'm not sure what any of this has to do with
this particular issue. I have an exe that does not use threads that
loads a lib that is linked with libpthread. Why does different threading
Yes, the exe is tclsh. I understand that linking tclsh with libpthread is
what would work. However this is very impractical. A user of my library
shouldn't have to rebuild their tclsh to match my library specs. Another
option would be to ship tclsh with my lib, but that also is a little weird.
It
On Fri, Sep 12, 2008 at 11:55:01AM -0400, Barry Andrews wrote:
Yes, the exe is tclsh. I understand that linking tclsh with libpthread is
what would work. However this is very impractical. A user of my library
shouldn't have to rebuild their tclsh to match my library specs. Another
option would
On Fri, Sep 12, 2008 at 09:09:00AM -0700, Jeremy Chadwick wrote:
On Fri, Sep 12, 2008 at 11:55:01AM -0400, Barry Andrews wrote:
Yes, the exe is tclsh. I understand that linking tclsh with libpthread is
what would work. However this is very impractical. A user of my library
shouldn't have to
On Fri, 12 Sep 2008, Barry Andrews wrote:
Do you know if this is documented in Release Notes or Known Issues or
somewhere?
No, but it's certainly in the -threads or -ports mailing
list archives from a few years ago ;-)
--
DE
___
Hi All,
I have a multi-threaded library that is linked against libpthread. When I
load this lib into a tclsh process on FreeBSD, I get this error, Recurse on
private mutex. and crash. I understand that I can have this issue when the
executable is not linked against libpthread but one of the
On Thu, Sep 11, 2008 at 03:06:35PM -0400, Barry Andrews wrote:
Hi All,
I have a multi-threaded library that is linked against libpthread. When I
load this lib into a tclsh process on FreeBSD, I get this error, Recurse on
private mutex. and crash. I understand that I can have this issue when
On Thu, 11 Sep 2008, Barry Andrews wrote:
Hi All,
I have a multi-threaded library that is linked against libpthread. When I
load this lib into a tclsh process on FreeBSD, I get this error, Recurse on
private mutex. and crash. I understand that I can have this issue when the
executable is not
FreeBSD version 5.5
output of ldd for my lib is:
libbase.so:
libutils.so = ./libutils.so (0x287e)
libACE.so.5.5.6 = ./libACE.so.5.5.6 (0x2882d000)
libxerces-c.so.27 = ./libxerces-c.so.27 (0x28976000)
libsqlite3.so.8 = ./libsqlite3.so.8 (0x28d23000)
14 matches
Mail list logo
