From: Yasuhiro Kimura
Subject: Re: Buildworld fails with external GCC toolchain
Date: Tue, 15 Feb 2022 08:26:00 +0900 (JST)
>> I have amd64 world + kernel building with GCC 9 and the only remaining
>> open review not merged yet is https://reviews.freebsd.org/D34147.
>>
>&g
From: John Baldwin
Subject: Re: Buildworld fails with external GCC toolchain
Date: Mon, 14 Feb 2022 10:46:29 -0800
>>> Not really, the gcc 9 build has been broken for months, as far as I
>>> know.
>>>
>>> See also: https://ci.freebsd.org/job/FreeBSD-main-amd6
On 2/12/22 11:34 AM, Yasuhiro Kimura wrote:
From: Dimitry Andric
Subject: Re: Buildworld fails with external GCC toolchain
Date: Fri, 11 Feb 2022 22:53:44 +0100
Not really, the gcc 9 build has been broken for months, as far as I know.
See also: https://ci.freebsd.org/job/FreeBSD-main-amd64
From: Dimitry Andric
Subject: Re: Buildworld fails with external GCC toolchain
Date: Fri, 11 Feb 2022 22:53:44 +0100
> Not really, the gcc 9 build has been broken for months, as far as I know.
>
> See also: https://ci.freebsd.org/job/FreeBSD-main-amd64-gcc9_build/
>
> The last
On 11 Feb 2022, at 21:07, Yasuhiro Kimura wrote:
>
> I'm tring to update devel/binutils port to 2.38. When it was updated
> to 2.37.1, there was a suggestion that it should also be checked if
> building base system with GCC succeeds as binutils is a part of
> external GCC toolchain. So I'd like t
Hello,
I'm tring to update devel/binutils port to 2.38. When it was updated
to 2.37.1, there was a suggestion that it should also be checked if
building base system with GCC succeeds as binutils is a part of
external GCC toolchain. So I'd like to do it with binutils 2.38 before
updating the port.
On 30/11/2020 16:03, Michal Meloun wrote:
On 30.11.2020 13:11, Johan Hendriks wrote:
On 30/11/2020 12:29, Hans Petter Selasky wrote:
On 11/30/20 11:43 AM, Johan Hendriks wrote:
My server running FreeBSD 13.0-CURRENT #7 r368110 fails to build to
r368182
I did a make cleanworld && make clea
On 30.11.2020 13:11, Johan Hendriks wrote:
On 30/11/2020 12:29, Hans Petter Selasky wrote:
On 11/30/20 11:43 AM, Johan Hendriks wrote:
My server running FreeBSD 13.0-CURRENT #7 r368110 fails to build to
r368182
I did a make cleanworld && make cleanworld to make sure i use a fresh
build but
On 30/11/2020 12:29, Hans Petter Selasky wrote:
On 11/30/20 11:43 AM, Johan Hendriks wrote:
My server running FreeBSD 13.0-CURRENT #7 r368110 fails to build to
r368182
I did a make cleanworld && make cleanworld to make sure i use a fresh
build but it errors out with the following message.
T
On 11/30/20 11:43 AM, Johan Hendriks wrote:
My server running FreeBSD 13.0-CURRENT #7 r368110 fails to build to r368182
I did a make cleanworld && make cleanworld to make sure i use a fresh
build but it errors out with the following message.
This is a known issue and will be fixed.
--HPS
___
My server running FreeBSD 13.0-CURRENT #7 r368110 fails to build to r368182
I did a make cleanworld && make cleanworld to make sure i use a fresh
build but it errors out with the following message.
Building /usr/obj/usr/src/amd64.amd64/lib/libsysdecode/ioctl.o
cc -target x86_64-unknown-freebsd1
Dimitry Andric writes:
> /usr/src/contrib/llvm-project/clang/lib/Basic/SourceManager.cpp:1228:10:
> fatal error: 'emmintrin.h' file not found
> #include
> ^
> ...
> > In file included from
> /usr/src/contrib/llvm-project/clang/lib/Basic/SourceManag
On 9 May 2020, at 05:10, Robert Huff wrote:
>
> Chris writes:
>>> "make buildowrld" fails with:
...
/usr/src/contrib/llvm-project/clang/lib/Basic/SourceManager.cpp:1228:10:
fatal error: 'emmintrin.h' file not found
#include
^
...
> In file included fr
Chris writes:
> >"make buildowrld" fails with:
> >
> > > c++ -O2 -pipe -fno-common
> > > -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang
> > > -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm
> > > -I/usr/src/contrib/llvm-project/clang/lib/Basic
> >
On Thu, 7 May 2020 23:11:22 -0400 Robert Huff roberth...@rcn.com said
Hello:
On a system running:
FreeBSD 13.0-CURRENT #0 r354131: Mon Oct 28 17:27:33 EDT 2019 amd64
Today around noon I downloaded a fresh copy of the source tree
(for base/head) to r360785.
make.conf:
Hello:
On a system running:
FreeBSD 13.0-CURRENT #0 r354131: Mon Oct 28 17:27:33 EDT 2019 amd64
Today around noon I downloaded a fresh copy of the source tree
(for base/head) to r360785.
make.conf:
#WITH_DEBUG=yes
SENDMAIL_CFLAGS=-I/usr/local/include/sasl -DSASL
SENDM
On Fri, Dec 28, 2018 at 10:18:12AM +0100, Gary Jennejohn wrote:
> I don't know why this hasn't already been reported, but I've been
> seeing this error since the commit was made.
>
> ===> lib/libc (obj,all,install)
> /usr/src/lib/libc/string/strerror.c:96:11: error: passing 'const char []' to
> p
I don't know why this hasn't already been reported, but I've been
seeing this error since the commit was made.
===> lib/libc (obj,all,install)
/usr/src/lib/libc/string/strerror.c:96:11: error: passing 'const char []' to
parameter of type 'char *' discards qualifiers
[-Werror,-Wincompatible-point
> On 11. Jul 2018, at 08:22, blubee blubeeme wrote:
>
> Why am I getting these errors?
>
> error: user-defined literal suffixes not starting with '_' are reserved
> [-Werror,-Wuser-defined-literals]
>
> --
> In file included from /usr/src/usr.sbin/pmc/cmd_pmc_filter.cc:71
Why am I getting these errors?
error: user-defined literal suffixes not starting with '_' are reserved
[-Werror,-Wuser-defined-literals]
--
In file included from /usr/src/usr.sbin/pmc/cmd_pmc_filter.cc:71:
In file included from
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/
On Tue, Apr 10, 2018, Kristof Provost wrote:
> On 9 Apr 2018, at 13:10, Vladimir Zakharov wrote:
> > On Mon, Apr 09, 2018, Kristof Provost wrote:
> > > On 9 Apr 2018, at 10:50, Vladimir Zakharov wrote:
> > >
> > > For several days buildworld fails f
On 9 Apr 2018, at 13:10, Vladimir Zakharov wrote:
On Mon, Apr 09, 2018, Kristof Provost wrote:
On 9 Apr 2018, at 10:50, Vladimir Zakharov wrote:
For several days buildworld fails for me with the following
error. Cleaning
and
rebuilding didn't help.
===> tests/sys/ne
On Mon, Apr 09, 2018, Kristof Provost wrote:
> On 9 Apr 2018, at 10:50, Vladimir Zakharov wrote:
>
> For several days buildworld fails for me with the following error.
> Cleaning
> and
> rebuilding didn't help.
>
> ===> tests/sys/netpfil/pf/
On 9 Apr 2018, at 10:50, Vladimir Zakharov wrote:
For several days buildworld fails for me with the following error.
Cleaning and
rebuilding didn't help.
===> tests/sys/netpfil/pf/ioctl (all)
--- validation ---
(cd /usr/src/tests/sys/netpfil/pf/ioctl &&
DEPENDFILE=.d
Hello!
For several days buildworld fails for me with the following error. Cleaning and
rebuilding didn't help.
===> tests/sys/netpfil/pf/ioctl (all)
--- validation ---
(cd /usr/src/tests/sys/netpfil/pf/ioctl && DEPENDFILE=.depend.validation
NO_SUBDIR=1 make -f /usr/src/test
Hi Ed
Yes how do I get those logs? I will be checking dmesg from time to time (is
there a way to tail it by the way??) but then how do I enable verbose
logging while building world? I tried finding out the same by searching on
the internet and by reading the manual page for make.conf but couldn't
On 7 August 2017 at 00:32, Aijaz Baig wrote:
> That was some pretty relevant information Ed. Thanks.
Even though it's not a direct cause of the problem you encountered I
wanted to make sure a there was comprehensive reply to Dimitry's
question.
> Nonetheless, as I have indicated in my previous e
That was some pretty relevant information Ed. Thanks.
However upon bumping up my RAM, I don't hit this error anymore perhaps I
believe since the relatively large amount of RAM does not necessitate that
much of swap space.
Nonetheless, as I have indicated in my previous email, I hit an error quite
On 5 August 2017 at 16:16, Dimitry Andric wrote:
>
> I remember there being an issue with ar and/or ranlib choking when the
> .a files become too big. Ed, does that ring any bells?
Our ar (and ranlib, which is the same binary) will produce a corrupt
symbol table if the .a archive output is large
I did notice some swap related messages in dmesg earlier so this time I
bumped up my RAM to 4.25GB (did I tell you I'm running this on a VM?). In
addition I skipped parallel make jobs altogether keeping other things the
same.
So this time around it went a lot further in fact all the way to step4.3
Yes you could be correct. See my reply below to Dimitry.
And if this indeed is an issue is there a workaround? Or based on my first
question, do I really need to buildworld?
-- Forwarded message --
From: Aijaz Baig
Date: Sun, Aug 6, 2017 at 9:53 AM
Subject: Re: buildworld fails
Hello
Yes guilty as charged!!!
I turn off optimization and enable DEBUG_FLAGS using src.conf:
CFLAGS= -O0 -pipe
COPTFLAGS= -O0 -pipe
DEBUG_FLAGS=-g
This time however I run without any parallel make jobs and it fails with a
different error:
*** Signal 9
Stop.
make[6]: stopped in /usr/src/lib/c
Dimitry Andric dim at FreeBSD.org wrote on
Sat Aug 5 20:16:53 UTC 2017 :
> Hm, now I read that your obj dir is on NFS, you might be hitting some
> 4GiB filesize limit for the final .a file. Are you building world with
> a very low optimization level, and debug information on?
>
> I remember ther
On 5 Aug 2017, at 21:55, Aijaz Baig wrote:
>
> I was a bit sceptical of this as it was failing with that same port (or is
> clang a port by the way?) all the time. So as you suggested, I reduced my
> '-j' number and it still fails at the very same place with the very same
> error. Is it becaus
Hi Dmitry
I was a bit sceptical of this as it was failing with that same port (or is
clang a port by the way?) all the time. So as you suggested, I reduced my
'-j' number and it still fails at the very same place with the very same
error. Is it because the clang port doesn't allow parallel make jo
On 5 Aug 2017, at 06:00, Aijaz Baig wrote:
>
> I am trying to buildworld and it works well for quite some time until it
> tries to build the static version of the clang library where it fails. The
> error it spits is:
>
> Killed
> *** [all_subdir_lib/clang/libclang] Error code 137
>
> make[5]:
I am trying to buildworld and it works well for quite some time until it
tries to build the static version of the clang library where it fails. The
error it spits is:
Killed
*** [all_subdir_lib/clang/libclang] Error code 137
make[5]: stopped in /usr/src/lib/clang
1 error
make[5]: stopped in /usr
On 29 Jun 2017, at 19:16, Mark Millard wrote:
>
> On 2017-Jun-29, at 5:54 AM, Konstantin Belousov
> wrote:
>>
>> On Thu, Jun 29, 2017 at 12:47:10PM +0200, Dimitry Andric wrote:
>>> One nasty problem with this is that it is not possible to figure out at
>>> compile time what the size of time_t
[Good news from the llvm side of things. . .]
On 2017-Jun-29, at 3:47 AM, Dimitry Andric wrote:
> On 29 Jun 2017, at 12:04, Mark Millard wrote:
>>
>> [The libc++ code in question appears to not be ready for
>> 32-bit contexts with 64 bit times. Disable
>> experimental/filesystem for now? I've
On 2017-Jun-29, at 5:54 AM, Konstantin Belousov wrote:
>
> On Thu, Jun 29, 2017 at 12:47:10PM +0200, Dimitry Andric wrote:
>> One nasty problem with this is that it is not possible to figure out at
>> compile time what the size of time_t is. You always need some sort of
>> configure-time test, a
On Thu, Jun 29, 2017 at 12:47:10PM +0200, Dimitry Andric wrote:
> One nasty problem with this is that it is not possible to figure out at
> compile time what the size of time_t is. You always need some sort of
> configure-time test, and an external define.
It is arguably possible, with constexpr.
On 29 Jun 2017, at 12:04, Mark Millard wrote:
>
> [The libc++ code in question appears to not be ready for
> 32-bit contexts with 64 bit times. Disable
> experimental/filesystem for now? I've submitted
> llvm bugzilla 33638 for the issue and have
> added it to llvm's 25780, the FreeBSD META for
>
[The libc++ code in question appears to not be ready for
32-bit contexts with 64 bit times. Disable
experimental/filesystem for now? I've submitted
llvm bugzilla 33638 for the issue and have
added it to llvm's 25780, the FreeBSD META for
clang.]
On 2017-Jun-29, at 2:21 AM, Mark Millard wrote:
>
[TARGET_ARCH=powerpc64 fails similarly in its world32
part of its build.]
On 2017-Jun-29, at 1:33 AM, Mark Millard wrote:
> Beyond static_assert failures and overflow/underflow of long long
> it also it complains in some cases about:
>
> static_assert expression is not an integral constant expr
Beyond static_assert failures and overflow/underflow of long long
it also it complains in some cases about:
static_assert expression is not an integral constant expression
[I will note that attempting a gcc 4.2.1 build did not
stop and report such things for its libstdc++. The below
is somehow l
> On 24 Apr 2017, at 20:26, Brooks Davis wrote:
>
> On Mon, Apr 24, 2017 at 10:04:15AM -0700, Hamza Sheikh wrote:
>> The error is:
>>
>> --- all_subdir_usr.bin ---
>> cc1: warnings being treated as errors
>> /home/vagrant/src/usr.bin/diff/diffreg.c: In function 'change':
>> /home/vagrant/src/us
On Mon, Apr 24, 2017 at 10:04:15AM -0700, Hamza Sheikh wrote:
> The error is:
>
> --- all_subdir_usr.bin ---
> cc1: warnings being treated as errors
> /home/vagrant/src/usr.bin/diff/diffreg.c: In function 'change':
> /home/vagrant/src/usr.bin/diff/diffreg.c:1085: warning: 'i' may be
> used uniniti
I'm sorry for the double post. I got confused by the filtering as I
had not subscribed to the list when I sent the first post.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any
The error is:
--- all_subdir_usr.bin ---
cc1: warnings being treated as errors
/home/vagrant/src/usr.bin/diff/diffreg.c: In function 'change':
/home/vagrant/src/usr.bin/diff/diffreg.c:1085: warning: 'i' may be
used uninitialized in this function
--- all_subdir_share ---
--- ucred.9.gz ---
gzip -cn
The error is:
--- all_subdir_usr.bin ---
cc1: warnings being treated as errors
/home/vagrant/src/usr.bin/diff/diffreg.c: In function 'change':
/home/vagrant/src/usr.bin/diff/diffreg.c:1085: warning: 'i' may be
used uninitialized in this function
--- all_subdir_share ---
--- ucred.9.gz ---
gzip -cn
On Thursday 02 March 2017 22:40:05 Alex Deiter wrote:
> Hello,
Hello,
>
> Please apply patch from upstream:
>
> https://github.com/the-tcpdump-group/libpcap/pull/541
>
> Fix compilation if INET6 isn't defined.
> Addresses GitHub issue #541, but differently from the pull request (it
> defines
On Thu, Mar 2, 2017 at 11:40 AM, Alex Deiter wrote:
> Hello,
>
> Please apply patch from upstream:
>
> https://github.com/the-tcpdump-group/libpcap/pull/541
>
> Fix compilation if INET6 isn't defined.
> Addresses GitHub issue #541, but differently from the pull request (it
> defines gen_gateway()
Hello,
Please apply patch from upstream:
https://github.com/the-tcpdump-group/libpcap/pull/541
Fix compilation if INET6 isn't defined.
Addresses GitHub issue #541, but differently from the pull request (it
defines gen_gateway() with a function prototype rather than using a
pre-prototype-style de
> On Feb 17, 2017, at 13:09, Bryan Drewery wrote:
…
> Ignore me, my yacc is just outdated.
I’ll try again. This might have been part of my issue too.
Thanks!
-Ngie
signature.asc
Description: Message signed with OpenPGP using GPGMail
On 2/17/2017 1:03 PM, Bryan Drewery wrote:
> On 2/16/2017 10:07 AM, Ngie Cooper (yaneurabeya) wrote:
>>
>>> On Feb 16, 2017, at 07:30, Oleg V. Nauman wrote:
>>>
>>> cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -
>>> B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe -march=core2 -DHAV
On 2/16/2017 10:07 AM, Ngie Cooper (yaneurabeya) wrote:
>
>> On Feb 16, 2017, at 07:30, Oleg V. Nauman wrote:
>>
>> cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -
>> B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe -march=core2 -DHAVE_CONFIG_H -
>> I/usr/src/lib/libpcap -I/usr/obj/
> On Feb 16, 2017, at 07:30, Oleg V. Nauman wrote:
>
> cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -
> B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe -march=core2 -DHAVE_CONFIG_H -
> I/usr/src/lib/libpcap -I/usr/obj/usr/src/lib/libpcap -
> D_U_="__attribute__((unused))" -DHAVE_
On Thu, 16 Feb 2017 17:30:37 +0200 "Oleg V. Nauman"
wrote
> cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -
> B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe -march=core2 -DHAVE_CONFIG_H -
> I/usr/src/lib/libpcap -I/usr/obj/usr/src/lib/libpcap -
> D_U_="__attribute__((unused))" -DH
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -
B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe -march=core2 -DHAVE_CONFIG_H -
I/usr/src/lib/libpcap -I/usr/obj/usr/src/lib/libpcap -
D_U_="__attribute__((unused))" -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -
DBUILDING_PCAP -DHAVE_NET_PFVAR_H -I
On September 24, 2016 at 11:14:38 AM, O. Hartmann (ohart...@zedat.fu-berlin.de)
wrote:
Am Sat, 24 Sep 2016 10:33:26 -0700
Marcel Moolenaar schrieb:
> On September 24, 2016 at 10:26:44 AM, O. Hartmann
> (ohart...@zedat.fu-berlin.de) wrote:
>
> Recent sources of CURRENT (r306298) fail to
Am Sat, 24 Sep 2016 10:33:26 -0700
Marcel Moolenaar schrieb:
> On September 24, 2016 at 10:26:44 AM, O. Hartmann
> (ohart...@zedat.fu-berlin.de) wrote:
>
> Recent sources of CURRENT (r306298) fail to build while WITH OFED is
> selected:
> That’s me. Looking into it.
>
>
It has been resolve
On September 24, 2016 at 10:26:44 AM, O. Hartmann (ohart...@zedat.fu-berlin.de)
wrote:
Recent sources of CURRENT (r306298) fail to build while WITH OFED is selected:
That’s me. Looking into it.
signature.asc
Description: Message signed with OpenPGP using AMPGpg
Recent sources of CURRENT (r306298) fail to build while WITH OFED is selected:
[...]
building shared library libibsdp.so.1
--- lib__L ---
--- obj ---
--- obj_subdir_lib/clang/libllvmpowerpcinfo ---
===> lib/clang/libllvmpowerpcinfo (obj)
--- contrib/ofed/usr.lib__L ---
nm: 'log.pico': No such file
On Tue, Sep 06, 2016 at 05:11:11AM -0700, David Wolfskill wrote:
> ...
> Laptop got through "buildworld" Just Fine; re-trying on build machine.
> We may have a race.
>
OK; build machine succeeded on the second try. (Laptop did so the first
time).
As that at least raises the possibility of a
On Tue, Sep 06, 2016 at 04:36:18AM -0700, David Wolfskill wrote:
> Leading up to this; building on head/amd64 running:
> FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #96
> r305415M/305415:126: Mon Sep 5 04:35:16 PDT 2016
> r...@freebeast.catwhisker.org:/common/S4/o
Leading up to this; building on head/amd64 running:
FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #96
r305415M/305415:126: Mon Sep 5 04:35:16 PDT 2016
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64
...
--- gnu/lib/libgcc__L ---
Building /co
My first Bug report for FreeBSD! Please be gentle with me if it is not
done right!
Bug 209435 has been successfully created
Regards
Johan
Op 10/05/16 om 20:36 schreef Adrian Chadd:
> Hi,
>
> please file a bug and I'll go make sure we can run it without it
> running a script like this. should be
yup, landon already offered to do it.
-adrian
On 10 May 2016 at 11:47, Dimitry Andric wrote:
> On 10 May 2016, at 20:29, Johan Hendriks wrote:
>>
>> Op 10/05/16 om 19:47 schreef Dimitry Andric:
>>> On 10 May 2016, at 13:53, Johan Hendriks wrote:
My buildworld of current fails today wit
On 10 May 2016, at 20:29, Johan Hendriks wrote:
>
> Op 10/05/16 om 19:47 schreef Dimitry Andric:
>> On 10 May 2016, at 13:53, Johan Hendriks wrote:
>>> My buildworld of current fails today with the following error message.
>>> This is FreeBSD desk.server.netaffairs.nl 11.0-CURRENT FreeBSD
>>> 11
Hi,
please file a bug and I'll go make sure we can run it without it
running a script like this. should be easy to do.
-a
On 10 May 2016 at 11:29, Johan Hendriks wrote:
>
>
> Op 10/05/16 om 19:47 schreef Dimitry Andric:
>> On 10 May 2016, at 13:53, Johan Hendriks wrote:
>>> My buildworld of
Op 10/05/16 om 19:47 schreef Dimitry Andric:
> On 10 May 2016, at 13:53, Johan Hendriks wrote:
>> My buildworld of current fails today with the following error message.
>> This is FreeBSD desk.server.netaffairs.nl 11.0-CURRENT FreeBSD
>> 11.0-CURRENT #8 r299158:
> ...
>> ===> bhnd (all)
>> machi
On 10 May 2016, at 13:53, Johan Hendriks wrote:
>
> My buildworld of current fails today with the following error message.
> This is FreeBSD desk.server.netaffairs.nl 11.0-CURRENT FreeBSD
> 11.0-CURRENT #8 r299158:
...
> ===> bhnd (all)
> machine -> /usr/src/sys/amd64/include
> x86 -> /usr/src/sy
That's odd; it doesn't happen here.. can you run that script manually?
On 10 May 2016 at 04:53, Johan Hendriks wrote:
> My buildworld of current fails today with the following error message.
> This is FreeBSD desk.server.netaffairs.nl 11.0-CURRENT FreeBSD
> 11.0-CURRENT #8 r299158:
>
> cc -O2 -
My buildworld of current fails today with the following error message.
This is FreeBSD desk.server.netaffairs.nl 11.0-CURRENT FreeBSD
11.0-CURRENT #8 r299158:
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
-nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include
/usr/obj/usr/src/sys/K
Warner broke sys/boot somehow.. Jenkins concurs.
> On Aug 27, 2015, at 23:41, O. Hartmann wrote:
>
> Recent CURRENT sources fail to buildworld:
>
> [...]
> --- util.o ---
> cc -DBOOTPROG=\"gptboot\" -O1 -DGPT -DUFS1_AND_UFS2 -DSIOPRT=0x3f8
> -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/bo
Recent CURRENT sources fail to buildworld:
[...]
--- util.o ---
cc -DBOOTPROG=\"gptboot\" -O1 -DGPT -DUFS1_AND_UFS2 -DSIOPRT=0x3f8
-DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/gptboot/../../common
-I/usr/src/sys/boot/i386/gptboot/../common
-I/usr/src/sys/boot/i386/gptboot/../btx/lib
> I fixed 2/3 of the issues in the following commits:
> 1. https://svnweb.freebsd.org/changeset/base/276319
> 3. https://svnweb.freebsd.org/changeset/base/276318
Thanks for the e-mail Garret. Before I proceed to file PR, I'd like some input
as to what to do about these problems which I had mentio
On Dec 24, 2014, at 1:45, Beeblebrox wrote:
> I plan on using openssl from ports and have no need for kerberos.
> /etc/src.conf >> WITHOUT_CRYPT= yes
>
> * First problem is with bsnmp (used WITHOUT_BSNMP to bypass)
> ===> lib/libbsnmp/libbsnmp (all)
> cc -O2 -pipe
> -I/asp/git/src/lib/libbs
So far from what I can tell, two modules don't get built for some reason.
* sys/boot/i386/boot2
I built and installed this manually:
* usr/sbin/mtree
This is missing, and usr.sbin/mtree gives fmtree. Trying
from contrib/mtree results in:
/usr/local/libexec/ccache/world/clang -O2 -pipe -DNDEBUG
On Wed, Dec 24, 2014 at 04:33:19PM +0200, Beeblebrox wrote:
> * So as to keep the build going, I commented out ctld in the usr.sbin/Makefile
>
> * The next part to break was pkg. I set WITHOUT_PKGTOOLS, but that did
> not solve the problem, so I once more had to comment out in
> usr.sbin/Makef
On Wed, Dec 24, 2014 at 02:47:57PM +0200, Beeblebrox wrote:
> I patched Herbert's code, deleted the entire partial world and have
> WITHOUT_CRYPT, WITHOUT_BSNMP in src.conf.
Too many parts require openssl (libfetch, bsdinstall/distfetch?, pkg, dma, etc.)
some of them can be disabled with knobs but
* So as to keep the build going, I commented out ctld in the usr.sbin/Makefile
* The next part to break was pkg. I set WITHOUT_PKGTOOLS, but that did
not solve the problem, so I once more had to comment out in
usr.sbin/Makefile "SUBDIR+= pkg"
===> usr.sbin/pkg (all)
cc -O2 -pipe -I/asp/git/
I patched Herbert's code, deleted the entire partial world and have
WITHOUT_CRYPT, WITHOUT_BSNMP in src.conf.
First this part below broke, but managed to move forward when I disabled ccache
(clipped for brevity):
===> rescue/rescue/chown/tests (depend)
(cd /asp/git/src/usr.sbin/chown/tests && ma
> Instead of using WITHOUT_CRYPT, you could have used WITHOUT_KERBEROS.
I know that, but I don't want to waste time compiling openssl either.
> You can still install openssl from ports.
Thanks. As stated it's just a matter of not wanting to compile something I'm
not going to use.
> What's wrong
On Wed, Dec 24, 2014 at 11:45:04AM +0200, Beeblebrox wrote:
> I plan on using openssl from ports and have no need for kerberos.
> /etc/src.conf >> WITHOUT_CRYPT= yes
>
> * First problem is with bsnmp (used WITHOUT_BSNMP to bypass)
> ===> lib/libbsnmp/libbsnmp (all)
> cc -O2 -pipe
> -I/asp/git
On Wed, Dec 24, 2014 at 3:45 AM, Beeblebrox wrote:
> I plan on using openssl from ports and have no need for kerberos.
> /etc/src.conf >> WITHOUT_CRYPT= yes
>
Instead of using WITHOUT_CRYPT, you could have used WITHOUT_KERBEROS.
>
> * I would prefer being able to use SSH from world (instead of dr
On Wed, Dec 24, 2014 at 11:45:04AM +0200, Beeblebrox wrote:
> I plan on using openssl from ports and have no need for kerberos.
> /etc/src.conf >> WITHOUT_CRYPT= yes
>
> * First problem is with bsnmp (used WITHOUT_BSNMP to bypass)
> ===> lib/libbsnmp/libbsnmp (all)
> cc -O2 -pipe
> -I/asp/git
I plan on using openssl from ports and have no need for kerberos.
/etc/src.conf >> WITHOUT_CRYPT= yes
* First problem is with bsnmp (used WITHOUT_BSNMP to bypass)
===> lib/libbsnmp/libbsnmp (all)
cc -O2 -pipe
-I/asp/git/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib -DHAVE_ERR_H
-DHAVE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
So the ztest link fails looking for spa_maxblocksize, which
is defined in
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c
I don't see which lib it is included in. One of zpool, zfs,
or zfs_core, apparently.
As my build system is root on zf
Am Sun, 5 Oct 2014 15:20:20 -0700
Mark Johnston schrieb:
> On Sun, Oct 05, 2014 at 11:18:55AM +0200, O. Hartmann wrote:
> > Am Sun, 5 Oct 2014 05:36:57 +0400
> > Arseny Nasokin schrieb:
> >
> > > Mark,
> > >
> > > Thank you for patch, I encounter same error and this patch works for me.
> > >
On Sun, Oct 05, 2014 at 11:18:55AM +0200, O. Hartmann wrote:
> Am Sun, 5 Oct 2014 05:36:57 +0400
> Arseny Nasokin schrieb:
>
> > Mark,
> >
> > Thank you for patch, I encounter same error and this patch works for me.
> >
> > ✪
> >
> >
> > -- Eir Nym
> >
> > On 5 October 2014 04:43, Mark Johns
2014-10-05 11:37 GMT+02:00 Arseny Nasokin :
> Waiting for patch in -CURRENT.
>
> -- Eir Nym
>
> This patch work in r272559 for me: http://pastebin.com/2QJRYjCK
Regards
Maurizio
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailma
Waiting for patch in -CURRENT.
-- Eir Nym
On 5 October 2014 13:18, O. Hartmann wrote:
> Am Sun, 5 Oct 2014 05:36:57 +0400
> Arseny Nasokin schrieb:
>
> > Mark,
> >
> > Thank you for patch, I encounter same error and this patch works for me.
> >
> > ✪
> >
> >
> > -- Eir Nym
> >
> > On 5 October
Am Sun, 5 Oct 2014 05:36:57 +0400
Arseny Nasokin schrieb:
> Mark,
>
> Thank you for patch, I encounter same error and this patch works for me.
>
> ✪
>
>
> -- Eir Nym
>
> On 5 October 2014 04:43, Mark Johnston wrote:
>
> > On Sat, Oct 04, 2014 at 04:41:07PM -0700, Russell L. Carter wrote:
>
Am Sat, 4 Oct 2014 15:58:48 -0700
Mark Johnston schrieb:
> On Sat, Oct 4, 2014 at 3:40 PM, Mark Johnston wrote:
> > On Sat, Oct 04, 2014 at 04:39:37PM -0400, Ryan Stone wrote:
> >> On Sat, Oct 4, 2014 at 2:33 PM, Mark Johnston wrote:
> >> > On Sat, Oct 04, 2014 at 07:47:56PM +0200, O. Hartmann
Mark,
Thank you for patch, I encounter same error and this patch works for me.
✪
-- Eir Nym
On 5 October 2014 04:43, Mark Johnston wrote:
> On Sat, Oct 04, 2014 at 04:41:07PM -0700, Russell L. Carter wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> >
> >
> > On 10/04/14 15:
On Sat, Oct 04, 2014 at 04:41:07PM -0700, Russell L. Carter wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> On 10/04/14 15:58, Mark Johnston wrote:
> > On Sat, Oct 4, 2014 at 3:40 PM, Mark Johnston
> > wrote:
> >> On Sat, Oct 04, 2014 at 04:39:37PM -0400, Ryan Stone wrote:
> >>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/04/14 15:58, Mark Johnston wrote:
> On Sat, Oct 4, 2014 at 3:40 PM, Mark Johnston
> wrote:
>> On Sat, Oct 04, 2014 at 04:39:37PM -0400, Ryan Stone wrote:
>>> On Sat, Oct 4, 2014 at 2:33 PM, Mark Johnston
>>> wrote:
On Sat, Oct 04, 2014 a
On Sat, Oct 4, 2014 at 3:40 PM, Mark Johnston wrote:
> On Sat, Oct 04, 2014 at 04:39:37PM -0400, Ryan Stone wrote:
>> On Sat, Oct 4, 2014 at 2:33 PM, Mark Johnston wrote:
>> > On Sat, Oct 04, 2014 at 07:47:56PM +0200, O. Hartmann wrote:
>> >> Recent sources (Revision: 272529) fail to compile:
>>
On Sat, Oct 04, 2014 at 04:39:37PM -0400, Ryan Stone wrote:
> On Sat, Oct 4, 2014 at 2:33 PM, Mark Johnston wrote:
> > On Sat, Oct 04, 2014 at 07:47:56PM +0200, O. Hartmann wrote:
> >> Recent sources (Revision: 272529) fail to compile:
> >>
> >> [...]
> >> cc -m32 -march=native -DCOMPAT_32BIT -is
1 - 100 of 402 matches
Mail list logo
