Date: Thu, 17 Mar 2022 17:59:33 +0000 From: bugzilla-noreply@freebsd.org To: ruby@FreeBSD.org Subject: [Bug 260831] lang/ruby26, lang/ruby27, lang/ruby3[01]: Add DTRACE option Message-ID: <bug-260831-21402-DzHc0bsg2z@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-260831-21402@https.bugs.freebsd.org/bugzilla/> References: <bug-260831-21402@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260831 --- Comment #2 from Sean Champ <lab+bsd@thinkum.space> --- (In reply to Kubilay Kocak from comment #1) I'll take a look at those patches for dtrace options in ruby26 and ruby27. = thx for the reference Noticing the cmd args added for the dtrace call in configure - in each of t= hose port patches by Evgeniy Khramtsov, for ruby2[67] - perhaps it might help to clarify why some port builds have been failing locally when the upstream src tries to use dtrace in the build -- e.g lang/ghc which failed here on a Fre= eBSD 12.3 build, in something to do with dtrace. I've disabled dtrace in that bu= ild in the local ports tree, and the build succeeded. If those additional args were used with the dtrace cmd, maybe those port bu= ilds would not fail. iirc it was a similar situation that had initially inspired this patch. Perhaps the additional args can be added to the 'DTRACE' cmd variable itsel= f, via the configure args or configure env.=20 If it may be feasible to include the additional args in the cmd variable, t= hen perhaps it could also be needed during build. Of course, it might also serv= e to alleviate the concern of maintaining an additional patch. I'll try to test the approach adding those args to the 'DTRACE' cmd, maybe = it could be needed on some FreeBSD before 12.3 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-260831-21402-DzHc0bsg2z>