Re: [PATCH] portmaster with SU_CMD

[lemon]

I doubt there's any need for more cautionary tales about the wisdom of
building stuff as root(*), but I can't resist throwing this in as an
example of an astounding build-time glitch with bad consequences if done
as root:

  

Sure: FreeBSD doesn't invoke 'make test', this is a silly error and I'd
expect such things to be noticed by the port maintainer, but hey :-)

regards, l.

(*) FWIW: I agree with Greg, it's a matter of taste or principle. I
bounce between either camp depending if it's in the lab or in production
and some non-linear function of my current laziness.


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ruby18, -pthreads, deep recursion

[lemon]

Marcin Wisnicki wrote:
> On Thu, 01 Nov 2007 22:02:38 -0500, Josh Paetzel wrote:
>> On Thursday 01 November 2007 04:04:35 pm lemon wrote:
>>> [0] http://lists.freebsd.org/pipermail/freebsd-ports/2005-
> January/019352.html
>>> http://lists.freebsd.org/pipermail/freebsd-ports/2006-
> March/030691.html
>> If it's any consolation, I've emailed the ruby maintainer a few times
>> about why disabling threads in the port's menu doesn't *really* disable
>> threads and have never gotten a reply.
> 
> As explained in abovementioned links, some of ruby extensions need 
> pthreads but since shared modules on freebsd are never linked with 
> threading libraries (i think it might no longer be true in releng7/
> current), you have no other choice than to link ruby interpreter binary 
> with libpthread.

Thanks, that's much clearer for me now. I guess I'm lucky - I've yet to
hit anything involved in our RoR app that breaks a pthread-less ruby18
on 6.2-R. Even better if the problem's gone away on 7.x.

Cheers for all the responses.

Regards, l.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

ruby18, -pthreads, deep recursion

[lemon]

Hi,

I've been struggling with FreeBSD's ruby18 port and threads. I realise
there's previous discussion[0] about this and I feel I'm blundering
somewhat, but here goes.

On both 7.x and 6.x boxes I've built ruby18 with the pthreads knob
deliberately turned off (the default). The resultant ruby has problems
with deep recursion, shown by this script[1] but less pathologically in
production in a busy RoR site too.

  $ ruby -e 'def d(x); p x; d x+1; end; d 0'

This bombs with SIGILL[2].

I note that, as per the conversations linked above, this build uses the
GCC option -pthread and links against libthr[3].

If I build the port without -pthread (and related config.h #define),
install the library alongside the from-port one, and employ the
resultant binary with some libmap.conf guidance I get a ruby which
behaves far nicer[4]. I can recurse way deeper and receive a graceful
SystemStackError exception when things hit the wall[5].

What's the score here? Clearly there's motive for building like it does,
but the hacked ruby works better for me in everyday life. Any ideas?

I hope this is on-topic for freebsd-ports. I mailed the maintainer first
but got no response.

Regards, l.

[0]
http://lists.freebsd.org/pipermail/freebsd-ports/2005-January/019352.html
http://lists.freebsd.org/pipermail/freebsd-ports/2006-March/030691.html

[1] Google found me this, I forget where!

[2] $ ruby -e 'def d(x); p x; d x+1; end; d 0' | head
0
1
2
...
2138
2139
Illegal instruction: 4

[3] $ ldd `which ruby`
/usr/local/bin/ruby:
libruby18.so.18 => /usr/local/lib/libruby18.so.18 (0x2807d000)
libcrypt.so.4 => /lib/libcrypt.so.4 (0x28154000)
libm.so.5 => /lib/libm.so.5 (0x2816d000)
libthr.so.3 => /lib/libthr.so.3 (0x28182000)
libc.so.7 => /lib/libc.so.7 (0x28195000)

[4] $ ldd ~/tmp/ruby18
/home/lemon/tmp/ruby18:
libruby18.so.18 => /usr/local/lib/libruby18-nothread.so.18
(0x2807d000)
libcrypt.so.4 => /lib/libcrypt.so.4 (0x28154000)
libm.so.5 => /lib/libm.so.5 (0x2816d000)
libc.so.7 => /lib/libc.so.7 (0x28182000)

[5] $ ~/tmp/ruby18 -e 'def d(x); p x; d x+1; end; d 0'
0
1
2
...
67705
67706
-e:1:in `inspect': stack level too deep (SystemStackError)
from -e:1:in `p'
from -e:1:in `d'
from -e:1:in `d'
from -e:1
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"