Re: Question on building from sources.
Hi, On Fri, 29 Mar 2013 22:03:11 -0400 Glen Barber wrote: > On Fri, Mar 29, 2013 at 09:31:12PM -0400, Super Bisquit wrote: > > I have my QuickSilver and no internet connection. I have a few > > questions. 1. Do I download the latest for PowerPC(32bit) and then > > download the sources according to the Makefile. > > For ports, yes, you will to do 'make fetch' or 'make fetch-recursive' > for third-party software you want to install. > yes. > > 3. Has anyone else done this before? If yes, then what were your > > results? > > > > It is painful. My suggestion is to identify everything you absolutely > need, and do from a separate machine with internet access: > I do this all the while as I have only random Internet connection. But I do this only for amd64. It works most of the time. Expect some returns to the machine with an Internet connection. > Note that if anything is missing, build will fail at compile time on > the internet-less machine. This should only be a problem for the ports. The sources can easily be downloaded in one go. Erich ___ 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: Question on building from sources.
On Fri, Mar 29, 2013 at 09:31:12PM -0400, Super Bisquit wrote: > I have my QuickSilver and no internet connection. I have a few questions. > 1. Do I download the latest for PowerPC(32bit) and then download the > sources according to the Makefile. For ports, yes, you will to do 'make fetch' or 'make fetch-recursive' for third-party software you want to install. > 2. Will I need to skip checking the hash/md sum so that the > applications can build? No. Hashes are generated locally and compared against information in the distinfo file. If there is a mismatch, that is a bug. > 3. Has anyone else done this before? If yes, then what were your results? > It is painful. My suggestion is to identify everything you absolutely need, and do from a separate machine with internet access: # sh -c 'for i in `make -C /usr/ports/category/port all-depends-list`; \ do make -C $i fetch-recursive; \ done Note that if anything is missing, build will fail at compile time on the internet-less machine. Glen pgpWklgaFfU7s.pgp Description: PGP signature
Re: ports/177488: qemu-1.4
On 3/30/13, Pinter Oliver ICTF wrote:
> CC other mail address
>
> On Sat, Mar 30, 2013 at 01:20:00AM +, freebsd-gnats-sub...@freebsd.org
> wrote:
>> Thank you very much for your problem report.
>> It has the internal identification `ports/177488'.
>> The individual assigned to look at your
>> report is: freebsd-ports-bugs.
>>
>> You can access the state of your problem report at any time
>> via this link:
>>
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=177488
>>
>> >Category: ports
>> >Responsible:freebsd-ports-bugs
>> >Synopsis: qemu-1.4
>> >Arrival-Date: Sat Mar 30 01:20:00 UTC 2013
>>
disable some unneeded function, and make qemu 1.4 compilable on FreeBSD 9.1
>
From 579cf589ca45e6fd7e15d7c214dfa63b57ae4163 Mon Sep 17 00:00:00 2001
From: Oliver Pinter
Date: Sat, 30 Mar 2013 01:06:48 +0100
Subject: [PATCH 1/4] fix this error:
In file included from qemu-char.c:59:
/usr/include/libutil.h:98:6: error: conflicting types for 'hexdump'
voidhexdump(const void *_ptr, int _length, const char *_hdr, int
_flags);
^
/tmp/qemu/include/qemu-common.h:449:6: note: previous
declaration is here
void hexdump(const char *buf, FILE *fp, const char *prefix,
size_t size);
^
1 error generated.
gmake: *** [qemu-char.o] Error 1
Signed-off-by: Oliver Pinter
---
hw/pl330.c| 4 ++--
include/qemu-common.h | 2 +-
util/hexdump.c| 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/pl330.c b/hw/pl330.c
index 1a04773..ac661eb 100644
--- a/hw/pl330.c
+++ b/hw/pl330.c
@@ -1158,7 +1158,7 @@ static int pl330_exec_cycle(PL330Chan *channel)
if (PL330_ERR_DEBUG > 1) {
DB_PRINT("PL330 read from memory @%08x (size = %08x):\n",
q->addr, len);
-hexdump((char *)buf, stderr, "", len);
+qemu_hexdump((char *)buf, stderr, "", len);
}
fifo_res = pl330_fifo_push(&s->fifo, buf, len, q->tag);
if (fifo_res == PL330_FIFO_OK) {
@@ -1190,7 +1190,7 @@ static int pl330_exec_cycle(PL330Chan *channel)
if (PL330_ERR_DEBUG > 1) {
DB_PRINT("PL330 read from memory @%08x (size = %08x):\n",
q->addr, len);
-hexdump((char *)buf, stderr, "", len);
+qemu_hexdump((char *)buf, stderr, "", len);
}
if (q->inc) {
q->addr += len;
diff --git a/include/qemu-common.h b/include/qemu-common.h
index 31fff22..e3cad8a 100644
--- a/include/qemu-common.h
+++ b/include/qemu-common.h
@@ -446,7 +446,7 @@ int uleb128_decode_small(const uint8_t *in, uint32_t *n);
* Hexdump a buffer to a file. An optional string prefix is added to every line
*/
-void hexdump(const char *buf, FILE *fp, const char *prefix, size_t size);
+void qemu_hexdump(const char *buf, FILE *fp, const char *prefix, size_t size);
/* vector definitions */
#ifdef __ALTIVEC__
diff --git a/util/hexdump.c b/util/hexdump.c
index 0d0efc8..969b340 100644
--- a/util/hexdump.c
+++ b/util/hexdump.c
@@ -15,7 +15,7 @@
#include "qemu-common.h"
-void hexdump(const char *buf, FILE *fp, const char *prefix, size_t size)
+void qemu_hexdump(const char *buf, FILE *fp, const char *prefix, size_t size)
{
unsigned int b;
--
1.8.2
From 27810afb999c9acb6dc81f0e9490fd69dd378251 Mon Sep 17 00:00:00 2001
From: Oliver Pinter
Date: Sat, 30 Mar 2013 01:11:58 +0100
Subject: [PATCH 2/4] removed usb-redir support, while it is broken ...
Signed-off-by: Oliver Pinter
---
configure | 1 -
1 file changed, 1 deletion(-)
diff --git a/configure b/configure
index f2af714..ba40756 100755
--- a/configure
+++ b/configure
@@ -540,7 +540,6 @@ esac
if [ "$bsd" = "yes" ] ; then
if [ "$darwin" != "yes" ] ; then
-usb="bsd"
bsd_user="yes"
fi
fi
--
1.8.2
From f2d4bbc618bd6aacd6926dd059a2a7ee649d4ff8 Mon Sep 17 00:00:00 2001
From: Oliver Pinter
Date: Sat, 30 Mar 2013 01:38:53 +0100
Subject: [PATCH 3/4] fix round_page redefinition
/tmp/qemu/hw/ppc/mac_oldworld.c:61:15: error: expected identifier or '('
static hwaddr round_page(hwaddr addr)
^
/usr/include/machine/param.h:128:27: note: expanded from macro 'round_page'
^
/tmp/qemu/hw/ppc/mac_oldworld.c:61:15: error: expected ')'
static hwaddr round_page(hwaddr addr)
^
/usr/include/machine/param.h:128:27: note: expanded from macro 'round_page'
^
/tmp/qemu/hw/ppc/mac_oldworld.c:61:15: note: to match this '('
static hwaddr round_page(hwaddr addr)
^
/usr/include/machine/param.h:128:26: note: expanded from macro 'round_page'
^
/tmp/qemu/hw/ppc/mac_oldworld.c:61:15: error: expected ')'
static hwaddr round_page(hwaddr addr)
^
/usr/include/machine/param.h:128:46: note: expanded from macro 'round_page'
^
/tmp/qemu/hw/ppc/mac_oldwo
Question on building from sources.
I have my QuickSilver and no internet connection. I have a few questions. 1. Do I download the latest for PowerPC(32bit) and then download the sources according to the Makefile. 2. Will I need to skip checking the hash/md sum so that the applications can build? 3. Has anyone else done this before? If yes, then what were your results? I'm asking on two lists because: 1. It is a PowerPC based machine. 2. It will be an installation of current. Thanks muchly. ___ 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: [RFC] vfs.read_min proposal
On Fri, Mar 29, 2013 at 1:58 PM, Konstantin Belousov wrote: > On Thu, Mar 28, 2013 at 10:11:25AM -0700, Maksim Yevmenkin wrote: >> On Thu, Mar 28, 2013 at 12:52 AM, Konstantin Belousov >> wrote: >> >> >> i would like to get some reviews, opinions and/or comments on the patch >> >> below. >> >> >> >> a little bit background, as far as i understand, cluster_read() can >> >> initiate two disk i/o's: one for exact amount of data being requested >> >> (rounded up to a filesystem block size) and another for a configurable >> >> read ahead. read ahead data are always extra and do not super set data >> >> being requested. also, read ahead can be controlled via f_seqcount (on >> >> per descriptor basis) and/or vfs.read_max (global knob). >> >> >> >> in some cases and/or on some work loads it can be beneficial to bundle >> >> original data and read ahead data in one i/o request. in other words, >> >> read more than caller has requested, but only perform one larger i/o, >> >> i.e. super set data being requested and read ahead. >> > >> > The totread argument to the cluster_read() is supplied by the filesystem >> > to indicate how many data in the current request is specified. Always >> > overriding this information means two things: >> > - you fill the buffer and page cache with potentially unused data. >> >> it very well could be >> >> > For some situations, like partial reads, it would be really bad. >> >> certainly possible >> >> > - you increase the latency by forcing the reader to wait for the whole >> > cluster which was not asked for. >> >> perhaps, however, modern drives are fast, and, in fact, are a lot >> better at reading continuous chunks without introducing significant >> delays. >> >> > So it looks as very single- and special-purpose hack. Besides, the >> > global knob is obscure and probably would not have any use except your >> > special situation. Would a file flag be acceptable for you ? >> >> flag would probably work just as well, but having global knob allows >> for runtime tuning without software re-configuration and re-start. > My point is that the 'tuning' there has too wide scope to be acceptable > as the feature for the general-puspose OS. i understand. i was just making parallels with vfs.read_max which has just as wider scope. granted, it can be set on per-descriptor basis, but only lowered, imo. >> > What is the difference in the numbers you see, and what numbers ? >> > Is it targeted for read(2) optimizations, or are you also concerned >> > with the read-ahead done at the fault time ? >> >> ok. please consider the following. modern high performance web server >> - nginx - with aio + sendfile(SF_NODISKIO) method of delivering data. >> >> for those who are not familiar how it works, here is a very quick >> overview of nginx's aio + sendfile >> >> 1) nginx always uses sendfile() with SF_NODISKIO to deliver content. >> it means that if requested pages are not in the buffer cache, send as >> much as available and return EBUSY >> >> 2) when nginx sees EBUSY return code from sendfile() it would issue >> aio_read() for 1 byte. the idea here being that OS will issue a read >> ahead and fill up buffer cache with some pages >> >> 3) when aio_read() completes, nginx calls sendfile() with SF_NODISKIO >> again, making an assumption that at least some of the pages will be in >> the buffer cache. >> >> this model allow for completely non-blocking asynchronous data send >> without copying anything back to user space. sounds awesome, right? >> well, it almost is. here is the problem: aio_read() for 1 byte will >> issue read for 1 filesystem block size, and, *another* read for read >> ahead data. say, we configure, read ahead to be 1mb (via >> ioctl(F_READAHEAD and/or vfs.read_max), and, say, our filesystem block >> size is 64k. we end up with 2 disk reads: one for 64k and another for >> 1mb, two trips to VM, and our average size per disk transfer is (64k + >> 1mb) / 2 = 544kb. >> >> now, if we use vfs.read_min and set it to 16, i.e. 1mb reads with 64k >> filesystem block size, turn off read ahead completely, i.e. set >> vfs.read_max to zero, then *all* cluster_reads() become nice 1mb >> chunks, and, we only do one disk i/o and one trip to VM to get the >> same data. so we effectively doubled (or halfed) our iops. also >> average size per disk transfer is around 900kb (there are still some >> filesystem block sized i/o that are not going via cluser_read()) which >> is a lot nicer for modern disks. > I think this is definitely a feature that should be set by a flag to > either file descriptor used for aio_read, or aio_read call itself. > Adding a flag to aio_read() might be cumbersome from the ABI perspective. something along the lines of ioctl(F_READAHEAD)/f_seqcount might be acceptable, dont you think? >> finally, vfs.read_min allows us to control size of orignal disk reads, >> and, vfs.read_max allows us to control of additional read ahead. so, >> ww control both sides here. in fact, we can have
Re: [RFC] vfs.read_min proposal
On Thu, Mar 28, 2013 at 10:11:25AM -0700, Maksim Yevmenkin wrote: > On Thu, Mar 28, 2013 at 12:52 AM, Konstantin Belousov > wrote: > > >> i would like to get some reviews, opinions and/or comments on the patch > >> below. > >> > >> a little bit background, as far as i understand, cluster_read() can > >> initiate two disk i/o's: one for exact amount of data being requested > >> (rounded up to a filesystem block size) and another for a configurable > >> read ahead. read ahead data are always extra and do not super set data > >> being requested. also, read ahead can be controlled via f_seqcount (on > >> per descriptor basis) and/or vfs.read_max (global knob). > >> > >> in some cases and/or on some work loads it can be beneficial to bundle > >> original data and read ahead data in one i/o request. in other words, > >> read more than caller has requested, but only perform one larger i/o, > >> i.e. super set data being requested and read ahead. > > > > The totread argument to the cluster_read() is supplied by the filesystem > > to indicate how many data in the current request is specified. Always > > overriding this information means two things: > > - you fill the buffer and page cache with potentially unused data. > > it very well could be > > > For some situations, like partial reads, it would be really bad. > > certainly possible > > > - you increase the latency by forcing the reader to wait for the whole > > cluster which was not asked for. > > perhaps, however, modern drives are fast, and, in fact, are a lot > better at reading continuous chunks without introducing significant > delays. > > > So it looks as very single- and special-purpose hack. Besides, the > > global knob is obscure and probably would not have any use except your > > special situation. Would a file flag be acceptable for you ? > > flag would probably work just as well, but having global knob allows > for runtime tuning without software re-configuration and re-start. My point is that the 'tuning' there has too wide scope to be acceptable as the feature for the general-puspose OS. > > > What is the difference in the numbers you see, and what numbers ? > > Is it targeted for read(2) optimizations, or are you also concerned > > with the read-ahead done at the fault time ? > > ok. please consider the following. modern high performance web server > - nginx - with aio + sendfile(SF_NODISKIO) method of delivering data. > > for those who are not familiar how it works, here is a very quick > overview of nginx's aio + sendfile > > 1) nginx always uses sendfile() with SF_NODISKIO to deliver content. > it means that if requested pages are not in the buffer cache, send as > much as available and return EBUSY > > 2) when nginx sees EBUSY return code from sendfile() it would issue > aio_read() for 1 byte. the idea here being that OS will issue a read > ahead and fill up buffer cache with some pages > > 3) when aio_read() completes, nginx calls sendfile() with SF_NODISKIO > again, making an assumption that at least some of the pages will be in > the buffer cache. > > this model allow for completely non-blocking asynchronous data send > without copying anything back to user space. sounds awesome, right? > well, it almost is. here is the problem: aio_read() for 1 byte will > issue read for 1 filesystem block size, and, *another* read for read > ahead data. say, we configure, read ahead to be 1mb (via > ioctl(F_READAHEAD and/or vfs.read_max), and, say, our filesystem block > size is 64k. we end up with 2 disk reads: one for 64k and another for > 1mb, two trips to VM, and our average size per disk transfer is (64k + > 1mb) / 2 = 544kb. > > now, if we use vfs.read_min and set it to 16, i.e. 1mb reads with 64k > filesystem block size, turn off read ahead completely, i.e. set > vfs.read_max to zero, then *all* cluster_reads() become nice 1mb > chunks, and, we only do one disk i/o and one trip to VM to get the > same data. so we effectively doubled (or halfed) our iops. also > average size per disk transfer is around 900kb (there are still some > filesystem block sized i/o that are not going via cluser_read()) which > is a lot nicer for modern disks. I think this is definitely a feature that should be set by a flag to either file descriptor used for aio_read, or aio_read call itself. Adding a flag to aio_read() might be cumbersome from the ABI perspective. > > finally, vfs.read_min allows us to control size of orignal disk reads, > and, vfs.read_max allows us to control of additional read ahead. so, > ww control both sides here. in fact, we can have 1mb reads and 1mb > read aheads together. granted, its not going to be optimal for all > loads. that is why vfs.read_min default is 1. however, i strongly > suspect that there are quite a few workloads where this could really > help with disk i/o. In fact, the existing OS behaviour is reasonable for the arguments which are passed to the syscall. The specified read size is 1, and the current r
Re: [head tinderbox] failure on mips/mips
... damn, this kernel wasn't yet meant to be built. I'll fix that now. Adrian On 29 March 2013 12:57, FreeBSD Tinderbox wrote: > TB --- 2013-03-29 18:54:33 - tinderbox 2.10 running on > freebsd-current.sentex.ca > TB --- 2013-03-29 18:54:33 - FreeBSD freebsd-current.sentex.ca8.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 --- 2013-03-29 18:54:33 - starting HEAD tinderbox run for mips/mips > TB --- 2013-03-29 18:54:33 - cleaning the object tree > TB --- 2013-03-29 18:56:02 - /usr/local/bin/svn stat /src > TB --- 2013-03-29 18:56:58 - At svn revision 248877 > TB --- 2013-03-29 18:56:59 - building world > TB --- 2013-03-29 18:56:59 - CROSS_BUILD_TESTING=YES > TB --- 2013-03-29 18:56:59 - MAKEOBJDIRPREFIX=/obj > TB --- 2013-03-29 18:56:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-29 18:56:59 - SRCCONF=/dev/null > TB --- 2013-03-29 18:56:59 - TARGET=mips > TB --- 2013-03-29 18:56:59 - TARGET_ARCH=mips > TB --- 2013-03-29 18:56:59 - TZ=UTC > TB --- 2013-03-29 18:56:59 - __MAKE_CONF=/dev/null > TB --- 2013-03-29 18:56:59 - cd /src > TB --- 2013-03-29 18:56:59 - /usr/bin/make -B buildworld > >>> Building an up-to-date make(1) > >>> World build started on Fri Mar 29 18:57:04 UTC 2013 > >>> 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 Fri Mar 29 19:57:40 UTC 2013 > TB --- 2013-03-29 19:57:40 - cd /src/sys/mips/conf > TB --- 2013-03-29 19:57:40 - /usr/sbin/config -m ADM5120 > TB --- 2013-03-29 19:57:41 - skipping ADM5120 kernel > TB --- 2013-03-29 19:57:41 - cd /src/sys/mips/conf > TB --- 2013-03-29 19:57:41 - /usr/sbin/config -m ALCHEMY > TB --- 2013-03-29 19:57:41 - skipping ALCHEMY kernel > TB --- 2013-03-29 19:57:41 - cd /src/sys/mips/conf > TB --- 2013-03-29 19:57:41 - /usr/sbin/config -m AP121 > TB --- 2013-03-29 19:57:41 - building AP121 kernel > TB --- 2013-03-29 19:57:41 - CROSS_BUILD_TESTING=YES > TB --- 2013-03-29 19:57:41 - MAKEOBJDIRPREFIX=/obj > TB --- 2013-03-29 19:57:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-29 19:57:41 - SRCCONF=/dev/null > TB --- 2013-03-29 19:57:41 - TARGET=mips > TB --- 2013-03-29 19:57:41 - TARGET_ARCH=mips > TB --- 2013-03-29 19:57:41 - TZ=UTC > TB --- 2013-03-29 19:57:41 - __MAKE_CONF=/dev/null > TB --- 2013-03-29 19:57:41 - cd /src > TB --- 2013-03-29 19:57:41 - /usr/bin/make -B buildkernel KERNCONF=AP121 > >>> Kernel build for AP121 started on Fri Mar 29 19:57:41 UTC 2013 > >>> stage 1: configuring the kernel > -- > cd /src/sys/mips/conf; > > PATH=/obj/mips.mips/src/tmp/legacy/usr/sbin:/obj/mips.mips/src/tmp/legacy/usr/bin:/obj/mips.mips/src/tmp/legacy/usr/games:/obj/mips.mips/src/tmp/legacy/bin:/obj/mips.mips/src/tmp/usr/sbin:/obj/mips.mips/src/tmp/usr/bin:/obj/mips.mips/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > config -d /obj/mips.mips/src/sys/AP121 /src/sys/mips/conf/AP121 > WARNING: duplicate option `AH_DEBUG_ALQ' encountered. > /src/sys/mips/conf/AP121: unknown option "UMTX_NUM_CHAINS" > *** [buildkernel] Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2013-03-29 19:57:41 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2013-03-29 19:57:41 - ERROR: failed to build AP121 kernel > TB --- 2013-03-29 19:57:41 - 2678.20 user 572.04 system 3788.11 real > > > http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full > ___ > freebsd-m...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscr...@freebsd.org" > ___ 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 mips/mips
TB --- 2013-03-29 18:54:33 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-29 18:54:33 - 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 --- 2013-03-29 18:54:33 - starting HEAD tinderbox run for mips/mips TB --- 2013-03-29 18:54:33 - cleaning the object tree TB --- 2013-03-29 18:56:02 - /usr/local/bin/svn stat /src TB --- 2013-03-29 18:56:58 - At svn revision 248877 TB --- 2013-03-29 18:56:59 - building world TB --- 2013-03-29 18:56:59 - CROSS_BUILD_TESTING=YES TB --- 2013-03-29 18:56:59 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-29 18:56:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-29 18:56:59 - SRCCONF=/dev/null TB --- 2013-03-29 18:56:59 - TARGET=mips TB --- 2013-03-29 18:56:59 - TARGET_ARCH=mips TB --- 2013-03-29 18:56:59 - TZ=UTC TB --- 2013-03-29 18:56:59 - __MAKE_CONF=/dev/null TB --- 2013-03-29 18:56:59 - cd /src TB --- 2013-03-29 18:56:59 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Mar 29 18:57:04 UTC 2013 >>> 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 Fri Mar 29 19:57:40 UTC 2013 TB --- 2013-03-29 19:57:40 - cd /src/sys/mips/conf TB --- 2013-03-29 19:57:40 - /usr/sbin/config -m ADM5120 TB --- 2013-03-29 19:57:41 - skipping ADM5120 kernel TB --- 2013-03-29 19:57:41 - cd /src/sys/mips/conf TB --- 2013-03-29 19:57:41 - /usr/sbin/config -m ALCHEMY TB --- 2013-03-29 19:57:41 - skipping ALCHEMY kernel TB --- 2013-03-29 19:57:41 - cd /src/sys/mips/conf TB --- 2013-03-29 19:57:41 - /usr/sbin/config -m AP121 TB --- 2013-03-29 19:57:41 - building AP121 kernel TB --- 2013-03-29 19:57:41 - CROSS_BUILD_TESTING=YES TB --- 2013-03-29 19:57:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-29 19:57:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-29 19:57:41 - SRCCONF=/dev/null TB --- 2013-03-29 19:57:41 - TARGET=mips TB --- 2013-03-29 19:57:41 - TARGET_ARCH=mips TB --- 2013-03-29 19:57:41 - TZ=UTC TB --- 2013-03-29 19:57:41 - __MAKE_CONF=/dev/null TB --- 2013-03-29 19:57:41 - cd /src TB --- 2013-03-29 19:57:41 - /usr/bin/make -B buildkernel KERNCONF=AP121 >>> Kernel build for AP121 started on Fri Mar 29 19:57:41 UTC 2013 >>> stage 1: configuring the kernel -- cd /src/sys/mips/conf; PATH=/obj/mips.mips/src/tmp/legacy/usr/sbin:/obj/mips.mips/src/tmp/legacy/usr/bin:/obj/mips.mips/src/tmp/legacy/usr/games:/obj/mips.mips/src/tmp/legacy/bin:/obj/mips.mips/src/tmp/usr/sbin:/obj/mips.mips/src/tmp/usr/bin:/obj/mips.mips/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /obj/mips.mips/src/sys/AP121 /src/sys/mips/conf/AP121 WARNING: duplicate option `AH_DEBUG_ALQ' encountered. /src/sys/mips/conf/AP121: unknown option "UMTX_NUM_CHAINS" *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-29 19:57:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-29 19:57:41 - ERROR: failed to build AP121 kernel TB --- 2013-03-29 19:57:41 - 2678.20 user 572.04 system 3788.11 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full ___ 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: net/xmlrpc-c-devel port with GCC 4.8
On 03/20/2013 20:49, Dimitry Andric wrote:> On Mar 20, 2013, at 19:54, deeptech71 wrote: /usr/local/lib/gcc48/include/c++/bits/locale_facets.h:869: undefined reference to `std::ctype::_M_widen_init() const' [...] /usr/local/lib/gcc48/include/c++/bits/stl_list.h:1550: undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)' [...] I worked around this by adding "/usr/local/lib/gcc48/libstdc++.so" to the make-rule. Weird. Why does this work? Should it? This is a general problem with the gcc ports: they should all pull in their own version(s) of libstdc++.so instead of using the default linker path. And possibly add rpath entries, to make sure the correct version of libstdc++.so is used at runtime. On 03/28/2013 15:37, Renato Botelho wrote: The problem here is -L/usr/lib, libwww-config --libs returned that, maybe the issue is on libwww side. ! ___ 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"
