Re: More of that "Rune" business

2012-03-10 Thread Conrad J. Sabatier 
On Sat, 10 Mar 2012 12:04:02 -0600
"Conrad J. Sabatier"  wrote:

> On Fri, 09 Mar 2012 22:22:18 -0800
> matt  wrote:
> 
> > On 03/09/12 22:19, Conrad J. Sabatier wrote:
> > > On Fri, 9 Mar 2012 23:53:50 -0600
> > >
> > > That sound you're hearing right now is me gnashing my teeth.  :-)
> > >
> > blow away /usr/obj, /usr/src, csup to current, then do "cd
> > /usr/src/include && make install"?
> > That may fix your system headers enough to allow a buildworld...
> > 
> > The rune curse was lifted long ago...sounds like there are some
> > remnants still on your system.
> 
> Is that a library issue, perhaps?  I've already tried what you just
> suggested, and the problem persists.  I'm wondering if maybe I need to
> try to rebuild libc or some other librar(y|ies) first.

Well, I managed to build and install libc, and reinstalled the includes
as well, and things are looking much better now.  Building the rest of
the libraries at the moment.  After that, I'll try a full buildworld.

Looks like I'm back in business, though.  Hallelujah!  :-)

-- 
Conrad J. Sabatier
conr...@cox.net
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: More of that "Rune" business

2012-03-10 Thread Conrad J. Sabatier 
On Sat, 10 Mar 2012 07:11:14 +0100
"O. Hartmann"  wrote:

> On 03/10/12 06:53, Conrad J. Sabatier wrote:
> > On Fri, 9 Mar 2012 23:38:22 -0600
> > "Conrad J. Sabatier"  wrote:
> > 
> >> On Fri, 09 Mar 2012 22:39:23 +0100
> >> "O. Hartmann"  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.

That's kind of weird, huh?

> 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 ...

"Rune" my day.  :-)  I like that!

I'm beginning to suspect it's a library issue in my case.  Gonna try
building/installing libc and friends and see if that does any good
(that is, if the build even succeeds!).

-- 
Conrad J. Sabatier
conr...@cox.net
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: More of that "Rune" business

2012-03-10 Thread Conrad J. Sabatier 
On Fri, 09 Mar 2012 22:22:18 -0800
matt  wrote:

> On 03/09/12 22:19, Conrad J. Sabatier wrote:
> > On Fri, 9 Mar 2012 23:53:50 -0600
> >
> > That sound you're hearing right now is me gnashing my teeth.  :-)
> >
> blow away /usr/obj, /usr/src, csup to current, then do "cd
> /usr/src/include && make install"?
> That may fix your system headers enough to allow a buildworld...
> 
> The rune curse was lifted long ago...sounds like there are some
> remnants still on your system.

Is that a library issue, perhaps?  I've already tried what you just
suggested, and the problem persists.  I'm wondering if maybe I need to
try to rebuild libc or some other librar(y|ies) first.

-- 
Conrad J. Sabatier
conr...@cox.net
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 10.0-CURRENT #0 r232730: buildworld broken with CLANG?

2012-03-10 Thread Dimitry Andric 
On 2012-03-10 17:11, Ivan Klymenko wrote:
> В Sat, 10 Mar 2012 14:26:42 +0100
> Dimitry Andric  пишет:
...
>> Unfortunately, you did a -j build, which makes the actual errors
>> difficult to find, and if you show only the last few lines, as you
>> have done here, those errors are not visible at all.
>>
>> Try doing a single-threaded build instead.  Save the entire log, using
>> script(1) for example, compress it and upload it somewhere.
> 
> Full buildworld log:
> http://pazzle.otdux.com.ua/logs/buildworld.log

This is, again, a multithreaded build log, so it is very difficult to
see where the actual error is.  Moreover, it seems to be using ccache,
which almost certainly result in problems, and non-standard CFLAGS. 

Try disabling all of these, deleting /usr/obj, and rebuild.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 10.0-CURRENT #0 r232730: buildworld broken with CLANG?

2012-03-10 Thread Ivan Klymenko 
В Sat, 10 Mar 2012 14:26:42 +0100
Dimitry Andric  пишет:

> On 2012-03-10 00:58, O. Hartmann wrote:
> > I might have missed the point but since a week now I can't build
> > FreeBSD 10.0 CURRENT/amd64 with CLANG anymore.
> > 
> > Amongst other problems I was told that the code this momnet is
> > incapable to build properly with CLANG, but then several fixes
> > where merged.
> > 
> > Building world ends up everytime at the below shown stage. What's
> > wrong? If I missed something - please enlighten me.
> > 
> > My src.conf attached.
> > 
> > 
> > Regards,
> > 
> > Oliver
> > 
> > 
> > building static c library
> > building shared library libc.so.7
> > building special pic c library
> > ranlib libc_pic.a
> > ranlib libc.a
> > sh /usr/src/tools/install.sh -C -o root -g wheel -m 444   libc.a
> > /usr/obj/usr/src/tmp/usr/lib
> > sh /usr/src/tools/install.sh -s -o root -g wheel -m 444   -S
> > libc.so.7 /usr/obj/usr/src/tmp/lib
> > sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> > be_BY.UTF-8.cat /usr/obj/usr/src/tmp/usr/share/nls/be_BY.UTF-8/libc.cat
> > sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> > ca_ES.ISO8859-1.cat
> > /usr/obj/usr/src/tmp/usr/share/nls/ca_ES.ISO8859-1/libc.cat
> > sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> > de_DE.ISO8859-1.cat
> > /usr/obj/usr/src/tmp/usr/share/nls/de_DE.ISO8859-1/libc.cat
> > sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> > el_GR.ISO8859-7.cat
> > /usr/obj/usr/src/tmp/usr/share/nls/el_GR.ISO8859-7/libc.cat
> > sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> > es_ES.ISO8859-1.cat
> > /usr/obj/usr/src/tmp/usr/share/nls/es_ES.ISO8859-1/libc.cat
> > sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> > fi_FI.ISO8859-1.cat
> > /usr/obj/usr/src/tmp/usr/share/nls/fi_FI.ISO8859-1/libc.cat
> > sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> > fr_FR.ISO8859-1.cat
> > /usr/obj/usr/src/tmp/usr/share/nls/fr_FR.ISO8859-1/libc.cat
> > sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> > gl_ES.ISO8859-1.cat
> > /usr/obj/usr/src/tmp/usr/share/nls/gl_ES.ISO8859-1/libc.cat
> > sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> > hu_HU.ISO8859-2.cat
> > /usr/obj/usr/src/tmp/usr/share/nls/hu_HU.ISO8859-2/libc.cat
> > sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> > it_IT.ISO8859-15.cat
> > /usr/obj/usr/src/tmp/usr/share/nls/it_IT.ISO8859-15/libc.cat
> > sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> > ja_JP.UTF-8.cat /usr/obj/usr/src/tmp/usr/share/nls/ja_JP.UTF-8/libc.cat
> > sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> > ja_JP.eucJP.cat /usr/obj/usr/src/tmp/usr/share/nls/ja_JP.eucJP/libc.cat
> > sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> > ko_KR.UTF-8.cat /usr/obj/usr/src/tmp/usr/share/nls/ko_KR.UTF-8/libc.cat
> > sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> > ko_KR.eucKR.cat /usr/obj/usr/src/tmp/usr/share/nls/ko_KR.eucKR/libc.cat
> > sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> > mn_MN.UTF-8.cat /usr/obj/usr/src/tmp/usr/share/nls/mn_MN.UTF-8/libc.cat
> > sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> > nl_NL.ISO8859-1.cat
> > /usr/obj/usr/src/tmp/usr/share/nls/nl_NL.ISO8859-1/libc.cat
> > sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> > no_NO.ISO8859-1.cat
> > /usr/obj/usr/src/tmp/usr/share/nls/no_NO.ISO8859-1/libc.cat
> > sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> > pl_PL.ISO8859-2.cat
> > /usr/obj/usr/src/tmp/usr/share/nls/pl_PL.ISO8859-2/libc.cat
> > sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> > pt_BR.ISO8859-1.cat
> > /usr/obj/usr/src/tmp/usr/share/nls/pt_BR.ISO8859-1/libc.cat
> > sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> > ru_RU.KOI8-R.cat /usr/obj/usr/src/tmp/usr/share/nls/ru_RU.KOI8-R/libc.cat
> > sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> > sk_SK.ISO8859-2.cat
> > /usr/obj/usr/src/tmp/usr/share/nls/sk_SK.ISO8859-2/libc.cat
> > sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> > sv_SE.ISO8859-1.cat
> > /usr/obj/usr/src/tmp/usr/share/nls/sv_SE.ISO8859-1/libc.cat
> > sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> > uk_UA.UTF-8.cat /usr/obj/usr/src/tmp/usr/share/nls/uk_UA.UTF-8/libc.cat
> > ln -fs /usr/obj/usr/src/tmp/lib/libc.so.7
> > /usr/obj/usr/src/tmp/usr/lib/libc.so
> > sh /usr/src/tools/install.sh -o root -g wheel -m 444   libc_pic.a
> > /usr/obj/usr/src/tmp/usr/lib
> > 1 error
> > *** [libraries] Error code 2
> > 1 error
> > *** [_libraries] Error code 2
> > 1 error
> > *** [buildworld] Error code 2
> > 1 error
> 
> Unfortunately, you did a -j build, which makes the actual errors
> difficult to find, and if you show only the last few lines, as you
> have done here, those errors are not visible at all.
> 
> Try doing a single-threaded build instead.  Save the entire log, using
> script(1) for example, compress it and upload it somewhere.

Full buildworld log:
http://pazzle.otdux.com.ua/logs/buildworld.log
___
freebsd-

Re: FreeBSD 10.0-CURRENT #0 r232730: buildworld broken with CLANG?

2012-03-10 Thread Ivan Klymenko 
В Sat, 10 Mar 2012 14:23:17 +0100
Dimitry Andric  пишет:

> On 2012-03-10 10:39, Ivan Klymenko wrote:
> ...
> > I have a similar problem, but with a different result.
> > 
> > I noticed this only with the svn revision r232253
> > 
> > FreeBSD 10.0-CURRENT #0 r232717M
> > 
> > make.conf:
> > ...
> > #For ccache
> > .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*))
> > && !defined(NOCCACHE)
> > CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/clang,1}
> > CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/clang++,1} .endif
> > 
> > .if empty(.CURDIR:M/usr/ports/*)
> > .if !defined(CC) || ${CC} == "cc"
> > CC=/usr/local/libexec/ccache/clang
> > .endif
> > .if !defined(CXX) || ${CXX} == "c++"
> > CXX=/usr/local/libexec/ccache/clang++
> > .endif
> > .if !defined(CPP) || ${CPP} == "cpp"
> > CPP=/usr/local/libexec/ccache/clang -E
> 
> There is your problem.  Don't use "clang -E", use "clang-cpp".
> Unfortunately, due to compatibility reasons with gcc, "clang -E"
> behaves differently than invoking it as "clang-cpp".

Thank you!

> 
> 
> ...
> > In file included from /usr/src/lib/libc/../../include/rpc/rpc.h:76:
> > /usr/src/lib/libc/../../include/rpc/rpcb_clnt.h:69:8: error:
> > unknown type name 'rpcblist' extern rpcblist *rpcb_getmaps(const
> > struct netconfig *, const char *); ^
> 
> And this is the result of it.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 10.0-CURRENT #0 r232730: buildworld broken with CLANG?

2012-03-10 Thread Dimitry Andric 
On 2012-03-10 00:58, O. Hartmann wrote:
> I might have missed the point but since a week now I can't build FreeBSD
> 10.0 CURRENT/amd64 with CLANG anymore.
> 
> Amongst other problems I was told that the code this momnet is incapable
> to build properly with CLANG, but then several fixes where merged.
> 
> Building world ends up everytime at the below shown stage. What's wrong?
> If I missed something - please enlighten me.
> 
> My src.conf attached.
> 
> 
> Regards,
> 
> Oliver
> 
> 
> building static c library
> building shared library libc.so.7
> building special pic c library
> ranlib libc_pic.a
> ranlib libc.a
> sh /usr/src/tools/install.sh -C -o root -g wheel -m 444   libc.a
> /usr/obj/usr/src/tmp/usr/lib
> sh /usr/src/tools/install.sh -s -o root -g wheel -m 444   -S  libc.so.7
> /usr/obj/usr/src/tmp/lib
> sh /usr/src/tools/install.sh -o root  -g wheel -m 444  be_BY.UTF-8.cat
> /usr/obj/usr/src/tmp/usr/share/nls/be_BY.UTF-8/libc.cat
> sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> ca_ES.ISO8859-1.cat
> /usr/obj/usr/src/tmp/usr/share/nls/ca_ES.ISO8859-1/libc.cat
> sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> de_DE.ISO8859-1.cat
> /usr/obj/usr/src/tmp/usr/share/nls/de_DE.ISO8859-1/libc.cat
> sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> el_GR.ISO8859-7.cat
> /usr/obj/usr/src/tmp/usr/share/nls/el_GR.ISO8859-7/libc.cat
> sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> es_ES.ISO8859-1.cat
> /usr/obj/usr/src/tmp/usr/share/nls/es_ES.ISO8859-1/libc.cat
> sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> fi_FI.ISO8859-1.cat
> /usr/obj/usr/src/tmp/usr/share/nls/fi_FI.ISO8859-1/libc.cat
> sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> fr_FR.ISO8859-1.cat
> /usr/obj/usr/src/tmp/usr/share/nls/fr_FR.ISO8859-1/libc.cat
> sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> gl_ES.ISO8859-1.cat
> /usr/obj/usr/src/tmp/usr/share/nls/gl_ES.ISO8859-1/libc.cat
> sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> hu_HU.ISO8859-2.cat
> /usr/obj/usr/src/tmp/usr/share/nls/hu_HU.ISO8859-2/libc.cat
> sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> it_IT.ISO8859-15.cat
> /usr/obj/usr/src/tmp/usr/share/nls/it_IT.ISO8859-15/libc.cat
> sh /usr/src/tools/install.sh -o root  -g wheel -m 444  ja_JP.UTF-8.cat
> /usr/obj/usr/src/tmp/usr/share/nls/ja_JP.UTF-8/libc.cat
> sh /usr/src/tools/install.sh -o root  -g wheel -m 444  ja_JP.eucJP.cat
> /usr/obj/usr/src/tmp/usr/share/nls/ja_JP.eucJP/libc.cat
> sh /usr/src/tools/install.sh -o root  -g wheel -m 444  ko_KR.UTF-8.cat
> /usr/obj/usr/src/tmp/usr/share/nls/ko_KR.UTF-8/libc.cat
> sh /usr/src/tools/install.sh -o root  -g wheel -m 444  ko_KR.eucKR.cat
> /usr/obj/usr/src/tmp/usr/share/nls/ko_KR.eucKR/libc.cat
> sh /usr/src/tools/install.sh -o root  -g wheel -m 444  mn_MN.UTF-8.cat
> /usr/obj/usr/src/tmp/usr/share/nls/mn_MN.UTF-8/libc.cat
> sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> nl_NL.ISO8859-1.cat
> /usr/obj/usr/src/tmp/usr/share/nls/nl_NL.ISO8859-1/libc.cat
> sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> no_NO.ISO8859-1.cat
> /usr/obj/usr/src/tmp/usr/share/nls/no_NO.ISO8859-1/libc.cat
> sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> pl_PL.ISO8859-2.cat
> /usr/obj/usr/src/tmp/usr/share/nls/pl_PL.ISO8859-2/libc.cat
> sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> pt_BR.ISO8859-1.cat
> /usr/obj/usr/src/tmp/usr/share/nls/pt_BR.ISO8859-1/libc.cat
> sh /usr/src/tools/install.sh -o root  -g wheel -m 444  ru_RU.KOI8-R.cat
>  /usr/obj/usr/src/tmp/usr/share/nls/ru_RU.KOI8-R/libc.cat
> sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> sk_SK.ISO8859-2.cat
> /usr/obj/usr/src/tmp/usr/share/nls/sk_SK.ISO8859-2/libc.cat
> sh /usr/src/tools/install.sh -o root  -g wheel -m 444
> sv_SE.ISO8859-1.cat
> /usr/obj/usr/src/tmp/usr/share/nls/sv_SE.ISO8859-1/libc.cat
> sh /usr/src/tools/install.sh -o root  -g wheel -m 444  uk_UA.UTF-8.cat
> /usr/obj/usr/src/tmp/usr/share/nls/uk_UA.UTF-8/libc.cat
> ln -fs /usr/obj/usr/src/tmp/lib/libc.so.7
> /usr/obj/usr/src/tmp/usr/lib/libc.so
> sh /usr/src/tools/install.sh -o root -g wheel -m 444   libc_pic.a
> /usr/obj/usr/src/tmp/usr/lib
> 1 error
> *** [libraries] Error code 2
> 1 error
> *** [_libraries] Error code 2
> 1 error
> *** [buildworld] Error code 2
> 1 error

Unfortunately, you did a -j build, which makes the actual errors
difficult to find, and if you show only the last few lines, as you have
done here, those errors are not visible at all.

Try doing a single-threaded build instead.  Save the entire log, using
script(1) for example, compress it and upload it somewhere.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 10.0-CURRENT #0 r232730: buildworld broken with CLANG?

2012-03-10 Thread Dimitry Andric 
On 2012-03-10 10:39, Ivan Klymenko wrote:
...
> I have a similar problem, but with a different result.
> 
> I noticed this only with the svn revision r232253
> 
> FreeBSD 10.0-CURRENT #0 r232717M
> 
> make.conf:
> ...
> #For ccache
> .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) && 
> !defined(NOCCACHE)
> CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/clang,1}
> CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/clang++,1}
> .endif
> 
> .if empty(.CURDIR:M/usr/ports/*)
> .if !defined(CC) || ${CC} == "cc"
> CC=/usr/local/libexec/ccache/clang
> .endif
> .if !defined(CXX) || ${CXX} == "c++"
> CXX=/usr/local/libexec/ccache/clang++
> .endif
> .if !defined(CPP) || ${CPP} == "cpp"
> CPP=/usr/local/libexec/ccache/clang -E

There is your problem.  Don't use "clang -E", use "clang-cpp".
Unfortunately, due to compatibility reasons with gcc, "clang -E" behaves
differently than invoking it as "clang-cpp".


...
> In file included from /usr/src/lib/libc/../../include/rpc/rpc.h:76:
> /usr/src/lib/libc/../../include/rpc/rpcb_clnt.h:69:8: error: unknown type 
> name 'rpcblist'
> extern rpcblist *rpcb_getmaps(const struct netconfig *, const char *);
>^

And this is the result of it.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

SU+J and fsck problem ?

2012-03-10 Thread jb 
Hi,

FB9.0-RELEASE; no updates or recompilation.
 
In multi-user mode:
$ mount
/dev/ada0s2a on / (ufs, local, journaled soft-updates)
The fs was in normal state (no known problem, clean shutdown),

Booted by choice in single-user mode.

# mount
/dev/ada0s2a on / (ufs, local, read-only)
 
# fsck -F
** /dev/ada0s2a

USE JOURNAL? [yn] y

** SU+J recovering /dev/ada0s2a
** Reading 33554432 byte journal from inode 4.

RECOVER? [yn] y

** ...
** Processing journal entries.

WRITE CHANGES? [yn] y

** 208 journal records in 13312 bytes for 50% utilization
** Freed 0 inodes (0 dirs) 6 blocks, and 0 frags.

* FILE SYSTEM MARKED CLEAN 

# fsck -F
** /dev/ada0s2a

USE JOURNAL? [yn] n

** Skipping journal, falling through to full fsck

** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=114700 (8 should be 0) 
CORRECT? [yn] n

INCORRECT BLOCK COUNT I=196081 (32 should be 8) 
CORRECT? [yn] n

INCORRECT BLOCK COUNT I=474381 (32 should be 8) 
CORRECT? [yn] n

** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
FREE BLOCK COUNTS(S) WRONG IN SUPERBLK
SALVAGE? [yn] n

SUMMARY INFORMATION BAD
SALVAGE? [yn] n

BLK(S) MISSING IN BIT MAPS
SALVAGE? [yn] n

266075 files, 939314 used, 1896628 free (2724 frags, 236738 blocks, 0.1%
fragmentation)

* FILE SYSTEM MARKED DIRTY *

* FILE SYSTEM WAS MODIFIED *

* PLEASE RERUN FSCK *

# fsck -F
** /dev/ada0s2a

USE JOURNAL? [yn] y

** SU+J recovering /dev/ada0s2a
Journal timestamp does not match fs mount time
** Skipping journal, falling through to full fsck 

** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=114700 (8 should be 0) 
CORRECT? [yn] y

INCORRECT BLOCK COUNT I=196081 (32 should be 8) 
CORRECT? [yn] y

INCORRECT BLOCK COUNT I=474381 (32 should be 8) 
CORRECT? [yn] y

** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
FREE BLOCK COUNTS(S) WRONG IN SUPERBLK
SALVAGE? [yn] y

SUMMARY INFORMATION BAD
SALVAGE? [yn] y

BLK(S) MISSING IN BIT MAPS
SALVAGE? [yn] y

266075 files, 939314 used, 1896629 free (2725 frags, 236738 blocks, 0.1%
fragmentation)

* FILE SYSTEM MARKED CLEAN *

* FILE SYSTEM WAS MODIFIED *

#

Summary:
1. # fsck -F  ## recovery done with J

2. # fsck -F  ## no recovery; fs marked dirty; time stamp modified
 Why during this step there were incorrect block counts reported if the fs
 was recovered and marked clean in step 1 ?
 Despite the fact that choice of no recovery was made, the fs was marked
 dirty (based on false assumption above ?, and time stamp ?)

3. # fsck -F  ## forced skipped Journal
 Same question as in step 2,
 based on which it accepted the choice of recovery ...
 Note:
 after step 2:
   1896628 free and 2724 frags in
   266075 files, 939314 used, 1896620 free (2724 frags, 236738 blocks, ...
 after step 3:
   1896629 free and 2725 frags in
   266075 files, 939314 used, 1896629 free (2725 frags, 236738 blocks, ...

Questions:
- is the fsck working properly with SU+J fs ?
  Note:
  fsck(8)
-F ...
-B ...
   It is recommended that you perform foreground fsck on your systems
   periodically and whenever you encounter file-system-related panics.
- would the fs as after step 1, and steps 1-3 or 1,3 be considered
  "recovered":
  - structurally ?
  - identical ?, does it matter ?
  - integrally ?

Any comments before I file a PR# ?
jb



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 10.0-CURRENT #0 r232730: buildworld broken with CLANG?

2012-03-10 Thread Ivan Klymenko 
В Sat, 10 Mar 2012 00:58:23 +0100
"O. Hartmann"  пишет:

> I might have missed the point but since a week now I can't build
> FreeBSD 10.0 CURRENT/amd64 with CLANG anymore.
> 
> Amongst other problems I was told that the code this momnet is
> incapable to build properly with CLANG, but then several fixes where
> merged.
> 
> Building world ends up everytime at the below shown stage. What's
> wrong? If I missed something - please enlighten me.

I have a similar problem, but with a different result.

I noticed this only with the svn revision r232253

FreeBSD 10.0-CURRENT #0 r232717M

make.conf:
...
#For ccache
.if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) && 
!defined(NOCCACHE)
CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/clang,1}
CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/clang++,1}
.endif

.if empty(.CURDIR:M/usr/ports/*)
.if !defined(CC) || ${CC} == "cc"
CC=/usr/local/libexec/ccache/clang
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX=/usr/local/libexec/ccache/clang++
.endif
.if !defined(CPP) || ${CPP} == "cpp"
CPP=/usr/local/libexec/ccache/clang -E
.endif
.endif
# Don't die on warnings
NO_WERROR=
WERROR=
# Don't forget this when using Jails!
NO_FSCHG=
.if ${CC:T} == "clang"
CFLAGS+= -Qunused-arguments -fcolor-diagnostics
.endif
...

...
/usr/local/libexec/ccache/world/clang -fpic -DPIC  -O2 -mmmx -msse -msse2 
-msse3 -mssse3 -pipe -march=nocona -I/usr/src/lib/libc/include 
-I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64 -DNLS  
-D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 
-I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE 
-DPOSIX_MISTAKE -DMALLOC_PRODUCTION 
-I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime 
-I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN 
-I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 
-fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized 
-Wno-pointer-sign -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch-enum 
-Wno-empty-body -c /usr/src/lib/libc/gen/getmntinfo.c -o getmntinfo.So
distcc[60773] ERROR: compile /usr/.ccache/tmp/getgrent.tmp.nonamehost.60734.i 
on localhost failed
clang: warning: argument unused during compilation: '-I 
/usr/src/lib/libc/include'
clang: warning: argument unused during compilation: '-I 
/usr/src/lib/libc/../../include'
clang: warning: argument unused during compilation: '-I /usr/src/lib/libc/amd64'
clang: warning: argument unused during compilation: '-I 
/usr/src/lib/libc/../../contrib/gdtoa'
clang: warning: argument unused during compilation: '-I 
/usr/obj/usr/src/lib/libc'
clang: warning: argument unused during compilation: '-I 
/usr/src/lib/libc/resolv'
clang: warning: argument unused during compilation: '-I 
/usr/src/lib/libc/../../contrib/tzcode/stdtime'
clang: warning: argument unused during compilation: '-I 
/usr/src/lib/libc/stdtime'
clang: warning: argument unused during compilation: '-I 
/usr/src/lib/libc/locale'
clang: warning: argument unused during compilation: '-I /usr/src/lib/libc/rpc'
In file included from /usr/src/lib/libc/gen/getgrent.c:1:
In file included from /usr/src/lib/libc/gen/getgrent.c:39:
In file included from /usr/src/lib/libc/../../include/rpc/rpc.h:76:
/usr/src/lib/libc/../../include/rpc/rpcb_clnt.h:69:8: error: unknown type name 
'rpcblist'
extern rpcblist *rpcb_getmaps(const struct netconfig *, const char *);
   ^
1 error generated.
*** [getgrent.o] Error code 1
clang: warning: argument unused during compilation: '-I 
/usr/src/lib/libc/include'
clang: warning: argument unused during compilation: '-I 
/usr/src/lib/libc/../../include'
clang: warning: argument unused during compilation: '-I /usr/src/lib/libc/amd64'
clang: warning: argument unused during compilation: '-I 
/usr/src/lib/libc/../../contrib/gdtoa'
clang: warning: argument unused during compilation: '-I 
/usr/obj/usr/src/lib/libc'
clang: warning: argument unused during compilation: '-I 
/usr/src/lib/libc/resolv'
clang: warning: argument unused during compilation: '-I 
/usr/src/lib/libc/../../contrib/tzcode/stdtime'
clang: warning: argument unused during compilation: '-I 
/usr/src/lib/libc/stdtime'
clang: warning: argument unused during compilation: '-I 
/usr/src/lib/libc/locale'
clang: warning: argument unused during compilation: '-I /usr/src/lib/libc/rpc'
distcc[60803] ERROR: compile /usr/.ccache/tmp/getgrent.tmp.nonamehost.60756.i 
on localhost failed
clang: warning: argument unused during compilation: '-I 
/usr/src/lib/libc/include'
clang: warning: argument unused during compilation: '-I 
/usr/src/lib/libc/../../include'
clang: warning: argument unused during compilation: '-I /usr/src/lib/libc/amd64'
clang: warning: argument unused during compilation: '-I 
/usr/src/lib/libc/../../contrib/gdtoa'
clang: warning: argument unused during compilation: '-I 
/usr/obj/usr/src/lib/libc'
clang: warning: argument unused during

[head tinderbox] failure on i386/i386

2012-03-10 Thread FreeBSD Tinderbox 
TB --- 2012-03-10 03:50:00 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-03-10 03:50:00 - starting HEAD tinderbox run for i386/i386
TB --- 2012-03-10 03:50:00 - cleaning the object tree
TB --- 2012-03-10 03:50:10 - cvsupping the source tree
TB --- 2012-03-10 03:50:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/i386/i386/supfile
TB --- 2012-03-10 03:55:35 - building world
TB --- 2012-03-10 03:55:35 - CROSS_BUILD_TESTING=YES
TB --- 2012-03-10 03:55:35 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-03-10 03:55:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-03-10 03:55:35 - SRCCONF=/dev/null
TB --- 2012-03-10 03:55:35 - TARGET=i386
TB --- 2012-03-10 03:55:35 - TARGET_ARCH=i386
TB --- 2012-03-10 03:55:35 - TZ=UTC
TB --- 2012-03-10 03:55:35 - __MAKE_CONF=/dev/null
TB --- 2012-03-10 03:55:35 - cd /src
TB --- 2012-03-10 03:55:35 - /usr/bin/make -B buildworld
>>> World build started on Sat Mar 10 03:55:35 UTC 2012
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Sat Mar 10 05:57:58 UTC 2012
TB --- 2012-03-10 05:57:58 - generating LINT kernel config
TB --- 2012-03-10 05:57:58 - cd /src/sys/i386/conf
TB --- 2012-03-10 05:57:58 - /usr/bin/make -B LINT
TB --- 2012-03-10 05:57:58 - cd /src/sys/i386/conf
TB --- 2012-03-10 05:57:58 - /usr/sbin/config -m LINT
TB --- 2012-03-10 05:57:58 - building LINT kernel
TB --- 2012-03-10 05:57:58 - CROSS_BUILD_TESTING=YES
TB --- 2012-03-10 05:57:58 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-03-10 05:57:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-03-10 05:57:58 - SRCCONF=/dev/null
TB --- 2012-03-10 05:57:58 - TARGET=i386
TB --- 2012-03-10 05:57:58 - TARGET_ARCH=i386
TB --- 2012-03-10 05:57:58 - TZ=UTC
TB --- 2012-03-10 05:57:58 - __MAKE_CONF=/dev/null
TB --- 2012-03-10 05:57:58 - cd /src
TB --- 2012-03-10 05:57:58 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sat Mar 10 05:57:58 UTC 2012
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT completed on Sat Mar 10 06:28:39 UTC 2012
TB --- 2012-03-10 06:28:39 - cd /src/sys/i386/conf
TB --- 2012-03-10 06:28:39 - /usr/sbin/config -m LINT-NOINET
TB --- 2012-03-10 06:28:39 - building LINT-NOINET kernel
TB --- 2012-03-10 06:28:39 - CROSS_BUILD_TESTING=YES
TB --- 2012-03-10 06:28:39 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-03-10 06:28:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-03-10 06:28:39 - SRCCONF=/dev/null
TB --- 2012-03-10 06:28:39 - TARGET=i386
TB --- 2012-03-10 06:28:39 - TARGET_ARCH=i386
TB --- 2012-03-10 06:28:39 - TZ=UTC
TB --- 2012-03-10 06:28:39 - __MAKE_CONF=/dev/null
TB --- 2012-03-10 06:28:39 - cd /src
TB --- 2012-03-10 06:28:39 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET
>>> Kernel build for LINT-NOINET started on Sat Mar 10 06:28:39 UTC 2012
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT-NOINET completed on Sat Mar 10 06:58:02 UTC 2012
TB --- 2012-03-10 06:58:02 - cd /src/sys/i386/conf
TB --- 2012-03-10 06:58:02 - /usr/sbin/config -m LINT-NOINET6
TB --- 2012-03-10 06:58:02 - building LINT-NOINET6 kernel
TB --- 2012-03-10 06:58:02 - CROSS_BUILD_TESTING=YES
TB --- 2012-03-10 06:58:02 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-03-10 06:58:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-03-10 06:58:02 - SRCCONF=/dev/null
TB --- 2012-03-10 06:58:02 - TARGET=i386
TB --- 2012-03-10 06:58:02 - TARGET_ARCH=i386
TB --- 2012-03-10 06:58:02 - TZ=UTC
TB --- 2012-03-10 06:58:02 - __MAKE_CONF=/dev/null
TB --- 2012-03-10 06:58:02 - cd /src
TB --- 2012-03-10 06:58:02 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6
>>> Kernel build for LINT-NOINET6 started on Sat Mar 10 06:58:02 UTC 2012
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT-NOINET6 completed on Sat Mar 10 07:27:32 UTC 2012
TB --- 2012-03-10 07:27:32 - cd /src/sys/i386/conf
TB --- 2012-03-10 07:27:32 - /usr/sbin/config -m LINT-NOIP
TB --- 2012-03-10 07:27:32 - building LINT-NOIP kernel
TB --- 2012-03-10 07:27:32 - CROSS_BUILD_TESTING=YES
TB --- 2012-03-10 07:27:32 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-03-10 07:27:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2