Re: gstat don't work after update to 10.0-CURRENT
On Sat, Apr 21, 2012 at 09:33:58AM -0400, you (Ryan Stone) sent the following to [freebsd-current] : > I believe that this was fixed in r234107 I updated to r234515 today on amd64 and I can confirm gstat(8) works again. -- marco Proud recurring donor of the FreeBSD Foundation You can have any color you want, as long as it is black! ___ 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"
netstat: no namelist on amd64 (r234515)
On both r233779 and r234515 on my 10-CURRENT amd64 home box netstat returns: no namelist This is a Q9550 system and I rebuilt both world and kernel using clang with -j8 The last revision netstat was functioning for me was r230839. I went from r230839 to r233779 so no other updates went in between those 2 revisions. -- marco Proud recurring donor of the FreeBSD Foundation You can have any color you want, as long as it is black! ___ 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: clang and 'config KERNFILE' error
On Sun, Apr 22, 2012 at 01:18:53AM +0200, Dimitry Andric wrote:
> On 2012-04-20 02:40, Steve Kargl wrote:
> >laptop:root[227] uname -a
> >FreeBSD laptop 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r230975M: Sat Feb 4
> >09:03:27 PST 2012 root@laptop:/usr/obj/usr/src/sys/MOBILE i386
> >
> >
> >laptop:root[224] config MOBILE
> >Kernel build directory is ../compile/MOBILE
> >Don't forget to do ``make cleandepend&& make depend''
> >laptop:root[225] cd ../compile/MOBILE
> >laptop:root[226] make cleandepend&& make depend
> >"../../../conf/kern.pre.mk", line 87: Malformed conditional
> >(${MK_CLANG_IS_CC} == "no"&& ${CC:T:Mclang} != "clang")
> >"../../../conf/kern.pre.mk", line 98: if-less endif
> >"../../../conf/kern.pre.mk", line 104: Malformed conditional
> >(${MK_CLANG_IS_CC} != "no" || ${CC:T:Mclang} == "clang")
> >"../../../conf/kern.pre.mk", line 106: if-less endif
> >"../../../conf/kern.mk", line 18: Malformed conditional (${MK_CLANG_IS_CC}
> >!= "no" || ${CC:T:Mclang} == "clang")
> >"../../../conf/kern.mk", line 31: if-less endif
> >"../../../conf/kern.mk", line 53: Malformed conditional (${MK_CLANG_IS_CC}
> >== "no"&& ${CC:T:Mclang} != "clang")
> >"../../../conf/kern.mk", line 60: if-less endif
> >make: fatal errors encountered -- cannot continue
>
> Hi Steve,
>
> This means your /usr/share/mk files are out of sync with your source
> tree. When you build kernels in the old way, this will not work
> properly. I guess the simplest solution is to set MAKESYSPATH to
> /usr/src/share/mk, or just use "make buildkernel KERNCONF=MOBILE".
Thanks for the explanation.
I normally keep my src tree and installed system in sync.
It appears that I may have done an 'svn update' without
re-installing the system.
One reason that I was baffled by the above error is that
I have WITHOUT_CLANG in my /etc/src.conf file. I was
under the impression that this would disable references
to anything associated with clang.
--
Steve
___
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: Some performance measurements on the FreeBSD network stack
Most of these issues are well known. Addressing the bottlenecks is simply time consuming due to the fact that any bugs introduced during development potentially impact many users. -Kip On Sun, Apr 22, 2012 at 4:14 AM, Adrian Chadd wrote: > Hi, > > This honestly sounds like it's begging for an > instrumentation/analysis/optimisation project. > > What do we need to do? > > > Adrian -- “The real damage is done by those millions who want to 'get by.' The ordinary men who just want to be left in peace. Those who don’t want their little lives disturbed by anything bigger than themselves. Those with no sides and no causes. Those who won’t take measure of their own strength, for fear of antagonizing their own weakness. Those who don’t like to make waves—or enemies. Those for whom freedom, honour, truth, and principles are only literature. Those who live small, love small, die small. It’s the reductionist approach to life: if you keep it small, you’ll keep it under control. If you don’t make any noise, the bogeyman won’t find you. But it’s all an illusion, because they die too, those people who roll up their spirits into tiny little balls so as to be safe. Safe?! >From what? Life is always on the edge of death; narrow streets lead to the same place as wide avenues, and a little candle burns itself out just like a flaming torch does. I choose my own way to burn.” Sophie Scholl ___ 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: buildworld fails on FreeBSD 7.x for HEAD from 19.04.2012
On Apr 20, 2012, at 10:26 AM, Doug Barton wrote: > On 4/20/2012 5:16 AM, Jan Sieka wrote: >> I can't build world from recent sources (HEAD as of 2012.04.19 11:06:48 >> UTC) on a machine running FreeBSD 7.3. > > That's not a supported configuration. We don't promise support for > $VERSION on anything less than the most recent version of $VERSION - 1. I'm sorry, but given the error below shown by Jan I don't buy this argument. It seems like file's objects are is trying to link against an ABI incompatible libc and failing. The build system should handle this properly if you invoke the top-level targets (buildworld, buildkernel, distribution). Thanks, -Garrett___ 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: buildworld fails on FreeBSD 7.x for HEAD from 19.04.2012
On 2012-04-22 16:51, Garrett Cooper wrote: > On Apr 20, 2012, at 10:26 AM, Doug Barton wrote: >> On 4/20/2012 5:16 AM, Jan Sieka wrote: >>> I can't build world from recent sources (HEAD as of 2012.04.19 11:06:48 >>> UTC) on a machine running FreeBSD 7.3. >> >> That's not a supported configuration. We don't promise support for >> $VERSION on anything less than the most recent version of $VERSION - 1. > > I'm sorry, but given the error below shown by Jan I don't buy this > argument. It seems like file's objects are is trying to link against an ABI > incompatible libc and failing. The build system should handle this properly > if you invoke the top-level targets (buildworld, buildkernel, distribution). This is trickier than you think: the error occurs during the build-tools stage, where everything that builds still uses the host's toolchain and libraries (e.g. the 7.x versions). So if you try to build a program that uses getline(), it will not be able to link. This is what happens with the 'mkmagic' tool. However, this will have started failing just very recently, since obrien updated to a new file(1) version, and regenerated the config.h file: http://svnweb.freebsd.org/base/head/lib/libmagic/config.h?r1=208341&r2=234449 Maybe some hackery could be inserted in lib/libmagic/Makefile, so during the early stages a 'toned down' config.h file is used. The libmagic source has its own getline implementation in contrib/file/getline.c, so maybe that could be used instead. On the other hand, going from 7.x to HEAD via the 'official' route would go like: - Update 7.x to the latests 7-STABLE - Update 7-STABLE to 8-STABLE - Update 8-STABLE to 9-STABLE - Update 9-STABLE to 10-CURRENT It is *way* easier to just grab a recent 10-CURRENT snapshot ISO and just reinstall. :) ___ 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: buildworld fails on FreeBSD 7.x for HEAD from 19.04.2012
On Apr 22, 2012, at 8:51 AM, Dimitry Andric wrote: > On 2012-04-22 16:51, Garrett Cooper wrote: >> On Apr 20, 2012, at 10:26 AM, Doug Barton wrote: >>> On 4/20/2012 5:16 AM, Jan Sieka wrote: I can't build world from recent sources (HEAD as of 2012.04.19 11:06:48 UTC) on a machine running FreeBSD 7.3. >>> >>> That's not a supported configuration. We don't promise support for >>> $VERSION on anything less than the most recent version of $VERSION - 1. >> >> I'm sorry, but given the error below shown by Jan I don't buy this >> argument. It seems like file's objects are is trying to link against an ABI >> incompatible libc and failing. The build system should handle this properly >> if you invoke the top-level targets (buildworld, buildkernel, distribution). > > This is trickier than you think: the error occurs during the build-tools > stage, where everything that builds still uses the host's toolchain and > libraries (e.g. the 7.x versions). So if you try to build a program > that uses getline(), it will not be able to link. This is what happens > with the 'mkmagic' tool. > > However, this will have started failing just very recently, since obrien > updated to a new file(1) version, and regenerated the config.h file: > > http://svnweb.freebsd.org/base/head/lib/libmagic/config.h?r1=208341&r2=234449 And this is why NetBSD runs autotools on their tree sources in their build instead of dealing with stale config.h files -- which also brings up the bug of what happens if support is available on one architecture, but not the other? Doesn't happen often and I hope it wouldn't happen in sources imported into FreeBSD, but I've seen it happen in the past with various open source projects. > Maybe some hackery could be inserted in lib/libmagic/Makefile, so during > the early stages a 'toned down' config.h file is used. The libmagic > source has its own getline implementation in contrib/file/getline.c, so > maybe that could be used instead. That seems like a good idea for the time being. On the other hand (and this is probably a dumb question), but why is libmagic required in the build-tools stage? > On the other hand, going from 7.x to HEAD via the 'official' route would go > like: > > - Update 7.x to the latests 7-STABLE > - Update 7-STABLE to 8-STABLE > - Update 8-STABLE to 9-STABLE > - Update 9-STABLE to 10-CURRENT > > It is *way* easier to just grab a recent 10-CURRENT snapshot ISO and > just reinstall. :) Ugh. The usecase (that's now broken) is that Jan from Semihalf might have been running CURRENT builds on an older (stable) build machine. I have done this a couple times in the past (but not regularly because I usually follow the above prescribed method or just hop 1-2 major versions). Other groups I've worked with use the same major version or higher than the running build because of chroot hackery involved in the build process. Thanks, -Garrett___ 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: buildworld fails on FreeBSD 7.x for HEAD from 19.04.2012
On 2012-04-22 18:06, Garrett Cooper wrote: > On Apr 22, 2012, at 8:51 AM, Dimitry Andric wrote: ... >> However, this will have started failing just very recently, since obrien >> updated to a new file(1) version, and regenerated the config.h file: >> >> >> http://svnweb.freebsd.org/base/head/lib/libmagic/config.h?r1=208341&r2=234449 > > And this is why NetBSD runs autotools on their tree sources in their build > instead of dealing with stale config.h files Well, I wouldn't want to run autoconf during build, firstly because it is horribly slow, and second because the results will be less predictable. Maybe during the bootstrap stage, it would be acceptable. But even then, one of the configure scripts could fail due to too-old system components, and you would be SOL. > which also brings up the bug of what happens if support is available on one > architecture, but not the other? Doesn't happen often and I hope it wouldn't > happen in sources imported into FreeBSD, but I've seen it happen in the past > with various open source projects. Usually, if something is arch-dependent in a config.h file, we simply surround it with #ifdefs. >> Maybe some hackery could be inserted in lib/libmagic/Makefile, so during >> the early stages a 'toned down' config.h file is used. The libmagic >> source has its own getline implementation in contrib/file/getline.c, so >> maybe that could be used instead. > > That seems like a good idea for the time being. > > On the other hand (and this is probably a dumb question), but why is libmagic > required in the build-tools stage? Apparently the file(1) build needs a 'mkmagic' tool, which generates .mgc files (the 'compiled' version of magic files). This requirement was originally added in r81845, more than 10 years ago. >> On the other hand, going from 7.x to HEAD via the 'official' route would go >> like: >> >> - Update 7.x to the latests 7-STABLE >> - Update 7-STABLE to 8-STABLE >> - Update 8-STABLE to 9-STABLE >> - Update 9-STABLE to 10-CURRENT >> >> It is *way* easier to just grab a recent 10-CURRENT snapshot ISO and >> just reinstall. :) > > Ugh. The usecase (that's now broken) is that Jan from Semihalf might have > been running CURRENT builds on an older (stable) build machine. I have done > this a couple times in the past (but not regularly because I usually follow > the above prescribed method or just hop 1-2 major versions). Yes, it might work, but there is no guarantee. I'm not sure if there is enough incentive to change this policy. It would potentially require a lot effort to make it always work. > Other groups I've worked with use the same major version or higher than the > running build because of chroot hackery involved in the build process. I wasn't aware of any chroot hackery? ___ 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"
stat(1) - option doubled in manpage
Just a small note. In stat(1) the description of option -l doubles: -l Display output in ls -lT format. Perhaps someone with a commit bit is interested in correcting this? ___ 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: stat(1) - option doubled in manpage
On Apr 22, 2012, at 11:00 AM, Rainer Hurling wrote: > Just a small note. > > In stat(1) the description of option -l doubles: > > -l Display output in ls -lT format. > > > Perhaps someone with a commit bit is interested in correcting this? Please submit a PR so this doesn't get lost. Thanks! -Garrett ___ 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: stat(1) - option doubled in manpage
On 4/22/12 20:00 , Rainer Hurling wrote: Just a small note. In stat(1) the description of option -l doubles: -l Display output in ls -lT format. Perhaps someone with a commit bit is interested in correcting this? ___ Fixed, thanks! Christian ___ 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: buildworld fails on FreeBSD 7.x for HEAD from 19.04.2012
On Apr 22, 2012, at 10:34 AM, Dimitry Andric wrote:
> Well, I wouldn't want to run autoconf during build, firstly because it
> is horribly slow, and second because the results will be less
> predictable. Maybe during the bootstrap stage, it would be acceptable.
Sure -- that seems reasonable.
> But even then, one of the configure scripts could fail due to too-old
> system components, and you would be SOL.
… but it would be a step forward from where things are currently at. I'm not
sure how well tested "source upgrade" paths are, but being able to upgrade from
the lowest supported version to the latest supported version, then upgrading to
CURRENT (at the very least) would be nice.
> Usually, if something is arch-dependent in a config.h file, we simply
> surround it with #ifdefs.
Makes sense (assumption being that it can be controlled via the
config.h/configure.{ac,in} file). However, jemalloc recently disproved this >_<.
> Apparently the file(1) build needs a 'mkmagic' tool, which generates
> .mgc files (the 'compiled' version of magic files). This requirement
> was originally added in r81845, more than 10 years ago.
I tested out removing libmagic from Makefile.inc1 and see that there's some
dependency magic going on there where building the library failed.
> Yes, it might work, but there is no guarantee. I'm not sure if there is
> enough incentive to change this policy. It would potentially require a
> lot effort to make it always work.
Understood and I guess the ownness is upon the stakeholders to fix this, but
there are a lot of companies that depend on things like this working (at least
to reduce pain when doing source upgrades). This would probably be less of an
issue for developers that use freebsd-update or for companies that roll their
own freebsd-update (and servers). I have yet to run into a company that does
this though (not saying there aren't groups that could or do do this, but it's
not the standard path).
> I wasn't aware of any chroot hackery?
A publicly available example is available in FreeNAS (
http://freenas.svn.sourceforge.net/viewvc/freenas?view=revision&revision=8193
); the hangup is building packages for a target system that doesn't match the
build host.
Cheers!
-Garrett___
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"
[head tinderbox] failure on powerpc/powerpc
TB --- 2012-04-23 02:59:03 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-23 02:59:03 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-23 02:59:03 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-04-23 02:59:03 - cleaning the object tree TB --- 2012-04-23 02:59:03 - cvsupping the source tree TB --- 2012-04-23 02:59:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-04-23 02:59:47 - building world TB --- 2012-04-23 02:59:47 - CROSS_BUILD_TESTING=YES TB --- 2012-04-23 02:59:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-23 02:59:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-23 02:59:47 - SRCCONF=/dev/null TB --- 2012-04-23 02:59:47 - TARGET=powerpc TB --- 2012-04-23 02:59:47 - TARGET_ARCH=powerpc TB --- 2012-04-23 02:59:47 - TZ=UTC TB --- 2012-04-23 02:59:47 - __MAKE_CONF=/dev/null TB --- 2012-04-23 02:59:47 - cd /src TB --- 2012-04-23 02:59:47 - /usr/bin/make -B buildworld >>> World build started on Mon Apr 23 02:59:48 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 Mon Apr 23 05:16:49 UTC 2012 TB --- 2012-04-23 05:16:49 - generating LINT kernel config TB --- 2012-04-23 05:16:49 - cd /src/sys/powerpc/conf TB --- 2012-04-23 05:16:49 - /usr/bin/make -B LINT TB --- 2012-04-23 05:16:49 - cd /src/sys/powerpc/conf TB --- 2012-04-23 05:16:49 - /usr/sbin/config -m LINT TB --- 2012-04-23 05:16:50 - building LINT kernel TB --- 2012-04-23 05:16:50 - CROSS_BUILD_TESTING=YES TB --- 2012-04-23 05:16:50 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-23 05:16:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-23 05:16:50 - SRCCONF=/dev/null TB --- 2012-04-23 05:16:50 - TARGET=powerpc TB --- 2012-04-23 05:16:50 - TARGET_ARCH=powerpc TB --- 2012-04-23 05:16:50 - TZ=UTC TB --- 2012-04-23 05:16:50 - __MAKE_CONF=/dev/null TB --- 2012-04-23 05:16:50 - cd /src TB --- 2012-04-23 05:16:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Apr 23 05:16:50 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 Mon Apr 23 05:35:47 UTC 2012 TB --- 2012-04-23 05:35:47 - cd /src/sys/powerpc/conf TB --- 2012-04-23 05:35:47 - /usr/sbin/config -m GENERIC TB --- 2012-04-23 05:35:47 - building GENERIC kernel TB --- 2012-04-23 05:35:47 - CROSS_BUILD_TESTING=YES TB --- 2012-04-23 05:35:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-23 05:35:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-23 05:35:47 - SRCCONF=/dev/null TB --- 2012-04-23 05:35:47 - TARGET=powerpc TB --- 2012-04-23 05:35:47 - TARGET_ARCH=powerpc TB --- 2012-04-23 05:35:47 - TZ=UTC TB --- 2012-04-23 05:35:47 - __MAKE_CONF=/dev/null TB --- 2012-04-23 05:35:47 - cd /src TB --- 2012-04-23 05:35:47 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Apr 23 05:35:47 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 GENERIC completed on Mon Apr 23 05:50:09 UTC 2012 TB --- 2012-04-23 05:50:09 - cd /src/sys/powerpc/conf TB --- 2012-04-23 05:50:09 - /usr/sbin/config -m GENERIC64 TB --- 2012-04-23 05:50:09 - skipping GENERIC64 kernel TB --- 2012-04-23 05:50:09 - cd /src/sys/powerpc/conf TB --- 2012-04-23 05:50:09 - /usr/sbin/config -m MPC85XX TB --- 2012-04-23 05:50:09 - building MPC85XX kernel TB --- 2012-04-23 05:50:09 - CROSS_BUILD_TESTING=YES TB --- 2012-04-23 05:50:09 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-23 05:50:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-23 05:50:09 - SRCCONF=/dev/null TB --- 2012-04-23 05:50:09 - TARGET=powerpc TB --- 2012-04-23 05:50:09 - TARGET_ARCH=powerpc TB --- 2012-04-23 05:50:09 - TZ=UTC TB --- 2012-04-23 05:50:09 - __MAKE_CONF=/dev/null TB --- 2012-04-23 05:50:09 - cd /src TB --- 2012-04-23 05:50:09 - /usr/bin/make -B buildkernel KERNCONF=MPC85XX >>> Kernel build for MPC85XX started on Mon Apr 23 05:50:09 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 [...] cc -c -O -pipe -std=c99 -Wa
