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
___
freebsd-hackers@free
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 h
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 wo
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 s
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
> implementa
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 F
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
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 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
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 ge
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)
li
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
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
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 load
14 matches
Mail list logo
