On Mon, 3 Jan 2005 19:26:54 +0100, Michael Nottebrock
<michaelnottebrock at gmx.net> wrote:
> On Monday, 3. January 2005 19:13, Michael Nottebrock wrote:
>> On Monday, 3. January 2005 18:56, Ulrich Spoerlein wrote:
>> > On Mon, 03.01.2005 at 16:36:36 +0100, Michael Nottebrock wrote:
>> > > > And running a ruby program requiring wxruby I get this error:
>> > > > /libexec/ld-elf.so.1: /usr/local/lib/libgthread-2.0.so.400:
>> Undefined
>> > > > symbol "pthread_getschedparam"
>> > >
>> > > This is expected: When shared libraries are linked with -pthread,
>> the
>> > > linker only resolves the necessary symbols but does not emit a
>> > > DT_NEEDED symbol for the resulting shared library, it only does for
>> > > programs.
>> > >
>> > > Bottom line: Pthread symbols must always be resolved through the
>> actual
>> > > program. Make sure the program that uses wxruby is linked with
>> -pthread
>> > > as well.
>> >
>> > wxruby.so get's loaded by ruby on demand. That is when using 'require
>> > wxruby'. I'm pretty sure we don't want to link pthread into ruby
>> itself.
>>>> There is no other choice. It's the same issue with perl and python (the
>> latter already has thread-support on by default for that reason).
>> Looking at the ruby ports, this should actually be pretty easy to
> accomplish - just depend on ruby18_r.
No, it will not working on FreeBSD 5.x and 6.x, because _r is returning as
null. The _r is only for FreeBSD 4.x. I had to add '-pthread' in ruby's
LDFLAGS and reinstall it to solve this problem. I have the same problem
with ruby-gtk2/ruby-gnome2. I have reported to knu few times and you
should see my emails in cvs-ports.
I also suggested to knu try to get rid of _r, because it is creating some
weird problem. Enable _r options by default, but without have '_r'.
http://lists.freebsd.org/pipermail/cvs-ports/2004-December/053217.html
BTW: CC'ing to knu.
Cheers,
Mezz
--
mezz7 at cox.net - mezz at FreeBSD.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gnome at FreeBSD.org