Re: More of that "Rune" business

From: O. Hartmann <ohartman_at_mail.zedat.fu-berlin.de>
Date: Sat, 10 Mar 2012 07:11:14 +0100
On 03/10/12 06:53, Conrad J. Sabatier wrote:
> On Fri, 9 Mar 2012 23:38:22 -0600
> "Conrad J. Sabatier" <conrads_at_cox.net> wrote:
> 
>> On Fri, 09 Mar 2012 22:39:23 +0100
>> "O. Hartmann" <ohartman_at_mail.zedat.fu-berlin.de> wrote:
>>
>>> On 03/09/12 21:04, Conrad J. Sabatier wrote:
>>>> I'm getting quite a few of these "Rune"-related errors during port
>>>> builds lately.  I've tried following the advice from the list, but
>>>> no good, they still keep occurring.  I even tried backing off to
>>>> my last known good buildworld/buildkernel (around Feb 23), and it
>>>> still doesn't help.
>>>>
>>>> Also seeing problems relating to the new clang src.conf variables.
>>>> Can't successfully build world and/or kernel to try to correct
>>>> things. "make buildenv" in /usr/src hasn't helped. "make install"
>>>> in /usr/src/share/mk hasn't helped.
>>>>
>>>> Is there some "magic bullet" for this that I've just somehow
>>>> managed to overlook?  I'm totally at a loss here.  Help!
> 
> [failed port build output snipped]
> 
>>> Me, too, here.
>>> Buidling a world with most recent sources and CLANG doesn't work, if
>>> building with legacy/old gcc 4.2.1 the option WITH_LIBCPLUSPLUS=
>>> YES blow off things.
>>>
>>> I had the "_Rune" problem quite often and came around by walking
>>> back to a well known source base and doing a "make installincludes".
>>
>> Yes, it's a very frustrating issue, because it also affects ports
>> builds, not only source.
>>
>> Just on the outside chance it might help, tonight I hosed my entire
>> src tree (which I normally update from a local copy of the CVS
>> repository which I maintain via csup) and did an svn checkout of the
>> src tree. Still no go.  Same exact thing.
>>
>> I'm completely stuck for the time being, until the root cause of this
>> problem is corrected.  I only have about a 50/50 chance at the moment
>> of any port builds succeeding, with numerous updates lying in wait,
>> and zero chance of a successful world/kernel build.  I don't pretend
>> to understand what the real issue is; all I do know is what I've been
>> seeing lately: numerous failed ports builds, most of them referring to
>> an unresolvable _ThreadRuneLocale, and some of them mentioning issues
>> with yylex et al.  I'm stumped, honestly.  Been reading the lists in
>> hopes of learning of a working solution, but nothing I've tried so
>> far has produced any positive results.  I'm seeing the word "Rune" in
>> my sleep lately, I swear!  :-)
>>
>> This is absolutely maddening!
> 
> Well, now, this is interesting.  Just for curiosity's sake, I tried
> building a new kernel with the fresh source tree I just fetched from
> the svn repository, and it succeeded!  Still can't build world, though.
> 
> The question now is: do I dare install this new kernel and give it a
> try?  Cant afford to do any harm to my existing installation.
> 
> My latest working kernel is from Feb 23.  Just how dangerous might it
> be to try the new one?
> 


Kernel building wasn't an issue all the time. Only "world" was broken.
And, funny, world compiles now when issuing "make buildworld". But it
takes ages ... Even on my brand new Core i7-3930X. While compiling
FreeBSD 10.0-CURRENT/amd64 with LLVM EXTRAS and CLANG (I do not know
whether the whole LLVM has it made finally into the build process)
within 30 minutes on the new lab's box, with "make buildworld", no -jX
(usually 12 for the 6-core/12 thread box) is now heating up only one
thread/core for about two hours.

Well, I decided to rebuild all ports! This is easy to say and do if the
hardware is quite potent. At my office at home, I do not dare doing this
since the CPU is an older Intel E8500 with only two cores. It takes a
day and more to accomplish building the ports I use to get rid of the
"Rune"-issue. Rune seems to have a new sematics: ruin my day ...


Oliver


Received on Sat Mar 10 2012 - 05:11:22 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:24 UTC