Re: Buildworld fails with external GCC toolchain

2022-02-15 Thread Yasuhiro Kimura
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.
>> 
>> It is work to keep it working though and I hadn't worked on it again
>> until recently.
> 
> Thanks for letting me know. I tried patch of the review and confirmed
> both buildworld and buildkernel succeed with GCC 9 and binutils 2.37.
> So I reached start point now and can test binutils 2.38.

I tried buildworld and buildkernel with binutils 2.38 and they
completed successfully.

Just FYI.

---
Yasuhiro Kimura



Re: Buildworld fails with external GCC toolchain

2022-02-14 Thread Yasuhiro Kimura
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-amd64-gcc9_build/
>>>
>>> The last build(s) show a different error from yours, though:
>>>
>>> /workspace/src/tests/sys/netinet/libalias/util.c: In function
>>> 'set_udp':
>>> /workspace/src/tests/sys/netinet/libalias/util.c:112:2: error:
>>> converting a packed 'struct ip' pointer (alignment 2) to a 'uint32_t'
>>> {aka 'unsigned int'} pointer (alignment 4) may result in an unaligned
>>> pointer value [-Werror=address-of-packed-member]
>>>112 |  uint32_t *up = (void *)p;
>>>|  ^~~~
>>> In file included from
>>> /workspace/src/tests/sys/netinet/libalias/util.h:37,
>>>   from /workspace/src/tests/sys/netinet/libalias/util.c:39:
>>> /workspace/src/sys/netinet/ip.h:51:8: note: defined here
>>> 51 | struct ip {
>>>|^~
>>>
>>> -Dimitry
>>>
>> Thanks for information. I went back the commit history of main branch
>> about every month and check if buildworld succeeds with GCC. But it
>> didn't succeed even if I went back about a year. And devel/binutils
>> port was update to 2.37 on last August. So I suspect external GCC
>> toolchain doesn't work well after binutils is updated to current
>> version.
> 
> I have amd64 world + kernel building with GCC 9 and the only remaining
> open review not merged yet is https://reviews.freebsd.org/D34147.
> 
> It is work to keep it working though and I hadn't worked on it again
> until recently.

Thanks for letting me know. I tried patch of the review and confirmed
both buildworld and buildkernel succeed with GCC 9 and binutils 2.37.
So I reached start point now and can test binutils 2.38.

---
Yasuhiro Kimura



Re: Buildworld fails with external GCC toolchain

2022-02-14 Thread John Baldwin

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-gcc9_build/

The last build(s) show a different error from yours, though:

/workspace/src/tests/sys/netinet/libalias/util.c: In function 'set_udp':
/workspace/src/tests/sys/netinet/libalias/util.c:112:2: error: converting a 
packed 'struct ip' pointer (alignment 2) to a 'uint32_t' {aka 'unsigned int'} 
pointer (alignment 4) may result in an unaligned pointer value 
[-Werror=address-of-packed-member]
   112 |  uint32_t *up = (void *)p;
   |  ^~~~
In file included from /workspace/src/tests/sys/netinet/libalias/util.h:37,
  from /workspace/src/tests/sys/netinet/libalias/util.c:39:
/workspace/src/sys/netinet/ip.h:51:8: note: defined here
51 | struct ip {
   |^~

-Dimitry



Thanks for information. I went back the commit history of main branch
about every month and check if buildworld succeeds with GCC. But it
didn't succeed even if I went back about a year. And devel/binutils
port was update to 2.37 on last August. So I suspect external GCC
toolchain doesn't work well after binutils is updated to current
version.


I have amd64 world + kernel building with GCC 9 and the only remaining
open review not merged yet is https://reviews.freebsd.org/D34147.

It is work to keep it working though and I hadn't worked on it again
until recently.

--
John Baldwin



Re: Buildworld fails with external GCC toolchain

2022-02-12 Thread Yasuhiro Kimura
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 build(s) show a different error from yours, though:
> 
> /workspace/src/tests/sys/netinet/libalias/util.c: In function 'set_udp':
> /workspace/src/tests/sys/netinet/libalias/util.c:112:2: error: converting a 
> packed 'struct ip' pointer (alignment 2) to a 'uint32_t' {aka 'unsigned int'} 
> pointer (alignment 4) may result in an unaligned pointer value 
> [-Werror=address-of-packed-member]
>   112 |  uint32_t *up = (void *)p;
>   |  ^~~~
> In file included from /workspace/src/tests/sys/netinet/libalias/util.h:37,
>  from /workspace/src/tests/sys/netinet/libalias/util.c:39:
> /workspace/src/sys/netinet/ip.h:51:8: note: defined here
>51 | struct ip {
>   |^~
> 
> -Dimitry
> 

Thanks for information. I went back the commit history of main branch
about every month and check if buildworld succeeds with GCC. But it
didn't succeed even if I went back about a year. And devel/binutils
port was update to 2.37 on last August. So I suspect external GCC
toolchain doesn't work well after binutils is updated to current
version.

---
Yasuhiro Kimura



Re: Buildworld fails with external GCC toolchain

2022-02-11 Thread Dimitry Andric
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 to do it with binutils 2.38 before
> updating the port. And as a preparation for it, I tried building base
> system with current external GCC toolchain (that is, with binutils
> 2.37.1).
> 
> At first I read following wiki pages.
> 
> https://wiki.freebsd.org/ExternalToolchain
> https://wiki.freebsd.org/ExternalGCC
> 
> Next I took following steps.
> 
> 1. Make clean install of 14-CURRENT amd64 with the install image of
>   20220210 snapshot.
> 2. Checkout latest main of src repository (d4b0fa45dc1 at that time).
> 3. pkg install amd64-gcc9
> 4. cd /usr/src
> 5. make -j 4 CROSS_TOOLCHAIN=amd64-gcc9 buildworld buildkernel
> 
> Then step 5 failed as following.
> 
> --
> --- all_subdir_rescue ---
> /usr/local/bin/x86_64-unknown-freebsd14.0-ld: nc.lo: in function `_$$hide$$ 
> nc.lo main':
> (.text.startup+0xd42): warning: warning: mktemp() possibly used unsafely; 
> consider using mkstemp()
> /usr/local/bin/x86_64-unknown-freebsd14.0-ld: 
> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_set_term.o): 
> in function `_nc_setupscreen_sp':
> /usr/src/contrib/ncurses/ncurses/base/lib_set_term.c:415: undefined reference 
> to `_nc_set_buffer_sp'
> /usr/local/bin/x86_64-unknown-freebsd14.0-ld: 
> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_tstp.o): in 
> function `handle_SIGTSTP':
> /usr/src/contrib/ncurses/ncurses/tty/lib_tstp.c:222: undefined reference to 
> `flushinp_sp'
> /usr/local/bin/x86_64-unknown-freebsd14.0-ld: 
> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_getch.o): in 
> function `check_mouse_activity':
> /usr/src/contrib/ncurses/ncurses/base/lib_getch.c:188: undefined reference to 
> `_nc_timed_wait'
> /usr/local/bin/x86_64-unknown-freebsd14.0-ld: 
> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_getstr.o): in 
> function `wgetnstr':
> /usr/src/contrib/ncurses/ncurses/base/lib_getstr.c:106: undefined reference 
> to `erasechar_sp'
> /usr/local/bin/x86_64-unknown-freebsd14.0-ld: 
> /usr/src/contrib/ncurses/ncurses/base/lib_getstr.c:107: undefined reference 
> to `killchar_sp'
> collect2: error: ld returned 1 exit status
> *** [rescue] Error code 1
> 
> make[5]: stopped in /usr/obj/usr/src/amd64.amd64/rescue/rescue
> --- all_subdir_stand ---
> 
> make[2]: stopped in /usr/src
> --- all_subdir_share ---
> 
> make[2]: stopped in /usr/src
> --- all_subdir_rescue ---
> 1 error
> 
> make[5]: stopped in /usr/obj/usr/src/amd64.amd64/rescue/rescue
> *** [rescue] Error code 2
> 
> make[4]: stopped in /usr/src/rescue/rescue
> 1 error
> 
> make[4]: stopped in /usr/src/rescue/rescue
> 
> make[3]: stopped in /usr/src/rescue
> 
> make[2]: stopped in /usr/src
> --- all_subdir_lib ---
> 
> make[2]: stopped in /usr/src
>  167.49 real   492.07 user94.42 sys
> 
> make[1]: stopped in /usr/src
> 
> make: stopped in /usr/src
> --
> 
> If I check commit messages of main branch over the last few months, I
> can find some commits that fix warning message displayed by GCC. So
> currently external GCC toolchain seems to work fine. Then what is the
> cause of my build failure? Did I do something wrong?

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 build(s) show a different error from yours, though:

/workspace/src/tests/sys/netinet/libalias/util.c: In function 'set_udp':
/workspace/src/tests/sys/netinet/libalias/util.c:112:2: error: converting a 
packed 'struct ip' pointer (alignment 2) to a 'uint32_t' {aka 'unsigned int'} 
pointer (alignment 4) may result in an unaligned pointer value 
[-Werror=address-of-packed-member]
  112 |  uint32_t *up = (void *)p;
  |  ^~~~
In file included from /workspace/src/tests/sys/netinet/libalias/util.h:37,
 from /workspace/src/tests/sys/netinet/libalias/util.c:39:
/workspace/src/sys/netinet/ip.h:51:8: note: defined here
   51 | struct ip {
  |^~

-Dimitry



signature.asc
Description: Message signed with OpenPGP


Re: buildworld fails ( stopped in /usr/src/lib/libsysdecode )

2020-11-30 Thread Johan Hendriks



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


Thank you for the conformation.
And thank you all for your work on FreeBSD.

regards
Johan



Fixed in r368187. Sorry for troubles.
Michal



Thank you, no problem and no need for a sorry!

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


Re: buildworld fails ( stopped in /usr/src/lib/libsysdecode )

2020-11-30 Thread Michal Meloun




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 it errors out with the following message.


This is a known issue and will be fixed.

--HPS


Thank you for the conformation.
And thank you all for your work on FreeBSD.

regards
Johan



Fixed in r368187. Sorry for troubles.
Michal

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


Re: buildworld fails ( stopped in /usr/src/lib/libsysdecode )

2020-11-30 Thread Johan Hendriks



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.


This is a known issue and will be fixed.

--HPS


Thank you for the conformation.
And thank you all for your work on FreeBSD.

regards
Johan

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


Re: buildworld fails ( stopped in /usr/src/lib/libsysdecode )

2020-11-30 Thread Hans Petter Selasky

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

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


Re: buildworld fails: fatal error: 'netpfil/pf/pf.h' file not found

2018-04-11 Thread Vladimir Zakharov
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 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/tests/sys/netpfil/pf/ioctl/Makefile
> > > _RECURSING_PROGS=t PROG=validation )
> > > Building
> > > /home/obj/usr/src/amd64.amd64/tests/sys/netpfil/pf/ioctl/
> > > validation.o
> > > --- validation.o ---
> > > In file included from
> > > /usr/src/tests/sys/netpfil/pf/ioctl/validation.c:35:
> > > /home/obj/usr/src/amd64.amd64/tmp/usr/include/net/pfvar.h:49:10:
> > > fatal
> > > error: 'netpfil/pf/pf.h' file not found
> > > #include 
> > > ^
> 
> It should be fully fixed as of r332358.
> Thanks for the report.

Works for me. Thanks.

-- 
Regards, | "In theory there is no difference between theory
  Vladimir Zakharov  | and practice. In practice there is."- Yogi Berra
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: buildworld fails: fatal error: 'netpfil/pf/pf.h' file not found

2018-04-10 Thread Kristof Provost

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/netpfil/pf/ioctl (all)
--- validation ---
(cd /usr/src/tests/sys/netpfil/pf/ioctl && 
DEPENDFILE=.depend.validation

NO_SUBDIR=1 make -f /usr/src/tests/sys/netpfil/pf/ioctl/Makefile
_RECURSING_PROGS=t PROG=validation )
Building 
/home/obj/usr/src/amd64.amd64/tests/sys/netpfil/pf/ioctl/

validation.o
--- validation.o ---
In file included from 
/usr/src/tests/sys/netpfil/pf/ioctl/validation.c:35:
/home/obj/usr/src/amd64.amd64/tmp/usr/include/net/pfvar.h:49:10: 
fatal

error: 'netpfil/pf/pf.h' file not found
#include 
^


It should be fully fixed as of r332358.
Thanks for the report.

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


Re: buildworld fails: fatal error: 'netpfil/pf/pf.h' file not found

2018-04-09 Thread Vladimir Zakharov
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/ioctl (all)
> --- validation ---
> (cd /usr/src/tests/sys/netpfil/pf/ioctl && DEPENDFILE=.depend.validation
> NO_SUBDIR=1 make -f /usr/src/tests/sys/netpfil/pf/ioctl/Makefile
> _RECURSING_PROGS=t PROG=validation )
> Building /home/obj/usr/src/amd64.amd64/tests/sys/netpfil/pf/ioctl/
> validation.o
> --- validation.o ---
> In file included from /usr/src/tests/sys/netpfil/pf/ioctl/validation.c:35:
> /home/obj/usr/src/amd64.amd64/tmp/usr/include/net/pfvar.h:49:10: fatal
> error: 'netpfil/pf/pf.h' file not found
> #include 
> ^
> 1 error generated.
> *** [validation.o] Error code 1
> 
> make[8]: stopped in /usr/src/tests/sys/netpfil/pf/ioctl
> 
> 
> My /etc/src.conf (I have PF switched off):
> 
> Ah, that’s my fault. I didn’t consider people who’d switch off pf when I added
> the new ioctl tests.
> 
> You can work around the issue by removing the new tests yourself, or by
> building pf in anyway (it won’t do anything unless you load the module and
> activate it).
> 
> This should be a workaround for you until I can commit a better fix:
> 
> diff --git a/tests/sys/netpfil/pf/Makefile b/tests/sys/netpfil/pf/Makefile
> index c055e6840bd..259e1275d9c 100644
> --- a/tests/sys/netpfil/pf/Makefile
> +++ b/tests/sys/netpfil/pf/Makefile
> @@ -3,7 +3,6 @@
>  PACKAGE=   tests
> 
>  TESTSDIR=   ${TESTSBASE}/sys/netpfil/pf
> -TESTS_SUBDIRS+=ioctl
> 
>  ATF_TESTS_SH+= pass_block \
> forward \

Thanks. I've applied this fix for now and managed to update.


-- 
Regards, | "In theory there is no difference between theory
  Vladimir Zakharov  | and practice. In practice there is."- Yogi Berra
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: buildworld fails: fatal error: 'netpfil/pf/pf.h' file not found

2018-04-09 Thread Kristof Provost

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=.depend.validation  NO_SUBDIR=1 make -f 
/usr/src/tests/sys/netpfil/pf/ioctl/Makefile _RECURSING_PROGS=t  
PROG=validation )
Building 
/home/obj/usr/src/amd64.amd64/tests/sys/netpfil/pf/ioctl/validation.o

--- validation.o ---
In file included from 
/usr/src/tests/sys/netpfil/pf/ioctl/validation.c:35:
/home/obj/usr/src/amd64.amd64/tmp/usr/include/net/pfvar.h:49:10: fatal 
error: 'netpfil/pf/pf.h' file not found

#include 
 ^
1 error generated.
*** [validation.o] Error code 1

make[8]: stopped in /usr/src/tests/sys/netpfil/pf/ioctl


My /etc/src.conf (I have PF switched off):


Ah, that’s my fault. I didn’t consider people who’d switch off pf 
when I added the new ioctl tests.


You can work around the issue by removing the new tests yourself, or by 
building pf in anyway (it won’t do anything unless you load the module 
and activate it).


This should be a workaround for you until I can commit a better fix:

	diff --git a/tests/sys/netpfil/pf/Makefile 
b/tests/sys/netpfil/pf/Makefile

index c055e6840bd..259e1275d9c 100644
--- a/tests/sys/netpfil/pf/Makefile
+++ b/tests/sys/netpfil/pf/Makefile
@@ -3,7 +3,6 @@
 PACKAGE=   tests

 TESTSDIR=   ${TESTSBASE}/sys/netpfil/pf
-TESTS_SUBDIRS+=ioctl

 ATF_TESTS_SH+= pass_block \
forward \

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


Re: buildworld fails while building static clang library

2017-08-14 Thread Aijaz Baig
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
figure it out

Is it even possible to have a verbose output?

On Mon, Aug 14, 2017 at 7:36 PM, Ed Maste  wrote:

> 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 email, I hit an error
> quite
> > late in the process now (stage 4.3) when it is apparently linking
> h_raw.o
> > into h_raw.full ( is this linking by the way? what is the .full file
> > there??)
>
> Yes, this is a link step - the .full file is a binary or library with
> debug data included, which is then split into a .debug file containing
> only the debug data and the binary or library with no extension.
>
> There's no indication of what the error is in your log excerpt; are
> there any messages in dmesg from the time of the build?
>



-- 

Best Regards,
Aijaz Baig
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: buildworld fails while building static clang library

2017-08-14 Thread Ed Maste
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 email, I hit an error quite
> late in the process now (stage 4.3) when it is apparently linking  h_raw.o
> into h_raw.full ( is this linking by the way? what is the .full file
> there??)

Yes, this is a link step - the .full file is a binary or library with
debug data included, which is then split into a .debug file containing
only the debug data and the binary or library with no extension.

There's no indication of what the error is in your log excerpt; are
there any messages in dmesg from the time of the build?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: buildworld fails while building static clang library

2017-08-06 Thread Aijaz Baig
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
late in the process now (stage 4.3) when it is apparently linking  h_raw.o
into h_raw.full ( is this linking by the way? what is the .full file
there??)

Keen to hear

On Sun, Aug 6, 2017 at 3:04 PM, Ed Maste  wrote:

> 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 larger than 4GB, because we
> support only 32-bit offsets in the older "/" symbol table format, not
> the "/SYM64/" format and 64-bit offsets.
>
> As with GNU ar from binutils 2.17.50 we silently truncate if the
> offset does not fit in 32 bits. I'll have a patch for review soon to
> exit on error rather than produce corrupted output, and hope to look
> at adding /SYM64/ support later on.
>



-- 

Best Regards,
Aijaz Baig
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: buildworld fails while building static clang library

2017-08-06 Thread Ed Maste
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 larger than 4GB, because we
support only 32-bit offsets in the older "/" symbol table format, not
the "/SYM64/" format and 64-bit offsets.

As with GNU ar from binutils 2.17.50 we silently truncate if the
offset does not fit in 32 bits. I'll have a patch for review soon to
exit on error rather than produce corrupted output, and hope to look
at adding /SYM64/ support later on.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: buildworld fails while building static clang library

2017-08-06 Thread Aijaz Baig
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
(building everything)

and now it fails at this step:

===> lib/libc/tests/ssp (all)
(cd /usr/src/lib/libc/tests/ssp &&  DEPENDFILE=.depend.h_fgets  NO_SUBDIR=1
make -f /usr/src/lib/libc/tests/ssp/Makefile _RECURSING
_PROGS=t  PROG=h_fgets )
(cd /usr/src/lib/libc/tests/ssp &&  DEPENDFILE=.depend.h_gets  NO_SUBDIR=1
make -f /usr/src/lib/libc/tests/ssp/Makefile _RECURSING_
PROGS=t  PROG=h_gets )
(cd /usr/src/lib/libc/tests/ssp &&  DEPENDFILE=.depend.h_getcwd
 NO_SUBDIR=1 make -f /usr/src/lib/libc/tests/ssp/Makefile _RECURSIN
G_PROGS=t  PROG=h_getcwd )
(cd /usr/src/lib/libc/tests/ssp &&  DEPENDFILE=.depend.h_memcpy
 NO_SUBDIR=1 make -f /usr/src/lib/libc/tests/ssp/Makefile _RECURSIN
G_PROGS=t  PROG=h_memcpy )
(cd /usr/src/lib/libc/tests/ssp &&  DEPENDFILE=.depend.h_memmove
 NO_SUBDIR=1 make -f /usr/src/lib/libc/tests/ssp/Makefile _RECURSI
NG_PROGS=t  PROG=h_memmove )
(cd /usr/src/lib/libc/tests/ssp &&  DEPENDFILE=.depend.h_memset
 NO_SUBDIR=1 make -f /usr/src/lib/libc/tests/ssp/Makefile _RECURSIN
G_PROGS=t  PROG=h_memset )
(cd /usr/src/lib/libc/tests/ssp &&  DEPENDFILE=.depend.h_raw  NO_SUBDIR=1
make -f /usr/src/lib/libc/tests/ssp/Makefile _RECURSING_PROGS=t  PROG=h_raw
)
cc -target x86_64-unknown-freebsd12.0 --sysroot=/mnt/obj/usr/src/tmp
-B/mnt/obj/usr/src/tmp/usr/bin -O0 -pipe -march=core2 -fstack-protector-all
-Wstack-protector -fsanitize=bounds -g3 -g -std=gnu99
-fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k
-Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion
-Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch
-Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments  -o
h_raw.full h_raw.o
*** Error code 1

Stop.
make[7]: stopped in /usr/src/lib/libc/tests/ssp
*** Error code 1

Stop.
make[6]: stopped in /usr/src/lib/libc/tests/ssp
*** Error code 1

Stop.
make[5]: stopped in /usr/src/lib/libc/tests
*** Error code 1

Stop.
make[4]: stopped in /usr/src/lib/libc
*** Error code 1

Stop.
make[3]: stopped in /usr/src/lib
*** Error code 1

Stop.
make[2]: stopped in /usr/src
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src

keen to hear

On Sun, Aug 6, 2017 at 9:53 AM, Aijaz Baig  wrote:

> 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/clang/libclang
> *** Error code 1
>
> Stop.
> make[5]: stopped in /usr/src/lib/clang
> *** Error code 1
>
> Stop.
> make[4]: stopped in /usr/src/lib
> *** Error code 1
>
> Stop.
> make[3]: stopped in /usr/src
> *** Error code 1
>
> Stop.
> make[2]: stopped in /usr/src
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/src
> *** Error code 1
>
> Stop.
> make: stopped in /usr/src
>
> Keen to hear
>
> On Sun, Aug 6, 2017 at 1:46 AM, Dimitry Andric  wrote:
>
>> 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 because the clang port doesn't allow parallel make jobs?
>> >
>> > Nonetheless, as to my query regarding building the world, based on what
>> my goals are (as I stated earlier), does it require me to actually build
>> the whole world?
>> >
>> > Regards,
>> > Aijaz Baig
>> >
>> > On Sat, Aug 5, 2017 at 2:34 PM, Dimitry Andric  wrote:
>> > 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]: stopped in /usr/src/lib/clang
>> >
>> > I'm just guessing, but the most likely cause is lack of memory.  Please
>> > check dmesg for any messages like "pid foo (bar), uid baz, was killed:
>> > out of swap space".  To work around this, you can temporarily add more
>> > swap space, or lower your -j level.
>>
>> 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 

Re: buildworld fails while building static clang library

2017-08-05 Thread Aijaz Baig
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/clang/libclang
*** Error code 1

Stop.
make[5]: stopped in /usr/src/lib/clang
*** Error code 1

Stop.
make[4]: stopped in /usr/src/lib
*** Error code 1

Stop.
make[3]: stopped in /usr/src
*** Error code 1

Stop.
make[2]: stopped in /usr/src
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src

Keen to hear

On Sun, Aug 6, 2017 at 1:46 AM, Dimitry Andric  wrote:

> 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 because the clang port doesn't allow parallel make jobs?
> >
> > Nonetheless, as to my query regarding building the world, based on what
> my goals are (as I stated earlier), does it require me to actually build
> the whole world?
> >
> > Regards,
> > Aijaz Baig
> >
> > On Sat, Aug 5, 2017 at 2:34 PM, Dimitry Andric  wrote:
> > 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]: stopped in /usr/src/lib/clang
> >
> > I'm just guessing, but the most likely cause is lack of memory.  Please
> > check dmesg for any messages like "pid foo (bar), uid baz, was killed:
> > out of swap space".  To work around this, you can temporarily add more
> > swap space, or lower your -j level.
>
> 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 there being an issue with ar and/or ranlib choking when the
> .a files become too big.  Ed, does that ring any bells?
>
> -Dimitry
>
>


-- 

Best Regards,
Aijaz Baig
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: buildworld fails while building static clang library

2017-08-05 Thread Mark Millard
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 there being an issue with ar and/or ranlib choking when the
> .a files become too big.  Ed, does that ring any bells?

For an example of this for libWebCore.a and ar see bugzilla 206679 .

Quoting part of comment 2:


. . .
I would have guessed that the file format has some 4GB limit that might have 
been reached, explaining why the terminology reads like a file truncation 
instead of out-of-memory.

Looking around some I found one 2012 reference to code in ar that was reported 
to then look like:

  /* Catch an attempt to grow an archive past its 4Gb limit.  */
  if (archive_member_file_ptr != (file_ptr) offset)
{
  bfd_set_error (bfd_error_file_truncated);
  return FALSE;
}
. . .

===
Mark Millard
markmi at dsl-only.net

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


Re: buildworld fails while building static clang library

2017-08-05 Thread Dimitry Andric
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 because the clang port doesn't allow parallel make jobs?
> 
> Nonetheless, as to my query regarding building the world, based on what my 
> goals are (as I stated earlier), does it require me to actually build the 
> whole world?
> 
> Regards,
> Aijaz Baig
> 
> On Sat, Aug 5, 2017 at 2:34 PM, Dimitry Andric  wrote:
> 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]: stopped in /usr/src/lib/clang
> 
> I'm just guessing, but the most likely cause is lack of memory.  Please
> check dmesg for any messages like "pid foo (bar), uid baz, was killed:
> out of swap space".  To work around this, you can temporarily add more
> swap space, or lower your -j level.

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 there being an issue with ar and/or ranlib choking when the
.a files become too big.  Ed, does that ring any bells?

-Dimitry



signature.asc
Description: Message signed with OpenPGP


Re: buildworld fails while building static clang library

2017-08-05 Thread Aijaz Baig
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 jobs?

Nonetheless, as to my query regarding building the world, based on what my
goals are (as I stated earlier), does it require me to actually build the
whole world?

Regards,
Aijaz Baig

On Sat, Aug 5, 2017 at 2:34 PM, Dimitry Andric  wrote:

> 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]: stopped in /usr/src/lib/clang
>
> I'm just guessing, but the most likely cause is lack of memory.  Please
> check dmesg for any messages like "pid foo (bar), uid baz, was killed:
> out of swap space".  To work around this, you can temporarily add more
> swap space, or lower your -j level.
>
> -Dimitry
>
>


-- 

Best Regards,
Aijaz Baig
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: buildworld fails while building static clang library

2017-08-05 Thread Dimitry Andric
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]: stopped in /usr/src/lib/clang

I'm just guessing, but the most likely cause is lack of memory.  Please
check dmesg for any messages like "pid foo (bar), uid baz, was killed:
out of swap space".  To work around this, you can temporarily add more
swap space, or lower your -j level.

-Dimitry



signature.asc
Description: Message signed with OpenPGP


Re: buildworld fails with warning in usr.bin/diff/diffreg.c

2017-04-24 Thread Dimitry Andric

> 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/usr.bin/diff/diffreg.c:1085: warning: 'i' may be
>> used uninitialized in this function
> 
> If I'm reading the code correctly, this is caused by this code at line
> 1217 and the analyzer being insufficiently smart (all prior uses include
> initialization in for() loops):
> 
>if (diff_format != D_GFORMAT)
>i = fetch(ixnew, c, d, f2, diff_format == D_NORMAL ? '>' : 
> '\0', 0, *pflags);
>if (i != 0 && diff_format == D_EDIT) {
> 
> Adding "i = 0;" above this fixes the warning for me and appears to
> preserve the intent.  This variable should be named something other than
> i to avoid confusion.

See also https://reviews.freebsd.org/D10462 . Sorry for slacking off on that. :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP


Re: buildworld fails with warning in usr.bin/diff/diffreg.c

2017-04-24 Thread Brooks Davis
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 uninitialized in this function

If I'm reading the code correctly, this is caused by this code at line
1217 and the analyzer being insufficiently smart (all prior uses include
initialization in for() loops):

if (diff_format != D_GFORMAT)
i = fetch(ixnew, c, d, f2, diff_format == D_NORMAL ? '>' : 
'\0', 0, *pflags);
if (i != 0 && diff_format == D_EDIT) {

Adding "i = 0;" above this fixes the warning for me and appears to
preserve the intent.  This variable should be named something other than
i to avoid confusion.

-- Brooks


signature.asc
Description: PGP signature


Re: buildworld fails with warning in usr.bin/diff/diffreg.c

2017-04-24 Thread Hamza Sheikh
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 mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Buildworld fails if WITHOUT_INET6=YES defined

2017-03-03 Thread Oleg V. Nauman
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 gen_gateway() with a function prototype rather than using a
> pre-prototype-style definition).
> 
> https://github.com/the-tcpdump-group/libpcap/commit/470df104c6f55f6d6f390df7
> 448d8eb65c7642b9#diff-021c0dd9e9ed7100b9e31d8d95c930f2

 I can confirm that it fixes the issue.

> 
> Thank you!
> 
> Alex Deiter
> alex.dei...@gmail.com
> 
> > On 18 Feb 2017, at 00:09, Bryan Drewery  wrote:
> > 
> > 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  -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/usr/src/contrib/libpcap -MD  -
>  MF.depend.fad-getad.o -MTfad-getad.o -std=gnu99
>  -fstack-protector-strong -Wno- pointer-sign -Wno-empty-body
>  -Wno-string-plus-int -Wno-unused-const-variable -
>  Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
>  -Wno- unused-function -Wno-enum-conversion -Wno-unused-local-typedef
>  -Wno-switch - Wno-switch-enum -Wno-knr-promoted-parameter
>  -Wno-parentheses  -Qunused- arguments  -c
>  /usr/src/contrib/libpcap/fad-getad.c -o fad-getad.o
>  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/usr/src/contrib/libpcap -MD  -
>  MF.depend.gencode.o -MTgencode.o -std=gnu99 -fstack-protector-strong
>  -Wno-
>  pointer-sign -Wno-empty-body -Wno-string-plus-int
>  -Wno-unused-const-variable - Wno-tautological-compare
>  -Wno-unused-value -Wno-parentheses-equality -Wno- unused-function
>  -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -
>  Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses 
>  -Qunused- arguments  -c /usr/src/contrib/libpcap/gencode.c -o
>  gencode.o
>  /usr/src/contrib/libpcap/gencode.c:695:9: error: no member named 'ai'
>  in
>  'struct _compiler_state'
>  
>    cstate.ai = NULL;
>    ~~ ^
>  
>  /usr/src/contrib/libpcap/gencode.c:4916:13: error: use of undeclared
>  identifier 'cstate'
>  
>    bpf_error(cstate, "direction applied to 'gateway'");
>    
>  ^
>  
>  /usr/src/contrib/libpcap/gencode.c:4923:11: error: use of undeclared
>  identifier 'cstate'
>  
>    switch (cstate->linktype) {
>    
>    ^
>  
>  /usr/src/contrib/libpcap/gencode.c:4961:17: error: use of undeclared
>  identifier 'cstate'
>  
>    b1 = gen_host(cstate, **alist++, 0x, proto, Q_OR,
>  
>  Q_HOST);
>  
>  ^
>  
>  /usr/src/contrib/libpcap/gencode.c:4963:19: error: use of undeclared
>  identifier 'cstate'
>  
>    tmp = gen_host(cstate, **alist++, 0x,
>    proto,
>  
>  Q_OR,
>  
>   ^
>  
>  /usr/src/contrib/libpcap/gencode.c:4972:12: error: use of undeclared
>  identifier 'cstate'
>  
>    bpf_error(cstate, "illegal modifier of 'gateway'");
>    
>  ^
>  
>  6 errors generated.
>  *** Error code 1
>  
>  Stop.
>  make[5]: stopped in /usr/src/lib/libpcap
>  *** Error code 1
> >>> 
> >>> CCing Xin, who did the libpcap upgrade.
> >>> -Ngie
> >> 
> >> I get an error even with INET6 building grammar.o:
> >>> /root/git/freebsd/contrib/libpcap/grammar.y:348:15: error: use of
> >>> undeclared identifier 'cstate'; did you mean 'cstat'?>>> 
> >>>finish_parse(cstate, yystack.l_mark[0].blk.b);
> >>>
> >>> ^~
> >>> cstat
> >>> 
> >>> grammar.c:1291:1: note: 'cstat' declared here
> >>> YYPARSE_DECL()
> >>> ^
> > 
> > Ignore me, my yacc is just outdated.

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

Re: Buildworld fails if WITHOUT_INET6=YES defined

2017-03-02 Thread Ngie Cooper
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() with a function prototype rather than using a
> pre-prototype-style definition).
>
> https://github.com/the-tcpdump-group/libpcap/commit/470df104c6f55f6d6f390df7448d8eb65c7642b9#diff-021c0dd9e9ed7100b9e31d8d95c930f2

Hi Dieter,
Could you please open a bug and CC glebius@ and myself on it?
Thanks!
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Buildworld fails if WITHOUT_INET6=YES defined

2017-03-02 Thread Alex Deiter
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 definition).

https://github.com/the-tcpdump-group/libpcap/commit/470df104c6f55f6d6f390df7448d8eb65c7642b9#diff-021c0dd9e9ed7100b9e31d8d95c930f2

Thank you!

Alex Deiter
alex.dei...@gmail.com



> On 18 Feb 2017, at 00:09, Bryan Drewery  wrote:
> 
> 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  -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/usr/src/contrib/libpcap -MD  -
 MF.depend.fad-getad.o -MTfad-getad.o -std=gnu99 -fstack-protector-strong 
 -Wno-
 pointer-sign -Wno-empty-body -Wno-string-plus-int 
 -Wno-unused-const-variable -
 Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-
 unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch 
 -
 Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-
 arguments  -c /usr/src/contrib/libpcap/fad-getad.c -o fad-getad.o
 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/usr/src/contrib/libpcap -MD  -
 MF.depend.gencode.o -MTgencode.o -std=gnu99 -fstack-protector-strong -Wno-
 pointer-sign -Wno-empty-body -Wno-string-plus-int 
 -Wno-unused-const-variable -
 Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-
 unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch 
 -
 Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-
 arguments  -c /usr/src/contrib/libpcap/gencode.c -o gencode.o
 /usr/src/contrib/libpcap/gencode.c:695:9: error: no member named 'ai' in
 'struct _compiler_state'
   cstate.ai = NULL;
   ~~ ^
 /usr/src/contrib/libpcap/gencode.c:4916:13: error: use of undeclared
 identifier 'cstate'
   bpf_error(cstate, "direction applied to 'gateway'");
 ^
 /usr/src/contrib/libpcap/gencode.c:4923:11: error: use of undeclared
 identifier 'cstate'
   switch (cstate->linktype) {
   ^
 /usr/src/contrib/libpcap/gencode.c:4961:17: error: use of undeclared
 identifier 'cstate'
   b1 = gen_host(cstate, **alist++, 0x, proto, Q_OR,
 Q_HOST);
 ^
 /usr/src/contrib/libpcap/gencode.c:4963:19: error: use of undeclared
 identifier 'cstate'
   tmp = gen_host(cstate, **alist++, 0x, proto,
 Q_OR,
  ^
 /usr/src/contrib/libpcap/gencode.c:4972:12: error: use of undeclared
 identifier 'cstate'
   bpf_error(cstate, "illegal modifier of 'gateway'");
 ^
 6 errors generated.
 *** Error code 1
 
 Stop.
 make[5]: stopped in /usr/src/lib/libpcap
 *** Error code 1
>>> 
>>> CCing Xin, who did the libpcap upgrade.
>>> -Ngie
>>> 
>> 
>> I get an error even with INET6 building grammar.o:
>> 
>>> /root/git/freebsd/contrib/libpcap/grammar.y:348:15: error: use of 
>>> undeclared identifier 'cstate'; did you mean 'cstat'?
>>>finish_parse(cstate, yystack.l_mark[0].blk.b);   
>>>   
>>> ^~  
>>>   
>>> cstat   
>>>   
>>> grammar.c:1291:1: note: 'cstat' declared here   
>>>
>>> YYPARSE_DECL()  
>>>
>>> ^   
>>>
>> 
> 
> Ignore me, my yacc is just outdated.
> 
> -- 
> Regards,
> Bryan Drewery
> 

___
freebsd-current@freebsd.org mailing list

Re: Buildworld fails if WITHOUT_INET6=YES defined

2017-02-17 Thread Ngie Cooper (yaneurabeya)

> 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


Re: Buildworld fails if WITHOUT_INET6=YES defined

2017-02-17 Thread Bryan Drewery
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  -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/usr/src/contrib/libpcap -MD  -
>>> MF.depend.fad-getad.o -MTfad-getad.o -std=gnu99 -fstack-protector-strong 
>>> -Wno-
>>> pointer-sign -Wno-empty-body -Wno-string-plus-int 
>>> -Wno-unused-const-variable -
>>> Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-
>>> unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -
>>> Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-
>>> arguments  -c /usr/src/contrib/libpcap/fad-getad.c -o fad-getad.o
>>> 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/usr/src/contrib/libpcap -MD  -
>>> MF.depend.gencode.o -MTgencode.o -std=gnu99 -fstack-protector-strong -Wno-
>>> pointer-sign -Wno-empty-body -Wno-string-plus-int 
>>> -Wno-unused-const-variable -
>>> Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-
>>> unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -
>>> Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-
>>> arguments  -c /usr/src/contrib/libpcap/gencode.c -o gencode.o
>>> /usr/src/contrib/libpcap/gencode.c:695:9: error: no member named 'ai' in
>>> 'struct _compiler_state'
>>>cstate.ai = NULL;
>>>~~ ^
>>> /usr/src/contrib/libpcap/gencode.c:4916:13: error: use of undeclared
>>> identifier 'cstate'
>>>bpf_error(cstate, "direction applied to 'gateway'");
>>>  ^
>>> /usr/src/contrib/libpcap/gencode.c:4923:11: error: use of undeclared
>>> identifier 'cstate'
>>>switch (cstate->linktype) {
>>>^
>>> /usr/src/contrib/libpcap/gencode.c:4961:17: error: use of undeclared
>>> identifier 'cstate'
>>>b1 = gen_host(cstate, **alist++, 0x, proto, Q_OR,
>>> Q_HOST);
>>>  ^
>>> /usr/src/contrib/libpcap/gencode.c:4963:19: error: use of undeclared
>>> identifier 'cstate'
>>>tmp = gen_host(cstate, **alist++, 0x, proto,
>>> Q_OR,
>>>   ^
>>> /usr/src/contrib/libpcap/gencode.c:4972:12: error: use of undeclared
>>> identifier 'cstate'
>>>bpf_error(cstate, "illegal modifier of 'gateway'");
>>>  ^
>>> 6 errors generated.
>>> *** Error code 1
>>>
>>> Stop.
>>> make[5]: stopped in /usr/src/lib/libpcap
>>> *** Error code 1
>>
>> CCing Xin, who did the libpcap upgrade.
>> -Ngie
>>
> 
> I get an error even with INET6 building grammar.o:
> 
>> /root/git/freebsd/contrib/libpcap/grammar.y:348:15: error: use of undeclared 
>> identifier 'cstate'; did you mean 'cstat'?
>> finish_parse(cstate, yystack.l_mark[0].blk.b);   
>>   
>>  ^~  
>>   
>>  cstat   
>>   
>> grammar.c:1291:1: note: 'cstat' declared here
>>   
>> YYPARSE_DECL()   
>>   
>> ^
>>   
> 

Ignore me, my yacc is just outdated.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature


Re: Buildworld fails if WITHOUT_INET6=YES defined

2017-02-17 Thread Bryan Drewery
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/usr/src/lib/libpcap -
>> D_U_="__attribute__((unused))" -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -
>> DBUILDING_PCAP -DHAVE_NET_PFVAR_H -I/usr/src/contrib/libpcap -MD  -
>> MF.depend.fad-getad.o -MTfad-getad.o -std=gnu99 -fstack-protector-strong 
>> -Wno-
>> pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
>> -
>> Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-
>> unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -
>> Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-
>> arguments  -c /usr/src/contrib/libpcap/fad-getad.c -o fad-getad.o
>> 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/usr/src/contrib/libpcap -MD  -
>> MF.depend.gencode.o -MTgencode.o -std=gnu99 -fstack-protector-strong -Wno-
>> pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
>> -
>> Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-
>> unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -
>> Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-
>> arguments  -c /usr/src/contrib/libpcap/gencode.c -o gencode.o
>> /usr/src/contrib/libpcap/gencode.c:695:9: error: no member named 'ai' in
>> 'struct _compiler_state'
>>cstate.ai = NULL;
>>~~ ^
>> /usr/src/contrib/libpcap/gencode.c:4916:13: error: use of undeclared
>> identifier 'cstate'
>>bpf_error(cstate, "direction applied to 'gateway'");
>>  ^
>> /usr/src/contrib/libpcap/gencode.c:4923:11: error: use of undeclared
>> identifier 'cstate'
>>switch (cstate->linktype) {
>>^
>> /usr/src/contrib/libpcap/gencode.c:4961:17: error: use of undeclared
>> identifier 'cstate'
>>b1 = gen_host(cstate, **alist++, 0x, proto, Q_OR,
>> Q_HOST);
>>  ^
>> /usr/src/contrib/libpcap/gencode.c:4963:19: error: use of undeclared
>> identifier 'cstate'
>>tmp = gen_host(cstate, **alist++, 0x, proto,
>> Q_OR,
>>   ^
>> /usr/src/contrib/libpcap/gencode.c:4972:12: error: use of undeclared
>> identifier 'cstate'
>>bpf_error(cstate, "illegal modifier of 'gateway'");
>>  ^
>> 6 errors generated.
>> *** Error code 1
>>
>> Stop.
>> make[5]: stopped in /usr/src/lib/libpcap
>> *** Error code 1
> 
> CCing Xin, who did the libpcap upgrade.
> -Ngie
> 

I get an error even with INET6 building grammar.o:

> /root/git/freebsd/contrib/libpcap/grammar.y:348:15: error: use of undeclared 
> identifier 'cstate'; did you mean 'cstat'?
> finish_parse(cstate, yystack.l_mark[0].blk.b);
>  
>  ^~   
>  
>  cstat
>  
> grammar.c:1291:1: note: 'cstat' declared here 
>  
> YYPARSE_DECL()
>  
> ^ 
>  

-- 
Regards,
Bryan Drewery




signature.asc
Description: OpenPGP digital signature


Re: Buildworld fails if WITHOUT_INET6=YES defined

2017-02-16 Thread Ngie Cooper (yaneurabeya)

> 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_SNPRINTF -DHAVE_VSNPRINTF -
> DBUILDING_PCAP -DHAVE_NET_PFVAR_H -I/usr/src/contrib/libpcap -MD  -
> MF.depend.fad-getad.o -MTfad-getad.o -std=gnu99 -fstack-protector-strong -Wno-
> pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -
> Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-
> unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -
> Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-
> arguments  -c /usr/src/contrib/libpcap/fad-getad.c -o fad-getad.o
> 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/usr/src/contrib/libpcap -MD  -
> MF.depend.gencode.o -MTgencode.o -std=gnu99 -fstack-protector-strong -Wno-
> pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -
> Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-
> unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -
> Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-
> arguments  -c /usr/src/contrib/libpcap/gencode.c -o gencode.o
> /usr/src/contrib/libpcap/gencode.c:695:9: error: no member named 'ai' in
> 'struct _compiler_state'
>cstate.ai = NULL;
>~~ ^
> /usr/src/contrib/libpcap/gencode.c:4916:13: error: use of undeclared
> identifier 'cstate'
>bpf_error(cstate, "direction applied to 'gateway'");
>  ^
> /usr/src/contrib/libpcap/gencode.c:4923:11: error: use of undeclared
> identifier 'cstate'
>switch (cstate->linktype) {
>^
> /usr/src/contrib/libpcap/gencode.c:4961:17: error: use of undeclared
> identifier 'cstate'
>b1 = gen_host(cstate, **alist++, 0x, proto, Q_OR,
> Q_HOST);
>  ^
> /usr/src/contrib/libpcap/gencode.c:4963:19: error: use of undeclared
> identifier 'cstate'
>tmp = gen_host(cstate, **alist++, 0x, proto,
> Q_OR,
>   ^
> /usr/src/contrib/libpcap/gencode.c:4972:12: error: use of undeclared
> identifier 'cstate'
>bpf_error(cstate, "illegal modifier of 'gateway'");
>  ^
> 6 errors generated.
> *** Error code 1
> 
> Stop.
> make[5]: stopped in /usr/src/lib/libpcap
> *** Error code 1

CCing Xin, who did the libpcap upgrade.
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: Buildworld fails if WITHOUT_INET6=YES defined

2017-02-16 Thread Chris H
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))" -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -
> DBUILDING_PCAP -DHAVE_NET_PFVAR_H -I/usr/src/contrib/libpcap -MD  -
> MF.depend.fad-getad.o -MTfad-getad.o -std=gnu99 -fstack-protector-strong
> -Wno- pointer-sign -Wno-empty-body -Wno-string-plus-int
> -Wno-unused-const-variable - Wno-tautological-compare -Wno-unused-value
> -Wno-parentheses-equality -Wno- unused-function -Wno-enum-conversion
> -Wno-unused-local-typedef -Wno-switch - Wno-switch-enum
> -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused- arguments  -c
> /usr/src/contrib/libpcap/fad-getad.c -o fad-getad.o 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/usr/src/contrib/libpcap -MD  -
> MF.depend.gencode.o -MTgencode.o -std=gnu99 -fstack-protector-strong -Wno-
> pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
> - Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-
> unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -
> Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-
> arguments  -c /usr/src/contrib/libpcap/gencode.c -o gencode.o
> /usr/src/contrib/libpcap/gencode.c:695:9: error: no member named 'ai' in 
> 'struct _compiler_state'
> cstate.ai = NULL;
> ~~ ^
> /usr/src/contrib/libpcap/gencode.c:4916:13: error: use of undeclared 
> identifier 'cstate'
> bpf_error(cstate, "direction applied to 'gateway'");
>   ^
> /usr/src/contrib/libpcap/gencode.c:4923:11: error: use of undeclared 
> identifier 'cstate'
> switch (cstate->linktype) {
> ^
> /usr/src/contrib/libpcap/gencode.c:4961:17: error: use of undeclared 
> identifier 'cstate'
> b1 = gen_host(cstate, **alist++, 0x, proto, Q_OR, 
> Q_HOST);
>   ^
> /usr/src/contrib/libpcap/gencode.c:4963:19: error: use of undeclared 
> identifier 'cstate'
> tmp = gen_host(cstate, **alist++, 0x, proto, 
> Q_OR,
>^
> /usr/src/contrib/libpcap/gencode.c:4972:12: error: use of undeclared 
> identifier 'cstate'
> bpf_error(cstate, "illegal modifier of 'gateway'");
>   ^
> 6 errors generated.
> *** Error code 1
> 
> Stop.
> make[5]: stopped in /usr/src/lib/libpcap
> *** Error code 1
> 
> 
I regret I don't have an immediate solution for you. But I seem
to remember having seen at least a similar problem posted on the
mailing lists. I did a search, and this was the closest I could
find:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=146910

It's listed as still in progress dated 2010 -- yikes!

Anyway. I think you might do well to create a pr(1) yourself
for this. You can do so at the following link:

https://bugs.freebsd.org/bugzilla/enter_bug.cgi

Best wishes.

--Chris


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


Re: buildworld fails @r305471: "cc: error: linker command failed with exit code 1"

2016-09-06 Thread David Wolfskill
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 race condition during the
build, I have placed the typescripts from both builds in
.

The (csh) aliases that are used expand to:

* _bw
  setenv TMPDIR /tmp && \
  id && \
  mount && \
  cd /usr/src && \
  uname -a && \
  date && \
  make -j16 buildworld && \
  date && \
  make -j16 buildkernel && \
  date && \
  rm -fr /boot/modules.old && \
  cp -pr /boot/modules{,.old} && \
  make installkernel && \
  date && \
  pushd /usr/ports && \
  pushd x11/nvidia-driver && \
  make clean ; popd ; popd && \
  date && \
  mergemaster -U -u 0022 -p && \
  date && \
  rm -fr /usr/include.old && \
  date && \
  mv /usr/include{,.old} && \
  date && \
  rm -fr /usr/share/man && \
  date && \
  make installworld && \
  date && \
  mergemaster -F -U -u 0022 -i && \
  date && \
  make delete-old && \
  date && \
  df -k

* _do
  setenv TMPDIR /tmp && \
  id && \
  mount && \
  cd /usr/src && \
  uname -a && \
  date && \
  make delete-old-libs && \
  cp /var/run/dmesg.boot /var/tmp/dmesg.boot.12.0-CURRENT_amd64 && \
  log_uname && \
  date


"log_uname" is a little shell script that appends the output of "uname
-vp" to a file named:
/var/tmp/uname_${arch}.$( uname -r | sed -e 's/\..*$//' )

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature


Re: buildworld fails @r305471: "cc: error: linker command failed with exit code 1"

2016-09-06 Thread David Wolfskill
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/obj/usr/src/sys/GENERIC  amd64
> 
> ...
> [things generally go downhill from this point] ...
> 
> I'll be repeating the experiment on my laptop shortly.
> 

Laptop got through "buildworld" Just Fine; re-trying on build machine.
We may have a race.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature


Re: Buildworld Fails

2016-05-10 Thread Johan Hendriks
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 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 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/sys/x86/include
 /usr/src/sys/dev/bhnd/tools/nvram_map_gen.sh
 /usr/src/sys/dev/bhnd/nvram/nvram_map -h
 make[4]: exec(/usr/src/sys/dev/bhnd/tools/nvram_map_gen.sh) failed
 (Permission denied)
>>> Have you got /usr/src mounted noexec?
>>>
>>> -Dimitry
>>>
>> Thank you all.
>> I had exec=off on my /usr/src zfs dataset.
>>
>> Never needed exec on /usr/src so for that reason it was turned to off.
>> Till now, now it is turned to on.
>>
>> Now the kernel builds fine.
>>
>> Thanks Adrian and Dimitry for your time.
>>
>> regards
>> Johan
>>
>>
>>
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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


Re: Buildworld Fails

2016-05-10 Thread Adrian Chadd
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 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/sys/x86/include
 /usr/src/sys/dev/bhnd/tools/nvram_map_gen.sh
 /usr/src/sys/dev/bhnd/nvram/nvram_map -h
 make[4]: exec(/usr/src/sys/dev/bhnd/tools/nvram_map_gen.sh) failed
 (Permission denied)
>>> Have you got /usr/src mounted noexec?
>>>
>>> -Dimitry
>>>
>> Thank you all.
>> I had exec=off on my /usr/src zfs dataset.
>>
>> Never needed exec on /usr/src so for that reason it was turned to off.
>> Till now, now it is turned to on.
>>
>> Now the kernel builds fine.
>>
>> Thanks Adrian and Dimitry for your time.
>
> I think it *should* be possible to build world with /usr/src mounted
> noexec.  Typically, buildworld shell scripts are run using 'sh', for
> example in sys/conf/kern.post.mk there is:
>
> vers.c: $S/conf/newvers.sh $S/sys/param.h ${SYSTEM_DEP}
> MAKE=${MAKE} sh $S/conf/newvers.sh ${KERN_IDENT}
>
> The same should probably be done for the nvram_map_gen.sh script.
>
> -Dimitry
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Buildworld Fails

2016-05-10 Thread Dimitry Andric
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.0-CURRENT #8 r299158:
>> ...
>>> ===> bhnd (all)
>>> machine -> /usr/src/sys/amd64/include
>>> x86 -> /usr/src/sys/x86/include
>>> /usr/src/sys/dev/bhnd/tools/nvram_map_gen.sh
>>> /usr/src/sys/dev/bhnd/nvram/nvram_map -h
>>> make[4]: exec(/usr/src/sys/dev/bhnd/tools/nvram_map_gen.sh) failed
>>> (Permission denied)
>> Have you got /usr/src mounted noexec?
>> 
>> -Dimitry
>> 
> Thank you all.
> I had exec=off on my /usr/src zfs dataset.
> 
> Never needed exec on /usr/src so for that reason it was turned to off.
> Till now, now it is turned to on.
> 
> Now the kernel builds fine.
> 
> Thanks Adrian and Dimitry for your time.

I think it *should* be possible to build world with /usr/src mounted
noexec.  Typically, buildworld shell scripts are run using 'sh', for
example in sys/conf/kern.post.mk there is:

vers.c: $S/conf/newvers.sh $S/sys/param.h ${SYSTEM_DEP}
MAKE=${MAKE} sh $S/conf/newvers.sh ${KERN_IDENT}

The same should probably be done for the nvram_map_gen.sh script.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: Buildworld Fails

2016-05-10 Thread 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 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 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/sys/x86/include
>>> /usr/src/sys/dev/bhnd/tools/nvram_map_gen.sh
>>> /usr/src/sys/dev/bhnd/nvram/nvram_map -h
>>> make[4]: exec(/usr/src/sys/dev/bhnd/tools/nvram_map_gen.sh) failed
>>> (Permission denied)
>> Have you got /usr/src mounted noexec?
>>
>> -Dimitry
>>
> Thank you all.
> I had exec=off on my /usr/src zfs dataset.
>
> Never needed exec on /usr/src so for that reason it was turned to off.
> Till now, now it is turned to on.
>
> Now the kernel builds fine.
>
> Thanks Adrian and Dimitry for your time.
>
> regards
> Johan
>
>
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Buildworld Fails

2016-05-10 Thread Johan Hendriks


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)
>> machine -> /usr/src/sys/amd64/include
>> x86 -> /usr/src/sys/x86/include
>> /usr/src/sys/dev/bhnd/tools/nvram_map_gen.sh
>> /usr/src/sys/dev/bhnd/nvram/nvram_map -h
>> make[4]: exec(/usr/src/sys/dev/bhnd/tools/nvram_map_gen.sh) failed
>> (Permission denied)
> Have you got /usr/src mounted noexec?
>
> -Dimitry
>
Thank you all.
I had exec=off on my /usr/src zfs dataset.

Never needed exec on /usr/src so for that reason it was turned to off.
Till now, now it is turned to on.

Now the kernel builds fine.

Thanks Adrian and Dimitry for your time.

regards
Johan



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


Re: Buildworld Fails

2016-05-10 Thread 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)
> machine -> /usr/src/sys/amd64/include
> x86 -> /usr/src/sys/x86/include
> /usr/src/sys/dev/bhnd/tools/nvram_map_gen.sh
> /usr/src/sys/dev/bhnd/nvram/nvram_map -h
> make[4]: exec(/usr/src/sys/dev/bhnd/tools/nvram_map_gen.sh) failed
> (Permission denied)

Have you got /usr/src mounted noexec?

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: Buildworld Fails

2016-05-10 Thread Adrian Chadd
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 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
> -nostdinc   -DHAVE_KERNEL_OPTION_HEADERS -include
> /usr/obj/usr/src/sys/KRNL/opt_global.h -I. -I/usr/src/sys -fno-common -g
> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
> -I/usr/obj/usr/src/sys/KRNL  -MD  -MF.depend.if_bge.o -MTif_bge.o
> -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
> -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector
> -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
> -Wno-pointer-sign -D__printf__=__freebsd_kprintf__
> -Wmissing-include-dirs -fdiagnostics-show-option  -Wno-unknown-pragmas
> -Wno-error-tautological-compare -Wno-error-empty-body
> -Wno-error-parentheses-equality -Wno-error-unused-function
> -Wno-error-pointer-sign -Wno-error-shift-negative-value  -mno-aes
> -mno-avx  -std=iso9899:1999 -c
> /usr/src/sys/modules/bge/../../dev/bge/if_bge.c -o if_bge.o
> ctfconvert -L VERSION -g if_bge.o
> ld -d -warn-common -r -d -o if_bge.ko.full if_bge.o
> ctfmerge -L VERSION -g -o if_bge.ko.full if_bge.o
>
> :> export_syms
> awk -f /usr/src/sys/conf/kmod_syms.awk if_bge.ko.full  export_syms |
> xargs -J% objcopy % if_bge.ko.full
> objcopy --only-keep-debug if_bge.ko.full if_bge.ko.debug
> objcopy --strip-debug --add-gnu-debuglink=if_bge.ko.debug
> if_bge.ko.full if_bge.ko
> ===> bhnd (all)
> machine -> /usr/src/sys/amd64/include
> x86 -> /usr/src/sys/x86/include
> /usr/src/sys/dev/bhnd/tools/nvram_map_gen.sh
> /usr/src/sys/dev/bhnd/nvram/nvram_map -h
> make[4]: exec(/usr/src/sys/dev/bhnd/tools/nvram_map_gen.sh) failed
> (Permission denied)
> *** Error code 1
>
> Stop.
> make[4]: stopped in /usr/src/sys/modules/bhnd
> *** Error code 1
>
> Stop.
> make[3]: stopped in /usr/src/sys/modules
> *** Error code 1
>
> Stop.
> make[2]: stopped in /usr/obj/usr/src/sys/KRNL
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/src
> *** Error code 1
>
> Stop.
> make: stopped in /usr/src
>
>
> My kernel Config File
>
> include GENERIC
> ident   KRNL
>
> # hast support
> options GEOM_GATE
>
> # Carp support
> device  carp
>
> # pf
> options ALTQ
> options ALTQ_CBQ
> options ALTQ_RED
> options ALTQ_RIO
> options ALTQ_HFSC
> options ALTQ_CDNR
> options ALTQ_PRIQ
> device  pf
> device  pflog
> device  pfsync
>
> # new CAM scheduler
> options CAM_NETFLIX_IOSCHED
>
> # Console color options
> options SC_NORM_ATTR=(FG_LIGHTGREY|BG_BLACK)
> options SC_NORM_REV_ATTR=(FG_YELLOW|BG_GREEN)
> options SC_KERNEL_CONS_ATTR=(FG_BROWN|BG_BLACK)
> options SC_KERNEL_CONS_REV_ATTR=(FG_BLACK|BG_RED)
>
> # System console options
> options SC_DISABLE_REBOOT   # disable reboot key sequence
> options SC_HISTORY_SIZE=8192 # number of history buffer lines
>
> What could be wrong?
>
> regards
>
> Johan
>
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Buildworld fails due to WITHOUT_CRYPT (3 issues)

2014-12-29 Thread Beeblebrox
 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 mentioned in subsequent 
emails and which I can confirm persist after a fresh buildworld run (removed 
Herbert's patch) on Rev: 276354.

PROBLEM-1: ctld. Not shure how much CAM and ZFS are related. Not using anything 
CAM afaik, as netiher kernel (device ctl) nor loadr.conf have ctld. So I assume 
this is a no big deal level issue?
=== usr.sbin/ctld (all)
cc  -O2 -pipe   -I/asp/git/src/usr.sbin/ctld 
-I/asp/git/src/usr.sbin/ctld/../../sys 
-I/asp/git/src/usr.sbin/ctld/../../sys/cam/ctl 
-I/asp/git/src/usr.sbin/ctld/../../sys/dev/iscsi -DNDEBUG -std=gnu99 
-fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter 
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
-Wold-style-definition -Wno-pointer-sign -Wthread-safety -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments  -o ctld 
ctld.o discovery.o isns.o kernel.o keys.o log.o login.o parse.o pdu.o token.o  
-lbsdxml  -ll  -lsbuf  -lutil
discovery.o: In function `discovery_target_filtered_out':
/asp/git/src/usr.sbin/ctld/discovery.c:(.text+0x45b): undefined reference to 
`chap_authenticate'
login.o: In function `login':
/asp/git/src/usr.sbin/ctld/login.c:(.text+0x628): undefined reference to 
`chap_new'
/asp/git/src/usr.sbin/ctld/login.c:(.text+0x648): undefined reference to 
`chap_get_challenge'
/asp/git/src/usr.sbin/ctld/login.c:(.text+0x654): undefined reference to 
`chap_get_id'
/asp/git/src/usr.sbin/ctld/login.c:(.text+0x7a0): undefined reference to 
`chap_receive'
/asp/git/src/usr.sbin/ctld/login.c:(.text+0x7cc): undefined reference to 
`chap_authenticate'
/asp/git/src/usr.sbin/ctld/login.c:(.text+0x8e2): undefined reference to 
`rchap_new'
/asp/git/src/usr.sbin/ctld/login.c:(.text+0x8f3): undefined reference to 
`rchap_receive'
/asp/git/src/usr.sbin/ctld/login.c:(.text+0x903): undefined reference to 
`rchap_get_response'
/asp/git/src/usr.sbin/ctld/login.c:(.text+0x90e): undefined reference to 
`rchap_delete'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

PROBLEM-2: MK_PKGBOOTSTRAP
=== usr.sbin/pkg (all)
cc  -O2 -pipe   -I/asp/git/src/usr.sbin/pkg/../../contrib/libucl/include 
-DNDEBUG -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter 
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
-Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations 
-Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Qunused-arguments -c /asp/git/src/usr.sbin/pkg/pkg.c
/asp/git/src/usr.sbin/pkg/pkg.c:54:10: fatal error: 'openssl/err.h' file
  not found
#include openssl/err.h

PROBLEM-3: No /usr/sbin/mtree after # installworld

Other than these 3, there's also the persistent problem involving ccache, which 
again is no big deal, just FYI.

Regards

-- 
FreeBSD_amd64_11-Current_RadeonKMS


pgpS5A799pkd7.pgp
Description: OpenPGP digital signature


Re: Buildworld fails due to WITHOUT_CRYPT (3 issues)

2014-12-27 Thread Garrett Cooper
On Dec 24, 2014, at 1:45, Beeblebrox zap...@berentweb.com 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/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib -DHAVE_ERR_H 
 -DHAVE_GETADDRINFO -DHAVE_STRLCPY -DHAVE_STDINT_H -DHAVE_INTTYPES_H 
 -DQUADFMT='llu' -DQUADXFMT='llx' -DNDEBUG -std=gnu99 -fstack-protector 
 -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter 
 -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type 
 -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
 -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
 -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations 
 -Wthread-safety -Wno-empty-body -Wno-string-plus-int 
 -Wno-unused-const-variable -Qunused-arguments -c 
 /asp/git/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c -o 
 snmpcrypto.o
 /asp/git/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:370:1:
  error: 
  conflicting types for 'snmp_passwd_to_keys'
 snmp_passwd_to_keys(struct snmp_user *user, char *passwd __unused)
 /asp/git/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:273:16: 
 note: 
  previous declaration is here
 enum snmp_code snmp_passwd_to_keys(struct snmp_user *, char *);
 /asp/git/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:382:1:
  error: 
  conflicting types for 'snmp_get_local_keys'
 snmp_get_local_keys(struct snmp_user *user, uint8_t *eid __unused,
 /asp/git/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:274:16: 
 note: 
  previous declaration is here
 enum snmp_code snmp_get_local_keys(struct snmp_user *, uint8_t *, uint32_t);
 
 * Second problem is with ldns (used WITHOUT_LDNS as temporary fix)
 === lib/libldns (all)
 /usr/local/libexec/ccache/world/clang -target x86_64-unknown-freebsd11.0  -O2 
 -pipe   -I/asp/git/src/lib/libldns/../../contrib/ldns -DNDEBUG -std=gnu99 
 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W 
 -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes 
 -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body 
 -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
 -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
 -Wno-enum-conversion -Qunused-arguments -c 
 /asp/git/src/lib/libldns/../../contrib/ldns/buffer.c -o buffer.o
 In file included from /asp/git/src/lib/libldns/../../contrib/ldns/buffer.c:12:
 In file included from 
 /asp/git/src/lib/libldns/../../contrib/ldns/ldns/ldns.h:98:
 /asp/git/src/lib/libldns/../../contrib/ldns/ldns/dane.h:31:10: fatal error: 
  'openssl/ssl.h' file not found
 #include openssl/ssl.h
 
 * I found no work-around for this problem so I'm now stuck.
 === lib/libc/tests/hash (depend)
 (cd /asp/git/src/lib/libc/tests/hash  make -f 
 /asp/git/src/lib/libc/tests/hash/Makefile _RECURSING_PROGS=  SUBDIR= 
 PROG=h_hash  DEPENDFILE=.depend.h_hash .MAKE.DEPENDFILE=.depend.h_hash   
 depend)
 (cd /asp/git/src/lib/libc/tests/hash  make -f 
 /asp/git/src/lib/libc/tests/hash/Makefile _RECURSING_PROGS=  SUBDIR= 
 PROG=sha2_test  DEPENDFILE=.depend.sha2_test 
 .MAKE.DEPENDFILE=.depend.sha2_test   depend)
 rm -f .depend.sha2_test
 CC='/usr/local/libexec/ccache/world/clang -target x86_64-unknown-freebsd11.0 
 ' mkdep -f .depend.sha2_test -a
 -I/asp/git/src/lib/libc/tests/hash/../../../../crypto/openssh/openbsd-compat 
 -I/asp/git/src/lib/libc/tests/hash/../../../../crypto/openssh 
 -I/asp/git/src/lib/libnetbsd -I/asp/git/src/contrib/netbsd-tests -DNDEBUG 
 -std=gnu99   /asp/git/src/contrib/netbsd-tests/lib/libc/hash/t_sha2.c
 /asp/git/src/contrib/netbsd-tests/lib/libc/hash/t_sha2.c:45:10: fatal error: 
  'openssl/sha.h' file not found

Hi,

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

ldns needs to be fixed to not define LDNS_BUILD_CONFIG_HAVE_SSL to 1 in 
common.h and HAVE_SSL in config.h. I didn’t touch it because I don’t maintain 
that component and the issue isn’t a trivial fix and I can’t test all of the 
permutations easily. Please file a PR and CC des@ on the PR.

Thanks for the report!


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: Buildworld fails due to WITHOUT_CRYPT (3 issues)

2014-12-24 Thread Herbert J. Skuhra
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/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib -DHAVE_ERR_H 
 -DHAVE_GETADDRINFO -DHAVE_STRLCPY -DHAVE_STDINT_H -DHAVE_INTTYPES_H 
 -DQUADFMT='llu' -DQUADXFMT='llx' -DNDEBUG -std=gnu99 -fstack-protector 
 -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter 
 -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type 
 -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
 -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
 -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations 
 -Wthread-safety -Wno-empty-body -Wno-string-plus-int 
 -Wno-unused-const-variable -Qunused-arguments -c 
 /asp/git/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c -o 
 snmpcrypto.o
 /asp/git/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:370:1:
  error: 
   conflicting types for 'snmp_passwd_to_keys'
 snmp_passwd_to_keys(struct snmp_user *user, char *passwd __unused)
 /asp/git/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:273:16: 
 note: 
   previous declaration is here
 enum snmp_code snmp_passwd_to_keys(struct snmp_user *, char *);
 /asp/git/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:382:1:
  error: 
   conflicting types for 'snmp_get_local_keys'
 snmp_get_local_keys(struct snmp_user *user, uint8_t *eid __unused,
 /asp/git/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:274:16: 
 note: 
   previous declaration is here
 enum snmp_code snmp_get_local_keys(struct snmp_user *, uint8_t *, uint32_t);
 
 * Second problem is with ldns (used WITHOUT_LDNS as temporary fix)
 === lib/libldns (all)
 /usr/local/libexec/ccache/world/clang -target x86_64-unknown-freebsd11.0  -O2 
 -pipe   -I/asp/git/src/lib/libldns/../../contrib/ldns -DNDEBUG -std=gnu99 
 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W 
 -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes 
 -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body 
 -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
 -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
 -Wno-enum-conversion -Qunused-arguments -c 
 /asp/git/src/lib/libldns/../../contrib/ldns/buffer.c -o buffer.o
 In file included from /asp/git/src/lib/libldns/../../contrib/ldns/buffer.c:12:
 In file included from 
 /asp/git/src/lib/libldns/../../contrib/ldns/ldns/ldns.h:98:
 /asp/git/src/lib/libldns/../../contrib/ldns/ldns/dane.h:31:10: fatal error: 
   'openssl/ssl.h' file not found
 #include openssl/ssl.h
 
 * I found no work-around for this problem so I'm now stuck.
 === lib/libc/tests/hash (depend)
 (cd /asp/git/src/lib/libc/tests/hash  make -f 
 /asp/git/src/lib/libc/tests/hash/Makefile _RECURSING_PROGS=  SUBDIR= 
 PROG=h_hash  DEPENDFILE=.depend.h_hash .MAKE.DEPENDFILE=.depend.h_hash   
 depend)
 (cd /asp/git/src/lib/libc/tests/hash  make -f 
 /asp/git/src/lib/libc/tests/hash/Makefile _RECURSING_PROGS=  SUBDIR= 
 PROG=sha2_test  DEPENDFILE=.depend.sha2_test 
 .MAKE.DEPENDFILE=.depend.sha2_test   depend)
 rm -f .depend.sha2_test
 CC='/usr/local/libexec/ccache/world/clang -target x86_64-unknown-freebsd11.0 
 ' mkdep -f .depend.sha2_test -a
 -I/asp/git/src/lib/libc/tests/hash/../../../../crypto/openssh/openbsd-compat 
 -I/asp/git/src/lib/libc/tests/hash/../../../../crypto/openssh 
 -I/asp/git/src/lib/libnetbsd -I/asp/git/src/contrib/netbsd-tests -DNDEBUG 
 -std=gnu99   /asp/git/src/contrib/netbsd-tests/lib/libc/hash/t_sha2.c
 /asp/git/src/contrib/netbsd-tests/lib/libc/hash/t_sha2.c:45:10: fatal error: 
   'openssl/sha.h' file not found

I am not running HEAD, but have you tried to disable MK_TESTS as well?
The file lib/libc/Makefile.amd64 includes:

if ${MK_TESTS} != no
SUBDIR+=tests
.endif

 * I would prefer being able to use SSH from world (instead of dropbear), but 
 that seems impossible when openssl is disabled.

What's wrong with security/openssh-portable?

--  
Herbert
___
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 due to WITHOUT_CRYPT (3 issues)

2014-12-24 Thread Scot Hetzel
On Wed, Dec 24, 2014 at 3:45 AM, Beeblebrox zap...@berentweb.com 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 dropbear), but 
 that seems impossible when openssl is disabled.


Using WITHOUT_KERBEROS would allow SSH and other programs built from
world to use the base openssl.

You can still install openssl from ports.  Set WITH_OPENSSL_PORT=yes
in /etc/make.conf to allow the ports to use the openssl port instead
of the openssl from source.

-- 
DISCLAIMER:

No electrons were maimed while sending this message. Only slightly bruised.
___
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 due to WITHOUT_CRYPT (3 issues)

2014-12-24 Thread Herbert J. Skuhra
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/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib -DHAVE_ERR_H 
 -DHAVE_GETADDRINFO -DHAVE_STRLCPY -DHAVE_STDINT_H -DHAVE_INTTYPES_H 
 -DQUADFMT='llu' -DQUADXFMT='llx' -DNDEBUG -std=gnu99 -fstack-protector 
 -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter 
 -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type 
 -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
 -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
 -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations 
 -Wthread-safety -Wno-empty-body -Wno-string-plus-int 
 -Wno-unused-const-variable -Qunused-arguments -c 
 /asp/git/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c -o 
 snmpcrypto.o
 /asp/git/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:370:1:
  error: 
   conflicting types for 'snmp_passwd_to_keys'
 snmp_passwd_to_keys(struct snmp_user *user, char *passwd __unused)
 /asp/git/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:273:16: 
 note: 
   previous declaration is here
 enum snmp_code snmp_passwd_to_keys(struct snmp_user *, char *);
 /asp/git/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:382:1:
  error: 
   conflicting types for 'snmp_get_local_keys'
 snmp_get_local_keys(struct snmp_user *user, uint8_t *eid __unused,
 /asp/git/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:274:16: 
 note: 
   previous declaration is here
 enum snmp_code snmp_get_local_keys(struct snmp_user *, uint8_t *, uint32_t);
 
 * Second problem is with ldns (used WITHOUT_LDNS as temporary fix)
 === lib/libldns (all)
 /usr/local/libexec/ccache/world/clang -target x86_64-unknown-freebsd11.0  -O2 
 -pipe   -I/asp/git/src/lib/libldns/../../contrib/ldns -DNDEBUG -std=gnu99 
 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W 
 -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes 
 -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body 
 -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
 -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
 -Wno-enum-conversion -Qunused-arguments -c 
 /asp/git/src/lib/libldns/../../contrib/ldns/buffer.c -o buffer.o
 In file included from /asp/git/src/lib/libldns/../../contrib/ldns/buffer.c:12:
 In file included from 
 /asp/git/src/lib/libldns/../../contrib/ldns/ldns/ldns.h:98:
 /asp/git/src/lib/libldns/../../contrib/ldns/ldns/dane.h:31:10: fatal error: 
   'openssl/ssl.h' file not found
 #include openssl/ssl.h
 
 * I found no work-around for this problem so I'm now stuck.
 === lib/libc/tests/hash (depend)
 (cd /asp/git/src/lib/libc/tests/hash  make -f 
 /asp/git/src/lib/libc/tests/hash/Makefile _RECURSING_PROGS=  SUBDIR= 
 PROG=h_hash  DEPENDFILE=.depend.h_hash .MAKE.DEPENDFILE=.depend.h_hash   
 depend)
 (cd /asp/git/src/lib/libc/tests/hash  make -f 
 /asp/git/src/lib/libc/tests/hash/Makefile _RECURSING_PROGS=  SUBDIR= 
 PROG=sha2_test  DEPENDFILE=.depend.sha2_test 
 .MAKE.DEPENDFILE=.depend.sha2_test   depend)
 rm -f .depend.sha2_test
 CC='/usr/local/libexec/ccache/world/clang -target x86_64-unknown-freebsd11.0 
 ' mkdep -f .depend.sha2_test -a
 -I/asp/git/src/lib/libc/tests/hash/../../../../crypto/openssh/openbsd-compat 
 -I/asp/git/src/lib/libc/tests/hash/../../../../crypto/openssh 
 -I/asp/git/src/lib/libnetbsd -I/asp/git/src/contrib/netbsd-tests -DNDEBUG 
 -std=gnu99   /asp/git/src/contrib/netbsd-tests/lib/libc/hash/t_sha2.c
 /asp/git/src/contrib/netbsd-tests/lib/libc/hash/t_sha2.c:45:10: fatal error: 
   'openssl/sha.h' file not found

For this error, maybe the following patch can be applied:

Index: lib/libc/tests/Makefile
===
--- lib/libc/tests/Makefile (revision 276057)
+++ lib/libc/tests/Makefile (working copy)
@@ -9,7 +9,6 @@
 TESTS_SUBDIRS= c063
 TESTS_SUBDIRS+=db
 TESTS_SUBDIRS+=gen
-TESTS_SUBDIRS+=hash
 TESTS_SUBDIRS+=inet
 TESTS_SUBDIRS+=net
 TESTS_SUBDIRS+=regex
@@ -29,4 +28,8 @@
 TESTS_SUBDIRS+=ssp
 .endif
 
+.if ${MK_OPENSSL} != no
+TESTS_SUBDIRS+= hash
+.endif
+
 .include bsd.test.mk

-- 
Herbert
___
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 due to WITHOUT_CRYPT (3 issues)

2014-12-24 Thread Beeblebrox

 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 with security/openssh-portable?
Nothing, I just gave dropbear as an example. This port would be preferable of 
course.

I re-started buildworld after re-enabling all crypto modules (incl
krb5) and it's now breaking at telnet:
=== libexec/telnetd (all)
cc  -O2 -pipe   -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON  -DENV_HACK 
-DSTREAMSPTY -I/asp/git/src/libexec/telnetd/../../contrib/telnet 
-I/asp/git/src/libexec/telnetd/../../contrib/telnet/telnet -DAUTHENTICATION 
-DENCRYPTION -DKRB5 -DFORWARD -Dnet_write=telnet_net_write -DNDEBUG -std=gnu99 
-fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized 
-Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch 
-Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments  -o telnetd 
global.o slc.o state.o sys_term.o telnetd.o termstat.o utility.o authenc.o 
-L/usr/obj/asp/git/src/lib/libtelnet -ltelnet  -lutil  -lncursesw  -lmp  
-lcrypto  -lpam  -lkrb5   -lroken -lpthread
/usr/obj/asp/git/src/lib/libtelnet/libtelnet.a(auth.o): In function `auth_name':
/asp/git/src/lib/libtelnet/../../contrib/telnet/libtelnet/auth.c:(.text+0x9d5): 
undefined reference to `auth_encrypt_user'
/usr/obj/asp/git/src/lib/libtelnet/libtelnet.a(sra.o): In function `sra_is':
/asp/git/src/lib/libtelnet/../../contrib/telnet/libtelnet/sra.c:(.text+0x290): 
undefined reference to `auth_encrypt_user'
cc: error: linker command failed with exit code 1 (use -v to see invocation)

Herbert: I'm going to have to delete the whole compiled mess and re-start. I'll 
apply your patch and advise the results.

-- 
FreeBSD_amd64_11-Current_RadeonKMS
___
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 due to WITHOUT_CRYPT (3 issues)

2014-12-24 Thread Beeblebrox
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  make -f 
/asp/git/src/usr.sbin/chown/tests/Makefile SUBDIR= _RECURSING_PROGS=  depend)
`chown.o' is up to date.
nc.lo: In function `_$$hide$$ nc.lo main':
(.text+0x61a): warning: warning: mktemp() possibly used unsafely; consider 
using mkstemp()
/usr/lib/libarchive.a(archive_crypto.o): In function 
`__archive_openssl_md5init':
/asp/git/src/lib/libarchive/../../contrib/libarchive/libarchive/archive_crypto.c:(.text+0xa):
 undefined reference to `EVP_md5'
/asp/git/src/lib/libarchive/../../contrib/libarchive/libarchive/archive_crypto.c:(.text+0x15):
 undefined reference to `EVP_DigestInit'
..
/usr/lib/libarchive.a(archive_crypto.o): In function 
`__archive_openssl_sha512init':
/asp/git/src/lib/libarchive/../../contrib/libarchive/libarchive/archive_crypto.c:(.text+0x1ba):
 undefined reference to `EVP_sha512'
/asp/git/src/lib/libarchive/../../contrib/libarchive/libarchive/archive_crypto.c:(.text+0x1c5):
 undefined reference to `EVP_DigestInit'
/usr/lib/libarchive.a(archive_crypto.o): In function 
`__archive_openssl_sha512update':
/asp/git/src/lib/libarchive/../../contrib/libarchive/libarchive/archive_crypto.c:(.text+0x1e5):
 undefined reference to `EVP_DigestUpdate'
/usr/lib/libarchive.a(archive_crypto.o): In function 
`__archive_openssl_sha512final':
/asp/git/src/lib/libarchive/../../contrib/libarchive/libarchive/archive_crypto.c:(.text+0x1f7):
undefined reference to `EVP_DigestFinal'

* Then LDNS broke again, so I disabled that once more:
=== lib/libldns (all)
make[5]: /usr/obj/asp/git/src/lib/libldns/.depend, 2187: ignoring stale .depend 
for /usr/obj/asp/git/src/tmp/usr/lib/libcrypto.a
building shared library libldns.so.5
/usr/obj/asp/git/src/tmp/usr/bin/ld: cannot find -lcrypto

* Finally buildworld broke at CAM
=== usr.sbin/ctld (all)
cc  -O2 -pipe   -I/asp/git/src/usr.sbin/ctld 
-I/asp/git/src/usr.sbin/ctld/../../sys 
-I/asp/git/src/usr.sbin/ctld/../../sys/cam/ctl 
-I/asp/git/src/usr.sbin/ctld/../../sys/dev/iscsi -DNDEBUG -std=gnu99 
-fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter 
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
-Wold-style-definition -Wno-pointer-sign -Wthread-safety -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c 
/asp/git/src/usr.sbin/ctld/chap.c
/asp/git/src/usr.sbin/ctld/chap.c:38:10: fatal error: 'openssl/err.h' file not
  found
#include openssl/err.h
That file has several: (#include openssl/err.h, #include openssl/md5.h, 
#include openssl/rand.h). Other that deleting the include lines, how should I 
disable those?

* At svn revision 276177

Wow I haven't had this much trouble for quite a while. I don't see a full moon, 
so it must be because of the way the planets are aligned today :(

-- 
FreeBSD_amd64_11-Current_RadeonKMS
___
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 due to WITHOUT_CRYPT (3 issues)

2014-12-24 Thread Beeblebrox
* 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/src/usr.sbin/pkg/../../contrib/libucl/include 
-DNDEBUG -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter 
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
-Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations 
-Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Qunused-arguments -c /asp/git/src/usr.sbin/pkg/pkg.c
/asp/git/src/usr.sbin/pkg/pkg.c:54:10: fatal error: 'openssl/err.h' file not 
found
#include openssl/err.h

* Buildworld finally finished, but admittedly it's plain ugly. I decided to 
post the last the process so as to help anyone who might have a similar 
experience. Whether the CRYPT code should be used from base or ports is 
debatable, but BASE does not seem ready for complete switch for these functions 
from /src to /ports.

Regards.
-- 
FreeBSD_amd64_11-Current_RadeonKMS
___
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 due to WITHOUT_CRYPT (3 issues)

2014-12-24 Thread Herbert J. Skuhra
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 others require some hacking. 

-- 
Herbert
___
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 due to WITHOUT_CRYPT (3 issues)

2014-12-24 Thread Herbert J. Skuhra
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/Makefile SUBDIR+= pkg
 === usr.sbin/pkg (all)
 cc  -O2 -pipe   -I/asp/git/src/usr.sbin/pkg/../../contrib/libucl/include 
 -DNDEBUG -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k 
 -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes 
 -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow 
 -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs 
 -Wredundant-decls -Wold-style-definition -Wno-pointer-sign 
 -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body 
 -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c 
 /asp/git/src/usr.sbin/pkg/pkg.c
 /asp/git/src/usr.sbin/pkg/pkg.c:54:10: fatal error: 'openssl/err.h' file not 
 found
 #include openssl/err.h

Have you tried to set WITHOUT_PKGBOOTSTRAP?

-- 
Herbert
___
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 due to WITHOUT_CRYPT (3 issues)

2014-12-24 Thread Beeblebrox
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 -std=gnu99 
-fstack-protector   -Qunused-arguments -c compare.c
compare.c:61:10: fatal error: 'rmd160.h' file not found
#include rmd160.h

That file seems to be one of sys/opencrypto/rmd160.h or lib/libnetbsd/rmd160.h, 
but at this point I'm stumped. Did this have anything to do with Herbert's 
patch? 
I had cleaned out my poudriere amd64 jail, and mtree is needed for pkg 
building. I finally resorted to copying the two-week old mtree binary from 
/usr/sbin to the poudriere jail.

-- 
FreeBSD_amd64_11-Current_RadeonKMS
___
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 (missing /usr/share/mk/src.opts.mk)

2014-05-06 Thread Stefan Esser
Am 06.05.2014 11:52, schrieb Stefan Esser:
 Hi Warner,
 
 as already reported by Jenkins, HEAD does not build.
 
 Seems that this is caused by src.opts.mk missing in /usr/share/mk
 during the cleandir phase. I guess this is kind of a bootstrap
 issue - the definitions are looked up in the installed base, not
 in the src tree - but did not verify this assumption.
 
 A work-around is to manually install src.opts.mk:
 
 # make -C /usr/src/share/mk install
 
 (which might deserve an UPDATING entry). Falling back on the file
 in the src directory might be a better solution ...
 
 Regards, STefan

Following up to my earlier mail:

The diagnosis was wrong - the main Makefiles include src.opts.mk from
the source directory. But two sub-ordinate Makefiles missed to include
the new options file (sys/conf/kmod.mk and sys/modules/drm2/Makefile).

I committed a fix/work-around to stop the flood of tinderbox messages
(r265433).

Regards, STefan
___
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 (missing /usr/share/mk/src.opts.mk)

2014-05-06 Thread Trond Endrestøl
On Tue, 6 May 2014 13:24+0200, Stefan Esser wrote:

 Am 06.05.2014 11:52, schrieb Stefan Esser:
  Hi Warner,
  
  as already reported by Jenkins, HEAD does not build.
  
  Seems that this is caused by src.opts.mk missing in /usr/share/mk
  during the cleandir phase. I guess this is kind of a bootstrap
  issue - the definitions are looked up in the installed base, not
  in the src tree - but did not verify this assumption.
  
  A work-around is to manually install src.opts.mk:
  
  # make -C /usr/src/share/mk install
  
  (which might deserve an UPDATING entry). Falling back on the file
  in the src directory might be a better solution ...
  
  Regards, STefan
 
 Following up to my earlier mail:
 
 The diagnosis was wrong - the main Makefiles include src.opts.mk from
 the source directory. But two sub-ordinate Makefiles missed to include
 the new options file (sys/conf/kmod.mk and sys/modules/drm2/Makefile).
 
 I committed a fix/work-around to stop the flood of tinderbox messages
 (r265433).

tinderbox still complains about usr.bin/bmake/Makefile.inc.

-- 
+---++
| Vennlig hilsen,   | Best regards,  |
| Trond Endrestøl,  | Trond Endrestøl,   |
| IT-ansvarlig, | System administrator,  |
| Fagskolen Innlandet,  | Gjøvik Technical College, Norway,  |
| tlf. mob.   952 62 567,   | Cellular...: +47 952 62 567,   |
| sentralbord 61 14 54 00.  | Switchboard: +47 61 14 54 00.  |
+---++
___
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 (missing /usr/share/mk/src.opts.mk)

2014-05-06 Thread Stefan Esser
Am 06.05.2014 13:44, schrieb Trond Endrestøl:
 On Tue, 6 May 2014 13:24+0200, Stefan Esser wrote:
 Am 06.05.2014 11:52, schrieb Stefan Esser:
 Hi Warner,

 as already reported by Jenkins, HEAD does not build.

 Seems that this is caused by src.opts.mk missing in /usr/share/mk
 during the cleandir phase. I guess this is kind of a bootstrap
 issue - the definitions are looked up in the installed base, not
 in the src tree - but did not verify this assumption.

 A work-around is to manually install src.opts.mk:

 # make -C /usr/src/share/mk install

 (which might deserve an UPDATING entry). Falling back on the file
 in the src directory might be a better solution ...

 Regards, STefan

 Following up to my earlier mail:

 The diagnosis was wrong - the main Makefiles include src.opts.mk from
 the source directory. But two sub-ordinate Makefiles missed to include
 the new options file (sys/conf/kmod.mk and sys/modules/drm2/Makefile).

 I committed a fix/work-around to stop the flood of tinderbox messages
 (r265433).
 
 tinderbox still complains about usr.bin/bmake/Makefile.inc.

Hmmm, I managed to buildworld -HEAD after this patch, but it is
possible, that I had src.opts.mk installed in /usr/share/mk when
I started the build.

(I later deleted it, to be sure that the version in the source
directory was found and used when building modules, which the
commit actually fixed.)

I guess the remaining problem is caused by

.include src.opts.mk

in line 3 of src/usr.bin/bmake/Makefile.inc

Changing this line to read .include src.opts.mk seems to fix
it on my system.

--- usr.bin/bmake/Makefile.inc~
+++ usr.bin/bmake/Makefile.inc
@@ -1,6 +1,6 @@
 # $FreeBSD$

-.include src.opts.mk
+.include src.opts.mk

 .if defined(.PARSEDIR)
 # make sure this is available to unit-tests/Makefile

It is possible, that the build will still fail at a latter stage,
though (buildworld is still running).

I committed the above patch, since it gets buildworld through the
bmake subdirectory at least (r265436). If buildworld fails again,
then I'll commit any further missing fixes in one go. I'll know
in some 20 minutes.

Regards, STefan
___
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 (missing /usr/share/mk/src.opts.mk)

2014-05-06 Thread Warner Losh

On May 6, 2014, at 6:39 AM, Stefan Esser s...@freebsd.org wrote:

 Am 06.05.2014 13:44, schrieb Trond Endrestøl:
 On Tue, 6 May 2014 13:24+0200, Stefan Esser wrote:
 Am 06.05.2014 11:52, schrieb Stefan Esser:
 Hi Warner,
 
 as already reported by Jenkins, HEAD does not build.
 
 Seems that this is caused by src.opts.mk missing in /usr/share/mk
 during the cleandir phase. I guess this is kind of a bootstrap
 issue - the definitions are looked up in the installed base, not
 in the src tree - but did not verify this assumption.
 
 A work-around is to manually install src.opts.mk:
 
 # make -C /usr/src/share/mk install
 
 (which might deserve an UPDATING entry). Falling back on the file
 in the src directory might be a better solution ...
 
 Regards, STefan
 
 Following up to my earlier mail:
 
 The diagnosis was wrong - the main Makefiles include src.opts.mk from
 the source directory. But two sub-ordinate Makefiles missed to include
 the new options file (sys/conf/kmod.mk and sys/modules/drm2/Makefile).
 
 I committed a fix/work-around to stop the flood of tinderbox messages
 (r265433).
 
 tinderbox still complains about usr.bin/bmake/Makefile.inc.
 
 Hmmm, I managed to buildworld -HEAD after this patch, but it is
 possible, that I had src.opts.mk installed in /usr/share/mk when
 I started the build.
 
 (I later deleted it, to be sure that the version in the source
 directory was found and used when building modules, which the
 commit actually fixed.)
 
 I guess the remaining problem is caused by
 
 .include src.opts.mk
 
 in line 3 of src/usr.bin/bmake/Makefile.inc
 
 Changing this line to read .include src.opts.mk seems to fix
 it on my system.
 
 --- usr.bin/bmake/Makefile.inc~
 +++ usr.bin/bmake/Makefile.inc
 @@ -1,6 +1,6 @@
 # $FreeBSD$
 
 -.include src.opts.mk
 +.include src.opts.mk
 
 .if defined(.PARSEDIR)
 # make sure this is available to unit-tests/Makefile
 
 It is possible, that the build will still fail at a latter stage,
 though (buildworld is still running).
 
 I committed the above patch, since it gets buildworld through the
 bmake subdirectory at least (r265436). If buildworld fails again,
 then I'll commit any further missing fixes in one go. I'll know
 in some 20 minutes.

What is your source system? This is absolutely the wrong change, and shouldn’t 
be necessary at all. These changes survived a universe run and a few build 
worlds on other systems.

Warner


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: buildworld fails (missing /usr/share/mk/src.opts.mk)

2014-05-06 Thread Warner Losh

On May 6, 2014, at 7:16 AM, Warner Losh i...@bsdimp.com wrote:

 
 On May 6, 2014, at 6:39 AM, Stefan Esser s...@freebsd.org wrote:
 
 Am 06.05.2014 13:44, schrieb Trond Endrestøl:
 On Tue, 6 May 2014 13:24+0200, Stefan Esser wrote:
 Am 06.05.2014 11:52, schrieb Stefan Esser:
 Hi Warner,
 
 as already reported by Jenkins, HEAD does not build.
 
 Seems that this is caused by src.opts.mk missing in /usr/share/mk
 during the cleandir phase. I guess this is kind of a bootstrap
 issue - the definitions are looked up in the installed base, not
 in the src tree - but did not verify this assumption.
 
 A work-around is to manually install src.opts.mk:
 
 # make -C /usr/src/share/mk install
 
 (which might deserve an UPDATING entry). Falling back on the file
 in the src directory might be a better solution ...
 
 Regards, STefan
 
 Following up to my earlier mail:
 
 The diagnosis was wrong - the main Makefiles include src.opts.mk from
 the source directory. But two sub-ordinate Makefiles missed to include
 the new options file (sys/conf/kmod.mk and sys/modules/drm2/Makefile).
 
 I committed a fix/work-around to stop the flood of tinderbox messages
 (r265433).
 
 tinderbox still complains about usr.bin/bmake/Makefile.inc.
 
 Hmmm, I managed to buildworld -HEAD after this patch, but it is
 possible, that I had src.opts.mk installed in /usr/share/mk when
 I started the build.
 
 (I later deleted it, to be sure that the version in the source
 directory was found and used when building modules, which the
 commit actually fixed.)
 
 I guess the remaining problem is caused by
 
 .include src.opts.mk
 
 in line 3 of src/usr.bin/bmake/Makefile.inc
 
 Changing this line to read .include src.opts.mk seems to fix
 it on my system.
 
 --- usr.bin/bmake/Makefile.inc~
 +++ usr.bin/bmake/Makefile.inc
 @@ -1,6 +1,6 @@
 # $FreeBSD$
 
 -.include src.opts.mk
 +.include src.opts.mk
 
 .if defined(.PARSEDIR)
 # make sure this is available to unit-tests/Makefile
 
 It is possible, that the build will still fail at a latter stage,
 though (buildworld is still running).
 
 I committed the above patch, since it gets buildworld through the
 bmake subdirectory at least (r265436). If buildworld fails again,
 then I'll commit any further missing fixes in one go. I'll know
 in some 20 minutes.
 
 What is your source system? This is absolutely the wrong change, and 
 shouldn’t be necessary at all. These changes survived a universe run and a 
 few build worlds on other systems.

hit send too fast

so I’d like to know how to recreate it, since I didn’t see this in any of my 
testing over the last two weeks...

 Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: buildworld fails (missing /usr/share/mk/src.opts.mk)

2014-05-06 Thread Stefan Esser
Am 06.05.2014 14:39, schrieb Stefan Esser:
 Am 06.05.2014 13:44, schrieb Trond Endrestøl:
 On Tue, 6 May 2014 13:24+0200, Stefan Esser wrote:
 Am 06.05.2014 11:52, schrieb Stefan Esser:
 I committed a fix/work-around to stop the flood of tinderbox messages
 (r265433).

 tinderbox still complains about usr.bin/bmake/Makefile.inc.
 
 Hmmm, I managed to buildworld -HEAD after this patch, but it is
 possible, that I had src.opts.mk installed in /usr/share/mk when
 I started the build.
 
 (I later deleted it, to be sure that the version in the source
 directory was found and used when building modules, which the
 commit actually fixed.)
 
 I guess the remaining problem is caused by
 
 .include src.opts.mk
 
 in line 3 of src/usr.bin/bmake/Makefile.inc
 
 Changing this line to read .include src.opts.mk seems to fix
 it on my system.
 
 --- usr.bin/bmake/Makefile.inc~
 +++ usr.bin/bmake/Makefile.inc
 @@ -1,6 +1,6 @@
  # $FreeBSD$
 
 -.include src.opts.mk
 +.include src.opts.mk
 
  .if defined(.PARSEDIR)
  # make sure this is available to unit-tests/Makefile
 
 It is possible, that the build will still fail at a latter stage,
 though (buildworld is still running).
 
 I committed the above patch, since it gets buildworld through the
 bmake subdirectory at least (r265436). If buildworld fails again,
 then I'll commit any further missing fixes in one go. I'll know
 in some 20 minutes.

My -HEAD buildworld completed without error for r265436,
but the tinderbox still complains at r265439.

When I had looked for the cause of the build errors, I had
modified several other Makefiles, but I reverted all these
temporary changes before the last buildworld, which succeeded.
(I had added -I $(.CURDIR)/share/mk to several invocations
of sub-make processes, but I checked - these are removed and
already were, during the successful buildworld.)

I cannot reproduce the failure in buildworld, even after
deleting the src.opts.mk from /usr/share/mk to reproduce
a system before that file gets installed.


But if I just go to usr.bin/bmake and try to build it on
a system without already installed src.opts.mk, I get the
error reported by tinderbox.


Reverting r265436 seems to help: make -I /usr/src/share/mk
in src/usr.bin/bmake finds src.opts.mk in the source directory.

But I added that patch as the final step required to fix
buildworld on my system ...

I'll see whether the build completes with r265436 reverted
and will back this commit out, if successful.

Regards, STefan
___
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 (missing /usr/share/mk/src.opts.mk)

2014-05-06 Thread Stefan Esser
Am 06.05.2014 15:18, schrieb Warner Losh:
 
 On May 6, 2014, at 7:16 AM, Warner Losh i...@bsdimp.com wrote:
 
 
 On May 6, 2014, at 6:39 AM, Stefan Esser s...@freebsd.org wrote:
 
 Am 06.05.2014 13:44, schrieb Trond Endrestøl:
 On Tue, 6 May 2014 13:24+0200, Stefan Esser wrote:
 Am 06.05.2014 11:52, schrieb Stefan Esser:
 Hi Warner,
 
 as already reported by Jenkins, HEAD does not build.
 
 Seems that this is caused by src.opts.mk missing in
 /usr/share/mk during the cleandir phase. I guess this is
 kind of a bootstrap issue - the definitions are looked up
 in the installed base, not in the src tree - but did not
 verify this assumption.
 
 A work-around is to manually install src.opts.mk:
 
 # make -C /usr/src/share/mk install
 
 (which might deserve an UPDATING entry). Falling back on
 the file in the src directory might be a better solution
 ...
 
 Regards, STefan
 
 Following up to my earlier mail:
 
 The diagnosis was wrong - the main Makefiles include
 src.opts.mk from the source directory. But two sub-ordinate
 Makefiles missed to include the new options file
 (sys/conf/kmod.mk and sys/modules/drm2/Makefile).
 
 I committed a fix/work-around to stop the flood of
 tinderbox messages (r265433).
 
 tinderbox still complains about usr.bin/bmake/Makefile.inc.
 
 Hmmm, I managed to buildworld -HEAD after this patch, but it
 is possible, that I had src.opts.mk installed in /usr/share/mk
 when I started the build.
 
 (I later deleted it, to be sure that the version in the source 
 directory was found and used when building modules, which the 
 commit actually fixed.)
 
 I guess the remaining problem is caused by
 
 .include src.opts.mk
 
 in line 3 of src/usr.bin/bmake/Makefile.inc
 
 Changing this line to read .include src.opts.mk seems to
 fix it on my system.
 
 --- usr.bin/bmake/Makefile.inc~ +++ usr.bin/bmake/Makefile.inc 
 @@ -1,6 +1,6 @@ # $FreeBSD$
 
 -.include src.opts.mk +.include src.opts.mk
 
 .if defined(.PARSEDIR) # make sure this is available to
 unit-tests/Makefile
 
 It is possible, that the build will still fail at a latter
 stage, though (buildworld is still running).
 
 I committed the above patch, since it gets buildworld through
 the bmake subdirectory at least (r265436). If buildworld fails
 again, then I'll commit any further missing fixes in one go.
 I'll know in some 20 minutes.
 
 What is your source system? This is absolutely the wrong change,
 and shouldn’t be necessary at all. These changes survived a
 universe run and a few build worlds on other systems.

I'm on a fresh -CURRENT (built the previous day) and with sources
as of r265439.

I agree, that the change to bmake/Makefile.inc was wrong - though
it was needed to get a make cleandir working in that directory.

 hit send too fast
 
 so I’d like to know how to recreate it, since I didn’t see this in
 any of my testing over the last two weeks...

The tinderbox builds all fail in bmake, and while I changed
Makefile.inc to fix just that kind of problem on my system, it
may have worked by accident (because of a forgotten src.opts.mk
in /usr/share/mk - it had been installed by a previous attempt
to work around these problems).

To recapitulate the order of events:

1) make buildkernel failed due to 2 missing includes of
   src.opts.mk. The affected files files were:

sys/conf/kmod.mk
sys/modules/drm2/Makefile

   Adding an .include src.opts.mk seems to have fixed this
   problem. Maybe src.opts.mk would have been more correct,
   but I checked without src.opts.mk in /usr/share/mk and the
   file was found in src/share/mk.

2) tinderbox still complained about the test for MK_SHARED_TOOLCHAIN
   in bmake/Makefile.inc (I deleted the mails and thus cannot
   easily quote the exact error message). I tried to fix this by
   changing the include syntax in bmake/Makefile.inc, but have
   just reverted this change. It made buildworld complete on my
   system, but tinderbox complains loudly.

A work-around for the second problem is to manually install
src.opts.mk in /usr/share/mk before attempting to build bmake.

Regards, STefan
___
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 (missing /usr/share/mk/src.opts.mk)

2014-05-06 Thread Benjamin Kaduk

On Tue, 6 May 2014, Stefan Esser wrote:



2) tinderbox still complained about the test for MK_SHARED_TOOLCHAIN
  in bmake/Makefile.inc (I deleted the mails and thus cannot
  easily quote the exact error message). I tried to fix this by


http://lists.freebsd.org/pipermail/freebsd-current/2014-May/049744.html

-Ben

___
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 (missing /usr/share/mk/src.opts.mk)

2014-05-06 Thread Stefan Esser
Am 06.05.2014 16:15, schrieb Benjamin Kaduk:
 On Tue, 6 May 2014, Stefan Esser wrote:
 2) tinderbox still complained about the test for MK_SHARED_TOOLCHAIN
   in bmake/Makefile.inc (I deleted the mails and thus cannot
   easily quote the exact error message). I tried to fix this by
 
 http://lists.freebsd.org/pipermail/freebsd-current/2014-May/049744.html

Hi Ben,

thank you for the link, I did not know that the messages are archived
in real-time ...

Hmm, I was sure that there was a problem with MK_SHARED_TOOLCHAIN or
some other variable defined in src.opts.mk. I just checked my shell
history, and it must have been SOURCELESS_UCODE and MK_KERNEL_SYMBOLS
(which both made buildkernel fail).

Regards, STefan
___
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 (missing /usr/share/mk/src.opts.mk)

2014-05-06 Thread Warner Losh
First off, thanks for looking into this. Build issues are no fun. :(

On May 6, 2014, at 8:11 AM, Stefan Esser s...@freebsd.org wrote:

 Am 06.05.2014 15:18, schrieb Warner Losh:
 
 On May 6, 2014, at 7:16 AM, Warner Losh i...@bsdimp.com wrote:
 
 
 On May 6, 2014, at 6:39 AM, Stefan Esser s...@freebsd.org wrote:
 
 Am 06.05.2014 13:44, schrieb Trond Endrestøl:
 On Tue, 6 May 2014 13:24+0200, Stefan Esser wrote:
 Am 06.05.2014 11:52, schrieb Stefan Esser:
 Hi Warner,
 
 as already reported by Jenkins, HEAD does not build.
 
 Seems that this is caused by src.opts.mk missing in
 /usr/share/mk during the cleandir phase. I guess this is
 kind of a bootstrap issue - the definitions are looked up
 in the installed base, not in the src tree - but did not
 verify this assumption.
 
 A work-around is to manually install src.opts.mk:
 
 # make -C /usr/src/share/mk install
 
 (which might deserve an UPDATING entry). Falling back on
 the file in the src directory might be a better solution
 ...
 
 Regards, STefan
 
 Following up to my earlier mail:
 
 The diagnosis was wrong - the main Makefiles include
 src.opts.mk from the source directory. But two sub-ordinate
 Makefiles missed to include the new options file
 (sys/conf/kmod.mk and sys/modules/drm2/Makefile).
 
 I committed a fix/work-around to stop the flood of
 tinderbox messages (r265433).
 
 tinderbox still complains about usr.bin/bmake/Makefile.inc.
 
 Hmmm, I managed to buildworld -HEAD after this patch, but it
 is possible, that I had src.opts.mk installed in /usr/share/mk
 when I started the build.
 
 (I later deleted it, to be sure that the version in the source 
 directory was found and used when building modules, which the 
 commit actually fixed.)
 
 I guess the remaining problem is caused by
 
 .include src.opts.mk
 
 in line 3 of src/usr.bin/bmake/Makefile.inc
 
 Changing this line to read .include src.opts.mk seems to
 fix it on my system.
 
 --- usr.bin/bmake/Makefile.inc~ +++ usr.bin/bmake/Makefile.inc 
 @@ -1,6 +1,6 @@ # $FreeBSD$
 
 -.include src.opts.mk +.include src.opts.mk

This change I think actually is right. And it needs to be an ‘sinclude’
to support the fmake upgrade path, but I need to double check that
can’t be worked around in the environment.

 .if defined(.PARSEDIR) # make sure this is available to
 unit-tests/Makefile
 
 It is possible, that the build will still fail at a latter
 stage, though (buildworld is still running).
 
 I committed the above patch, since it gets buildworld through
 the bmake subdirectory at least (r265436). If buildworld fails
 again, then I'll commit any further missing fixes in one go.
 I'll know in some 20 minutes.
 
 What is your source system? This is absolutely the wrong change,
 and shouldn’t be necessary at all. These changes survived a
 universe run and a few build worlds on other systems.
 
 I'm on a fresh -CURRENT (built the previous day) and with sources
 as of r265439.

OK. My current is a bit dated, so I’ll spin up a new one.

 I agree, that the change to bmake/Makefile.inc was wrong - though
 it was needed to get a make cleandir working in that directory.

Yea, I’m trying to get one that works all the time… I think I have it
which should silence the tinderboxes…  In hind sight, perhaps
I should have pushed this in first thing this morning rather than
last thing last night...

 hit send too fast
 
 so I’d like to know how to recreate it, since I didn’t see this in
 any of my testing over the last two weeks...
 
 The tinderbox builds all fail in bmake, and while I changed
 Makefile.inc to fix just that kind of problem on my system, it
 may have worked by accident (because of a forgotten src.opts.mk
 in /usr/share/mk - it had been installed by a previous attempt
 to work around these problems).

The initial bootstrap of bmake, or the later build of bmake? I was
able to reproduce the former, but haven’t seen the latter fail.

 To recapitulate the order of events:
 
 1) make buildkernel failed due to 2 missing includes of
   src.opts.mk. The affected files files were:
 
   sys/conf/kmod.mk
   sys/modules/drm2/Makefile
 
   Adding an .include src.opts.mk seems to have fixed this
   problem. Maybe src.opts.mk would have been more correct,
   but I checked without src.opts.mk in /usr/share/mk and the
   file was found in src/share/mk.

I’ll look at these. I might have introduced the issues after I stopped
building the 75 kernels in make universe after I made it through once.
My bad...

 2) tinderbox still complained about the test for MK_SHARED_TOOLCHAIN
   in bmake/Makefile.inc (I deleted the mails and thus cannot
   easily quote the exact error message). I tried to fix this by
   changing the include syntax in bmake/Makefile.inc, but have
   just reverted this change. It made buildworld complete on my
   system, but tinderbox complains loudly.

I’ll look at this as well...

 A work-around for the second problem is to manually install
 src.opts.mk in /usr/share/mk before attempting to build 

Re: buildworld fails (missing /usr/share/mk/src.opts.mk)

2014-05-06 Thread Warner Losh

On May 6, 2014, at 8:15 AM, Benjamin Kaduk ka...@mit.edu wrote:

 On Tue, 6 May 2014, Stefan Esser wrote:
 
 
 2) tinderbox still complained about the test for MK_SHARED_TOOLCHAIN
  in bmake/Makefile.inc (I deleted the mails and thus cannot
  easily quote the exact error message). I tried to fix this by
 
 http://lists.freebsd.org/pipermail/freebsd-current/2014-May/049744.html

A fix for this is pending a full buildworld run, so 20 minutes.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: buildworld fails (missing /usr/share/mk/src.opts.mk)

2014-05-06 Thread Stefan Esser
Am 06.05.2014 16:28, schrieb Warner Losh:
 First off, thanks for looking into this. Build issues are no fun. :(
 On May 6, 2014, at 8:11 AM, Stefan Esser s...@freebsd.org wrote:
 Am 06.05.2014 15:18, schrieb Warner Losh:
 On May 6, 2014, at 7:16 AM, Warner Losh i...@bsdimp.com wrote:
 On May 6, 2014, at 6:39 AM, Stefan Esser s...@freebsd.org wrote:
 Am 06.05.2014 13:44, schrieb Trond Endrestøl:
 On Tue, 6 May 2014 13:24+0200, Stefan Esser wrote:
 Am 06.05.2014 11:52, schrieb Stefan Esser:
 tinderbox still complains about usr.bin/bmake/Makefile.inc.

 Hmmm, I managed to buildworld -HEAD after this patch, but it
 is possible, that I had src.opts.mk installed in /usr/share/mk
 when I started the build.

 (I later deleted it, to be sure that the version in the source 
 directory was found and used when building modules, which the 
 commit actually fixed.)

 I guess the remaining problem is caused by

 .include src.opts.mk

 in line 3 of src/usr.bin/bmake/Makefile.inc

 Changing this line to read .include src.opts.mk seems to
 fix it on my system.

 --- usr.bin/bmake/Makefile.inc~ +++ usr.bin/bmake/Makefile.inc 
 @@ -1,6 +1,6 @@ # $FreeBSD$

 -.include src.opts.mk +.include src.opts.mk
 
 This change I think actually is right. And it needs to be an ‘sinclude’
 to support the fmake upgrade path, but I need to double check that
 can’t be worked around in the environment.

Yes, the upgrade path is broken and that is what the tinderbox builds
complain about.

I just verified this by installing fmake as make on -HEAD. It fails
to build bmake as reported by tinderbox.

 What is your source system? This is absolutely the wrong change,
 and shouldn’t be necessary at all. These changes survived a
 universe run and a few build worlds on other systems.

 I'm on a fresh -CURRENT (built the previous day) and with sources
 as of r265439.
 
 OK. My current is a bit dated, so I’ll spin up a new one.

I guess there are less problems when starting with -CURRENT than if
you come from 9-STABLE, so that appears to be the better test.

 I agree, that the change to bmake/Makefile.inc was wrong - though
 it was needed to get a make cleandir working in that directory.
 
 Yea, I’m trying to get one that works all the time… I think I have it
 which should silence the tinderboxes…  In hind sight, perhaps
 I should have pushed this in first thing this morning rather than
 last thing last night...

Well, it was early morning in this part of the world, when the
tinderbox mails started to arrive ;-)

But the change (separation of src options and corresponding logic)
is definitely worth the nuisance of temporary breakage ...

 hit send too fast

 so I’d like to know how to recreate it, since I didn’t see this in
 any of my testing over the last two weeks...

 The tinderbox builds all fail in bmake, and while I changed
 Makefile.inc to fix just that kind of problem on my system, it
 may have worked by accident (because of a forgotten src.opts.mk
 in /usr/share/mk - it had been installed by a previous attempt
 to work around these problems).
 
 The initial bootstrap of bmake, or the later build of bmake? I was
 able to reproduce the former, but haven’t seen the latter fail.

Yes, it always seems to be the initial build that fails. And that
phase is skipped on systems with a usable bmake ...

 To recapitulate the order of events:

 1) make buildkernel failed due to 2 missing includes of
   src.opts.mk. The affected files files were:

  sys/conf/kmod.mk
  sys/modules/drm2/Makefile

   Adding an .include src.opts.mk seems to have fixed this
   problem. Maybe src.opts.mk would have been more correct,
   but I checked without src.opts.mk in /usr/share/mk and the
   file was found in src/share/mk.
 
 I’ll look at these. I might have introduced the issues after I stopped
 building the 75 kernels in make universe after I made it through once.
 My bad...
 
 2) tinderbox still complained about the test for MK_SHARED_TOOLCHAIN
   in bmake/Makefile.inc (I deleted the mails and thus cannot
   easily quote the exact error message). I tried to fix this by
   changing the include syntax in bmake/Makefile.inc, but have
   just reverted this change. It made buildworld complete on my
   system, but tinderbox complains loudly.
 
 I’ll look at this as well...
 
 A work-around for the second problem is to manually install
 src.opts.mk in /usr/share/mk before attempting to build bmake.
 
 Yea, and we don’t really want to do that. The other workaround is
 mentioned in updating… Setting MAKESYSPATH. I need to make
 sure my testing wasn’t contaminated with this somehow.

Ahh, I missed that entry in UPDATING ...

But if I had read it, I'd missed the hint that MAKESYSPATH can be
used to unbreak buildworld. The text just mentions incremental
builds.

Anyway, if .sinclude src.opts.mk really works in all cases, all
should be good again :)

Regards, STefan
___
freebsd-current@freebsd.org mailing list

Re: buildworld fails with Zero byte read from file, skipping rest of line

2014-02-08 Thread Michael Butler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/15/14 03:40, Gleb Smirnoff wrote:
   Jeremie,
 
 On Wed, Jan 15, 2014 at 08:40:53AM +0100, Jeremie Le Hen wrote:
 J  J   === gnu/usr.bin/groff/src/libs/libgroff (all)
 J  J   make[6]: 
 /usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend
  line 3: warning: Zero byte read from file, skipping rest of line.
 J  J   make[6]: 
 /usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend
  line 3: Need an operator
 J  J   make[6]: 
 /usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend
  line 4: Need an operator
 J  J   make[6]: Fatal errors encountered -- cannot continue
 J  J   make[6]: stopped in /usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff
 J  J   *** [all] Error code 1
 J  J 
 J  J Typscript available here:
 J  J http://people.freebsd.org/~jlh/typescript.buildworld.txt
 J  J 
 J  J Any ideas?
 J  
 J  Can you try to reproduce this with unmapped I/O turned off in boot 
 loader?
 J 
 J I've never heard of that.  Can you please point me to the right
 J code/doc?
 
 In loader prompt:
 
 OK set vfs.unmapped_buf_allowed=0
 OK boot

I'm seeing this on a non-virtualized laptop.

Core Duo T2300 (1.8GHz Prescott architecture)

Occurs randomly with either IDE or AHCI enabled on ICH-7 or on a USB
external drive.

Seems to only occur under heavy loads such as recompiling libreoffice,
KDE or similar.

Maybe a race condition in buffer management?

imb


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlL2j/kACgkQQv9rrgRC1JJADgCfb4sPmsA1F2HZm3HEJdCCtw43
u9AAoMpEmC94skFsLpCSWbulY1epWtk3
=aewU
-END PGP SIGNATURE-
___
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


-CURRENT on VBox is broken (was: Re: buildworld fails with Zero byte read from file, skipping rest) of line

2014-02-07 Thread Jeremie Le Hen
On Wed, Jan 15, 2014 at 12:36:53PM +0100, Jeremie Le Hen wrote:
 On Wed, Jan 15, 2014 at 12:40:35PM +0400, Gleb Smirnoff wrote:
  J  
  J  Can you try to reproduce this with unmapped I/O turned off in boot 
  loader?
  J 
  J I've never heard of that.  Can you please point me to the right
  J code/doc?
  
  In loader prompt:
  
  OK set vfs.unmapped_buf_allowed=0
  OK boot
 
 No, unfortunately I still have the same problem without unmapped bufs.

Ok, I'm back to try to try building world on VirtualBox with a recent
-CURRENT.

So, on a new workstation, I've installed a new VirtualBox, downloaded
the latest i386 snapshot and installed it:
FreeBSD-11.0-CURRENT-i386-20140203-r261419-disc1.iso

Things started to be shady when I tried to build and install
ports-mgmt/pkg:

% install -s -o root -g wheel -m 555   pkg-static 
/usr/ports/ports-mgmt/pkg/work/stage/usr/local/sbin/pkg-static
% strip: /usr/ports/ports-mgmt/pkg/work/stage/usr/local/sbin/pkg-static: File 
format not recognized

So I tried to disallow VFS unmapped bufs as you advised me and this
seems to have solved the problem (but maybe by chance, see below).


Now I'm still running with vfs.unmapped_buf_allowed=0, I installed all
the ports I need for basic development.  I fetched freebsd-src from
GitHub and tried to build world...  And now it's started to be very
wacky: it failed, multiple times, but never at the same place (I removed
/usr/obj/* between each run).

There is at least something consistent, it always fails with the same
error .../.depend: Zero byte read from file, skipping rest of line.:

% [jlh@freefall ~/www/wacky_buildworld_on_vbox]$ grep -B 1 -A 5 'warning: Zero 
byte read from file' *  
   
% typescript.fail1.txt-TMP=_depend$$;  sed -e 's/^\([^\.]*\).o[ ]*:/\1.o \1.po 
\1.So:/'  .depend   $TMP;  mv $TMP .depend
% typescript.fail1.txt:make[4]: 
/usr/obj/usr/src/kerberos5/lib/libheimbase/.depend line 3: warning: Zero byte 
read from file, skipping rest of line.
% typescript.fail1.txt-make[4]: 
/usr/obj/usr/src/kerberos5/lib/libheimbase/.depend line 3: Need an operator
% typescript.fail1.txt-make[4]: 
/usr/obj/usr/src/kerberos5/lib/libheimbase/.depend line 4: Need an operator
% typescript.fail1.txt-make[4]: Fatal errors encountered -- cannot continue
% typescript.fail1.txt-make[4]: stopped in /usr/src/kerberos5/lib/libheimbase
% typescript.fail1.txt-*** Error code 1
% --
% typescript.fail2.txt-TMP=_depend$$;  sed -e 's/^\([^\.]*\).o[ ]*:/\1.o \1.po 
\1.So:/'  .depend   $TMP;  mv $TMP .depend
% typescript.fail2.txt:make[3]: 
/usr/obj/usr/src/tmp/usr/src/kerberos5/lib/libvers/.depend line 3: warning: 
Zero byte read from file, skipping rest of line.
% typescript.fail2.txt-make[3]: 
/usr/obj/usr/src/tmp/usr/src/kerberos5/lib/libvers/.depend line 3: Need an 
operator
% typescript.fail2.txt-make[3]: 
/usr/obj/usr/src/tmp/usr/src/kerberos5/lib/libvers/.depend line 4: Need an 
operator
% typescript.fail2.txt-make[3]: Fatal errors encountered -- cannot continue
% typescript.fail2.txt-make[3]: stopped in /usr/src/kerberos5/lib/libvers
% typescript.fail2.txt-*** Error code 1
% --
% typescript.fail3.txt-echo libroken.so.11: 
/usr/obj/usr/src/tmp/usr/lib/libcrypt.a  .depend
% typescript.fail3.txt:make[4]: 
/usr/obj/usr/src/kerberos5/lib/libroken/.depend line 3: warning: Zero byte 
read from file, skipping rest of line.
% typescript.fail3.txt-make[4]: 
/usr/obj/usr/src/kerberos5/lib/libroken/.depend line 3: Need an operator
% typescript.fail3.txt-make[4]: 
/usr/obj/usr/src/kerberos5/lib/libroken/.depend line 4: Unknown directive
% typescript.fail3.txt-make[4]: Fatal errors encountered -- cannot continue
% typescript.fail3.txt-make[4]: stopped in /usr/src/kerberos5/lib/libroken
% typescript.fail3.txt-*** Error code 1
% --
% typescript.fail4.txt-echo asn1_compile: /usr/lib/libc.a 
/usr/obj/usr/src/tmp/usr/src/kerberos5/tools/asn1_compile/../../lib/libroken/libroken.a
 
/usr/obj/usr/src/tmp/usr/src/kerberos5/tools/asn1_compile/../../lib/libvers/libvers.a
 /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a  .depend
% typescript.fail4.txt:make[3]: 
/usr/obj/usr/src/tmp/usr/src/kerberos5/tools/asn1_compile/.depend line 3: 
warning: Zero byte read from file, skipping rest of line.
% typescript.fail4.txt-make[3]: 
/usr/obj/usr/src/tmp/usr/src/kerberos5/tools/asn1_compile/.depend line 3: 
Need an operator
% typescript.fail4.txt-make[3]: 
/usr/obj/usr/src/tmp/usr/src/kerberos5/tools/asn1_compile/.depend line 4: 
Need an operator
% typescript.fail4.txt-make[3]: Fatal errors encountered -- cannot continue
% typescript.fail4.txt-make[3]: stopped in /usr/src/kerberos5/tools/asn1_compile




Any idea how to debug this?

-- 
Jeremie Le Hen

Scientists say the world is made up of Protons, Neutrons and Electrons.
They forgot to mention Morons.
___
freebsd-current@freebsd.org mailing list

Re: buildworld fails with Zero byte read from file, skipping rest of line

2014-01-15 Thread Gleb Smirnoff
  Jeremie,

On Wed, Jan 15, 2014 at 08:40:53AM +0100, Jeremie Le Hen wrote:
J  J   === gnu/usr.bin/groff/src/libs/libgroff (all)
J  J   make[6]: 
/usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend
 line 3: warning: Zero byte read from file, skipping rest of line.
J  J   make[6]: 
/usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend
 line 3: Need an operator
J  J   make[6]: 
/usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend
 line 4: Need an operator
J  J   make[6]: Fatal errors encountered -- cannot continue
J  J   make[6]: stopped in /usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff
J  J   *** [all] Error code 1
J  J 
J  J Typscript available here:
J  J http://people.freebsd.org/~jlh/typescript.buildworld.txt
J  J 
J  J Any ideas?
J  
J  Can you try to reproduce this with unmapped I/O turned off in boot loader?
J 
J I've never heard of that.  Can you please point me to the right
J code/doc?

In loader prompt:

OK set vfs.unmapped_buf_allowed=0
OK boot

-- 
Totus tuus, Glebius.
___
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 with Zero byte read from file, skipping rest of line

2014-01-15 Thread Jeremie Le Hen
On Wed, Jan 15, 2014 at 12:40:35PM +0400, Gleb Smirnoff wrote:
   Jeremie,
 
 On Wed, Jan 15, 2014 at 08:40:53AM +0100, Jeremie Le Hen wrote:
 J  J   === gnu/usr.bin/groff/src/libs/libgroff (all)
 J  J   make[6]: 
 /usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend
  line 3: warning: Zero byte read from file, skipping rest of line.
 J  J   make[6]: 
 /usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend
  line 3: Need an operator
 J  J   make[6]: 
 /usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend
  line 4: Need an operator
 J  J   make[6]: Fatal errors encountered -- cannot continue
 J  J   make[6]: stopped in /usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff
 J  J   *** [all] Error code 1
 J  J 
 J  J Typscript available here:
 J  J http://people.freebsd.org/~jlh/typescript.buildworld.txt
 J  J 
 J  J Any ideas?
 J  
 J  Can you try to reproduce this with unmapped I/O turned off in boot 
 loader?
 J 
 J I've never heard of that.  Can you please point me to the right
 J code/doc?
 
 In loader prompt:
 
 OK set vfs.unmapped_buf_allowed=0
 OK boot

No, unfortunately I still have the same problem without unmapped bufs.

-- 
Jeremie Le Hen

Scientists say the world is made up of Protons, Neutrons and Electrons.
They forgot to mention Morons.
___
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 with Zero byte read from file, skipping rest of line

2014-01-14 Thread Gleb Smirnoff
  Jeremie,

On Tue, Jan 14, 2014 at 08:26:21AM +0100, Jeremie Le Hen wrote:
J Hi,
J 
J I have a FreeBSD -CURRENT in Virtualbox (running on Linux).  I have been
J unable to buildworld for a while.
J 
J I suspect this is not a problem with the source because I didn't see any
J report so far, whereas I've been experiencing this for a month or more.
J Thus I naturally suspected it was a binary problem, so I've upgraded
J to the latest snapshot, but the problem still exists.
J 
J   === gnu/usr.bin/groff/src/libs/libgroff (all)
J   make[6]: 
/usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend
 line 3: warning: Zero byte read from file, skipping rest of line.
J   make[6]: 
/usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend
 line 3: Need an operator
J   make[6]: 
/usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend
 line 4: Need an operator
J   make[6]: Fatal errors encountered -- cannot continue
J   make[6]: stopped in /usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff
J   *** [all] Error code 1
J 
J Typscript available here:
J http://people.freebsd.org/~jlh/typescript.buildworld.txt
J 
J Any ideas?

Can you try to reproduce this with unmapped I/O turned off in boot loader?

-- 
Totus tuus, Glebius.
___
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 with Zero byte read from file, skipping rest of line

2014-01-14 Thread Jeremie Le Hen
On Tue, Jan 14, 2014 at 12:58:18PM +0400, Gleb Smirnoff wrote:
   Jeremie,
 
 On Tue, Jan 14, 2014 at 08:26:21AM +0100, Jeremie Le Hen wrote:
 J Hi,
 J 
 J I have a FreeBSD -CURRENT in Virtualbox (running on Linux).  I have been
 J unable to buildworld for a while.
 J 
 J I suspect this is not a problem with the source because I didn't see any
 J report so far, whereas I've been experiencing this for a month or more.
 J Thus I naturally suspected it was a binary problem, so I've upgraded
 J to the latest snapshot, but the problem still exists.
 J 
 J   === gnu/usr.bin/groff/src/libs/libgroff (all)
 J   make[6]: 
 /usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend
  line 3: warning: Zero byte read from file, skipping rest of line.
 J   make[6]: 
 /usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend
  line 3: Need an operator
 J   make[6]: 
 /usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend
  line 4: Need an operator
 J   make[6]: Fatal errors encountered -- cannot continue
 J   make[6]: stopped in /usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff
 J   *** [all] Error code 1
 J 
 J Typscript available here:
 J http://people.freebsd.org/~jlh/typescript.buildworld.txt
 J 
 J Any ideas?
 
 Can you try to reproduce this with unmapped I/O turned off in boot loader?

I've never heard of that.  Can you please point me to the right
code/doc?
 
Thanks?
-- 
Jeremie Le Hen

Scientists say the world is made up of Protons, Neutrons and Electrons.
They forgot to mention Morons.
___
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

2013-03-22 Thread Glen Barber
On Fri, Mar 22, 2013 at 09:16:13PM -0400, AN wrote:
 FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #38 r248401: Sat
 Mar 16 21:39:04 CDT 2013
 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL  amd64
 
 
 # svn info
 Path: .
 Working Copy Root Path: /usr/src
 URL: svn://svn.freebsd.org/base/head
 Repository Root: svn://svn.freebsd.org/base
 Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
 Revision: 248631
 
 
 Is anyone else seeing this?
 
 === gnu/usr.bin/texinfo/infokey (all)
 cc -O2 -pipe  -DHAVE_CONFIG_H -DLOCALEDIR=\/usr/share/locale\
 -I/usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo 
 -I/usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo/lib
 -std=gnu99 -Qunused-arguments -fstack-protector  -c 
 /usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo/info/infokey.c
 cc -O2 -pipe  -DHAVE_CONFIG_H -DLOCALEDIR=\/usr/share/locale\
 -I/usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo 
 -I/usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo/lib
 -std=gnu99 -Qunused-arguments -fstack-protector  -c 
 /usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo/info/key.c
 gzip -cn 
 /usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo/doc/infokey.1
 infokey.1.gz
 cc -O2 -pipe  -DHAVE_CONFIG_H -DLOCALEDIR=\/usr/share/locale\
 -I/usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo 
 -I/usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo/lib
 -std=gnu99 -Qunused-arguments -fstack-protector   -o infokey
 infokey.o key.o
 /usr/obj/usr/src/gnu/usr.bin/texinfo/infokey/../libtxi/libtxi.a
 === gnu/usr.bin/texinfo/install-info (all)
 cc -O2 -pipe  -DHAVE_CONFIG_H -DLOCALEDIR=\/usr/share/locale\ 
 -I/usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo 
 -I/usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/lib
 -std=gnu99 -Qunused-arguments -fstack-protector  -c 
 /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/util/install-info.c
 gzip -cn 
 /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/doc/install-info.1
 install-info.1.gz
 /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/util/install-info.c:1179:28:
 warning: expression result unused [-Wunused-value]
   bindtextdomain (PACKAGE, LOCALEDIR);
^
 command line:2:19: note: expanded from macro 'LOCALEDIR'
 #define LOCALEDIR /usr/share/locale
   ^~~
 /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/lib/gettext.h:54:63:
 note: expanded from macro 'bindtextdomain'
 # define bindtextdomain(Domainname, Dirname) ((const char *) (Dirname))
   ^
 /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/util/install-info.c:1180:15:
 warning: expression result unused [-Wunused-value]
   textdomain (PACKAGE);
   ^~~
 /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/config.h:338:17:
 note: expanded from macro 'PACKAGE'
 #define PACKAGE texinfo
 ^
 /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/lib/gettext.h:53:50:
 note: expanded from macro 'textdomain'
 # define textdomain(Domainname) ((const char *) (Domainname))
  ^
 2 warnings generated.
 cc -O2 -pipe  -DHAVE_CONFIG_H -DLOCALEDIR=\/usr/share/locale\ 
 -I/usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo 
 -I/usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/lib
 -std=gnu99 -Qunused-arguments -fstack-protector   -o install-info
 install-info.o
 /usr/obj/usr/src/gnu/usr.bin/texinfo/install-info/../libtxi/libtxi.a
 === gnu/usr.bin/texinfo/texindex (all)
 cc -O2 -pipe  -DHAVE_CONFIG_H -DLOCALEDIR=\/usr/share/locale\
 -I/usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo 
 -I/usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/lib
 -std=gnu99 -Qunused-arguments -fstack-protector  -c 
 /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/util/texindex.c
 gzip -cn 
 /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/doc/texindex.1
 texindex.1.gz
 /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/util/texindex.c:166:28:
 warning: expression result unused [-Wunused-value]
   bindtextdomain (PACKAGE, LOCALEDIR);
^
 command line:2:19: note: expanded from macro 'LOCALEDIR'
 #define LOCALEDIR /usr/share/locale
   ^~~
 /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/lib/gettext.h:54:63:
 note: expanded from macro 'bindtextdomain'
 # define bindtextdomain(Domainname, Dirname) ((const char *) (Dirname))
   ^
 /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/util/texindex.c:167:15:
 

Re: buildworld fails

2013-03-22 Thread Glen Barber
On Fri, Mar 22, 2013 at 10:32:02PM -0400, Glen Barber wrote:
  gzip -cn info.info  info.info.gz
  gzip -cn info-stnd.info  info-stnd.info.gz
  gzip -cn texinfo.info  texinfo.info.gz
  2 errors
  *** [everything] Error code 2
  1 error
  *** [buildworld] Error code 2
  1 error
  
 
 No, not with this error.  Although, I am not using clang.  Can you
 please provide your /etc/make.conf and /etc/src.conf ?
 

And of course, my local build just made a liar out of me...  Yes, I see
this too.

Glen



pgpUI0hl1rt_e.pgp
Description: PGP signature


Re: buildworld fails

2013-03-22 Thread Glen Barber
On Fri, Mar 22, 2013 at 10:33:00PM -0400, Glen Barber wrote:
 On Fri, Mar 22, 2013 at 10:32:02PM -0400, Glen Barber wrote:
   gzip -cn info.info  info.info.gz
   gzip -cn info-stnd.info  info-stnd.info.gz
   gzip -cn texinfo.info  texinfo.info.gz
   2 errors
   *** [everything] Error code 2
   1 error
   *** [buildworld] Error code 2
   1 error
   
  
  No, not with this error.  Although, I am not using clang.  Can you
  please provide your /etc/make.conf and /etc/src.conf ?
  
 
 And of course, my local build just made a liar out of me...  Yes, I see
 this too.
 

Ok, I suspect you are using '-jN' with make(1).

The real error is:

(cd /usr/src/rescue/rescue/../../sbin/fsdb 
/usr/obj/usr/src/make.amd64/make -DRESCUE CRUNCH_CFLAGS=-DRESCUE
DIRPRFX=rescue/rescue/fsdb/ depend  /usr/obj/usr/src/make.amd64/make
-DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/fsdb/ fsdb.o
fsdbutil.o dir.o ea.o fsutil.o inode.o pass1.o pass1b.o pass2.o pass3.o
pass4.o pass5.o setup.o utilities.o ffs_subr.o ffs_tables.o)
/usr/local/libexec/ccache/world/cc -O2 -pipe
-I/usr/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -fstack-protector
-Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized
-Wno-pointer-sign -c /usr/src/sbin/fsdb/fsdb.c
/usr/src/sbin/fsdb/fsdb.c: In function 'findblk':
/usr/src/sbin/fsdb/fsdb.c:444: error: 'cgrp' undeclared (first use in
this function)
/usr/src/sbin/fsdb/fsdb.c:444: error: (Each undeclared identifier is
reported only once
/usr/src/sbin/fsdb/fsdb.c:444: error: for each function it appears in.)
/usr/src/sbin/fsdb/fsdb.c:476: error: 'cgblk' undeclared (first use in
this function)
*** [fsdb.o] Error code 1

Stop in /usr/src/sbin/fsdb.
*** [fsdb_make] Error code 1



This is ... known at the moment, and is being resolved.  Please hang in
there a bit until this change is either fixed or reverted.

Glen



pgpTA6IxoJVOA.pgp
Description: PGP signature


Re: buildworld fails

2012-12-23 Thread Dimitry Andric

On 2012-12-23 18:43, AN wrote:

FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #10 r244601: Sat Dec 22
18:22:44 EST 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL  amd64


=== gnu/usr.bin/texinfo/infokey (all)

...
...

1 error
*** [everything] Error code 2
1 error
*** [buildworld] Error code 2
1 error


The actual error was earlier in this multi-threaded build, but you did
not post the full log.  Please search in the log for the actual error,
or try a buildworld without -j.
___
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

2012-12-23 Thread Guido Falsi

On 12/23/12 18:50, Dimitry Andric wrote:

On 2012-12-23 18:43, AN wrote:

FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #10 r244601: Sat Dec 22
18:22:44 EST 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL  amd64


=== gnu/usr.bin/texinfo/infokey (all)

...
...

1 error
*** [everything] Error code 2
1 error
*** [buildworld] Error code 2
1 error


The actual error was earlier in this multi-threaded build, but you did
not post the full log.  Please search in the log for the actual error,
or try a buildworld without -j.


I have just got the same error, here is the relevant error message:

=== usr.sbin/gssd (all)
cc -O2 -pipe -march=nocona -I. -std=gnu99 -Qunused-arguments 
-fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign 
-Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
-Wno-conversion -Wno-switch -Wno-switch-enum -Wno-parentheses  -o gssd 
gssd.o gssd_svc.o gssd_xdr.o gssd_prot.o -lgssapi

gssd.o: In function `find_ccache_file':
/usr/src/usr.sbin/gssd/gssd.c:(.text+0xaf5): undefined reference to 
`krb5_init_context'
/usr/src/usr.sbin/gssd/gssd.c:(.text+0xb15): undefined reference to 
`krb5_cc_resolve'
/usr/src/usr.sbin/gssd/gssd.c:(.text+0xb3d): undefined reference to 
`krb5_cc_start_seq_get'
/usr/src/usr.sbin/gssd/gssd.c:(.text+0xb5e): undefined reference to 
`krb5_cc_next_cred'
/usr/src/usr.sbin/gssd/gssd.c:(.text+0xb7d): undefined reference to 
`krb5_free_context'
/usr/src/usr.sbin/gssd/gssd.c:(.text+0xbdf): undefined reference to 
`krb5_unparse_name'
/usr/src/usr.sbin/gssd/gssd.c:(.text+0xc96): undefined reference to 
`krb5_unparse_name'
/usr/src/usr.sbin/gssd/gssd.c:(.text+0xd67): undefined reference to 
`krb5_free_cred_contents'
/usr/src/usr.sbin/gssd/gssd.c:(.text+0xd84): undefined reference to 
`krb5_cc_next_cred'
/usr/src/usr.sbin/gssd/gssd.c:(.text+0xda6): undefined reference to 
`krb5_cc_end_seq_get'
/usr/src/usr.sbin/gssd/gssd.c:(.text+0xdbf): undefined reference to 
`krb5_cc_close'
/usr/src/usr.sbin/gssd/gssd.c:(.text+0xdcb): undefined reference to 
`krb5_free_context'

cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [gssd] Error code 1

Stop in /usr/src/usr.sbin/gssd.
*** [all] Error code 1

Stop in /usr/src/usr.sbin.
*** [usr.sbin.all__D] Error code 1

Stop in /usr/src.
*** [everything] Error code 1

Stop in /usr/src.
*** [buildworld] Error code 1

Stop in /usr/src.


Hope this helps.


___
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



--
Guido Falsi m...@madpilot.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: buildworld fails

2012-12-23 Thread AN



On Sun, 23 Dec 2012, Guido Falsi wrote:


On 12/23/12 18:50, Dimitry Andric wrote:

On 2012-12-23 18:43, AN wrote:

FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #10 r244601: Sat Dec 22
18:22:44 EST 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL  amd64


=== gnu/usr.bin/texinfo/infokey (all)

...
...

1 error
*** [everything] Error code 2
1 error
*** [buildworld] Error code 2
1 error


The actual error was earlier in this multi-threaded build, but you did
not post the full log.  Please search in the log for the actual error,
or try a buildworld without -j.


I have just got the same error, here is the relevant error message:

=== usr.sbin/gssd (all)
cc -O2 -pipe -march=nocona -I. -std=gnu99 -Qunused-arguments 
-fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body 
-Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch 
-Wno-switch-enum -Wno-parentheses  -o gssd gssd.o gssd_svc.o gssd_xdr.o 
gssd_prot.o -lgssapi

gssd.o: In function `find_ccache_file':
/usr/src/usr.sbin/gssd/gssd.c:(.text+0xaf5): undefined reference to 
`krb5_init_context'
/usr/src/usr.sbin/gssd/gssd.c:(.text+0xb15): undefined reference to 
`krb5_cc_resolve'
/usr/src/usr.sbin/gssd/gssd.c:(.text+0xb3d): undefined reference to 
`krb5_cc_start_seq_get'
/usr/src/usr.sbin/gssd/gssd.c:(.text+0xb5e): undefined reference to 
`krb5_cc_next_cred'
/usr/src/usr.sbin/gssd/gssd.c:(.text+0xb7d): undefined reference to 
`krb5_free_context'
/usr/src/usr.sbin/gssd/gssd.c:(.text+0xbdf): undefined reference to 
`krb5_unparse_name'
/usr/src/usr.sbin/gssd/gssd.c:(.text+0xc96): undefined reference to 
`krb5_unparse_name'
/usr/src/usr.sbin/gssd/gssd.c:(.text+0xd67): undefined reference to 
`krb5_free_cred_contents'
/usr/src/usr.sbin/gssd/gssd.c:(.text+0xd84): undefined reference to 
`krb5_cc_next_cred'
/usr/src/usr.sbin/gssd/gssd.c:(.text+0xda6): undefined reference to 
`krb5_cc_end_seq_get'
/usr/src/usr.sbin/gssd/gssd.c:(.text+0xdbf): undefined reference to 
`krb5_cc_close'
/usr/src/usr.sbin/gssd/gssd.c:(.text+0xdcb): undefined reference to 
`krb5_free_context'

cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [gssd] Error code 1

Stop in /usr/src/usr.sbin/gssd.
*** [all] Error code 1

Stop in /usr/src/usr.sbin.
*** [usr.sbin.all__D] Error code 1

Stop in /usr/src.
*** [everything] Error code 1

Stop in /usr/src.
*** [buildworld] Error code 1

Stop in /usr/src.



Probably this: 
http://svnweb.FreeBSD.org/base?view=revisionrevision=244604

___
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 with clang, seems to be due to ATF import

2012-10-23 Thread Dimitry Andric

On 2012-10-23 11:21, Olivier Smedts wrote:

I can't buildworld with clang anymore, tried with one job, error
below. Sorry for the noise if that's a known problem.

...

/usr/obj/usr/src/tmp/usr/include/c++/4.2/bits/streambuf_iterator.h:162:20:
error: '' within '||' [-Werror,-Wlogical-op-parentheses]
 return (__thiseof  __beof || (!__thiseof  !__beof));
 ~~^ ~~


Yes, these are several warnings in libstdc++ that should be fixed.  I
have a few patches ready to commit tonight.  Meanwhile, you can apply
the attached patch.
Index: contrib/atf/atf-report/atf-report.cpp
===
--- contrib/atf/atf-report/atf-report.cpp	(revision 241921)
+++ contrib/atf/atf-report/atf-report.cpp	(working copy)
@@ -381,7 +381,6 @@ class ticker_writer : public writer {
 class xml_writer : public writer {
 ostream_ptr m_os;
 
-size_t m_curtp, m_ntps;
 std::string m_tcname, m_tpname;
 
 static
Index: contrib/atf/atf-run/io.hpp
===
--- contrib/atf/atf-run/io.hpp	(revision 241921)
+++ contrib/atf/atf-run/io.hpp	(working copy)
@@ -378,11 +378,6 @@ class pistream :
 public std::istream, utils::noncopyable
 {
 //!
-//! \brief The file handle managed by this stream.
-//!
-int m_fd;
-
-//!
 //! \brief The systembuf object used to manage this stream's data.
 //!
 systembuf m_systembuf;
Index: contrib/libstdc++/config/os/bsd/freebsd/ctype_base.h
===
--- contrib/libstdc++/config/os/bsd/freebsd/ctype_base.h	(revision 241921)
+++ contrib/libstdc++/config/os/bsd/freebsd/ctype_base.h	(working copy)
@@ -38,8 +38,9 @@
 _GLIBCXX_BEGIN_NAMESPACE(std)
 
   /// @brief  Base class for ctype.
-  struct ctype_base
+  class ctype_base
   {
+  public:
 // Non-standard typedefs.
 typedef const int* 		__to_type;
 
Index: contrib/libstdc++/include/bits/fstream.tcc
===
--- contrib/libstdc++/include/bits/fstream.tcc	(revision 241921)
+++ contrib/libstdc++/include/bits/fstream.tcc	(working copy)
@@ -641,21 +641,23 @@ _GLIBCXX_BEGIN_NAMESPACE(std)
 setbuf(char_type* __s, streamsize __n)
 {
   if (!this-is_open())
-	if (__s == 0  __n == 0)
-	  _M_buf_size = 1;
-	else if (__s  __n  0)
-	  {
-	// This is implementation-defined behavior, and assumes that
-	// an external char_type array of length __n exists and has
-	// been pre-allocated. If this is not the case, things will
-	// quickly blow up. When __n  1, __n - 1 positions will be
-	// used for the get area, __n - 1 for the put area and 1
-	// position to host the overflow char of a full put area.
-	// When __n == 1, 1 position will be used for the get area
-	// and 0 for the put area, as in the unbuffered case above.
-	_M_buf = __s;
-	_M_buf_size = __n;
-	  }
+	{
+	  if (__s == 0  __n == 0)
+	_M_buf_size = 1;
+	  else if (__s  __n  0)
+	{
+	  // This is implementation-defined behavior, and assumes that
+	  // an external char_type array of length __n exists and has
+	  // been pre-allocated. If this is not the case, things will
+	  // quickly blow up. When __n  1, __n - 1 positions will be
+	  // used for the get area, __n - 1 for the put area and 1
+	  // position to host the overflow char of a full put area.
+	  // When __n == 1, 1 position will be used for the get area
+	  // and 0 for the put area, as in the unbuffered case above.
+	  _M_buf = __s;
+	  _M_buf_size = __n;
+	}
+	}
   return this;
 }
 
Index: contrib/libstdc++/include/bits/locale_facets.h
===
--- contrib/libstdc++/include/bits/locale_facets.h	(revision 241921)
+++ contrib/libstdc++/include/bits/locale_facets.h	(working copy)
@@ -4335,8 +4335,9 @@ _GLIBCXX_END_LDBL_NAMESPACE
   /**
*  @brief  Messages facet base class providing catalog typedef.
*/
-  struct messages_base
+  class messages_base
   {
+  public:
 typedef int catalog;
   };
 
Index: contrib/libstdc++/include/bits/locale_facets.tcc
===
--- contrib/libstdc++/include/bits/locale_facets.tcc	(revision 241921)
+++ contrib/libstdc++/include/bits/locale_facets.tcc	(working copy)
@@ -316,7 +316,7 @@ _GLIBCXX_BEGIN_LDBL_NAMESPACE
   int __sep_pos = 0;
   while (!__testeof)
 	{
-	  if (__lc-_M_use_grouping  __c == __lc-_M_thousands_sep
+	  if ((__lc-_M_use_grouping  __c == __lc-_M_thousands_sep)
 	  || __c == __lc-_M_decimal_point)
 	break;
 	  else if (__c == __lit[__num_base::_S_izero])
@@ -558,7 +558,7 @@ _GLIBCXX_BEGIN_LDBL_NAMESPACE
 	int __sep_pos = 0;
 	while (!__testeof)
 	  {
-	if (__lc-_M_use_grouping  __c == __lc-_M_thousands_sep
+	if ((__lc-_M_use_grouping  __c == 

Re: buildworld fails with clang, seems to be due to ATF import

2012-10-23 Thread Olivier Smedts
2012/10/23 Dimitry Andric d...@freebsd.org:
 Yes, these are several warnings in libstdc++ that should be fixed.  I
 have a few patches ready to commit tonight.  Meanwhile, you can apply
 the attached patch.

Applied with svn patch, no rejects, fixes buildworld. Thanks !

-- 
Olivier Smedts _
ASCII ribbon campaign ( )
e-mail: oliv...@gid0.org- against HTML email  vCards  X
www: http://www.gid0.org- against proprietary attachments / \

  Il y a seulement 10 sortes de gens dans le monde :
  ceux qui comprennent le binaire,
  et ceux qui ne le comprennent pas.
___
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

2012-04-30 Thread David O'Brien
On Tue, Apr 24, 2012 at 09:34:58PM +0300, Vladimir Sharun wrote:
 === usr.bin/file (all)
...
 file.o: In function `main':
 /usr/src/usr.bin/file/../../contrib/file/file.c:(.text+0x717): undefined
 reference to `magic_getpath'
 /usr/src/usr.bin/file/../../contrib/file/file.c:(.text+0x7df): undefined
 reference to `magic_list'
 clang: error: linker command failed with exit code 1 (use -v to see
 invocation)
 *** [file] Error code 1

How are you building this?  Did libmagic get [re]built first?


 r234657

$ svn info -r234657 svn info -r234657 svn://svn.freebsd.org/base/head
Last Changed Date: 2012-04-24 10:51:36 -0700 (Tue, 24 Apr 2012)

I do not believe that a 10-CURRENT system from 2012-04-24 has trouble
building the new file(1).

The issue that started this thread is due to a commit from
2009-02-27 -- which pre-dates 10-CURRENT.

-- 
-- David  (obr...@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


Re: buildworld fails on FreeBSD 7.x for HEAD from 19.04.2012

2012-04-24 Thread David O'Brien
On Sun, Apr 22, 2012 at 09:06:18AM -0700, Garrett Cooper 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.
...
 Ugh. The usecase (that's now broken) is that Jan from Semihalf might
 have been running CURRENT builds on an older (stable) build machine.

Lets not guess.  If you've found that any version of 10-CURRENT cannot
build HEAD post r234449 please let me know.

I've verified that I can build HEAD on 8.3-PRERELEASE (r231882).

-- 
-- David  (obr...@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


Re: buildworld fails on FreeBSD 7.x for HEAD from 19.04.2012

2012-04-24 Thread Vladimir Sharun



=== usr.bin/file (all)
/usr/bin/clang -O2 -pipe  -DMAGIC='/usr/share/misc/magic'
-DHAVE_CONFIG_H -I/usr/src/usr.bin/file/../../lib/libmagic -std=gnu99
-Qunused-arguments -fstack-protector -Wsystem-headers -Wall
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
-Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
-Wold-style-definition -Wno-pointer-sign -Wno-empty-body
-Wno-string-plus-int  -o file file.o -lmagic -lz
file.o: In function `main':
/usr/src/usr.bin/file/../../contrib/file/file.c:(.text+0x717): undefined
reference to `magic_getpath'
/usr/src/usr.bin/file/../../contrib/file/file.c:(.text+0x7df): undefined
reference to `magic_list'
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
*** [file] Error code 1

r234657

clang -v:
FreeBSD clang version 3.1 (trunk 154661) 20120413
Target: x86_64-unknown-freebsd10.0
Thread model: posix

FreeBSD 10.0-CURRENT #6: Thu Apr 12 08:56:05 EEST 2012 amd64

make buildworld without j's

On Sun, Apr 22, 2012 at 09:06:18AM -0700, Garrett Cooper 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.
...
 Ugh. The usecase (that's now broken) is that Jan from Semihalf might
 have been running CURRENT builds on an older (stable) build machine.

Lets not guess.  If you've found that any version of 10-CURRENT cannot
build HEAD post r234449 please let me know.

I've verified that I can build HEAD on 8.3-PRERELEASE (r231882).

-- 
-- David  (obr...@freebsd.org)
___freebsd-curr...@freebsd.org 
mailing listhttp://lists.freebsd.org/mailman/listinfo/freebsd-currentTo 
unsubscribe, send any mail to freebsd-current-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


Re: buildworld fails on FreeBSD 7.x for HEAD from 19.04.2012

2012-04-22 Thread Adrian Chadd
Not even a full crossbuild?



adrian
___
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

2012-04-22 Thread Garrett Cooper
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

2012-04-22 Thread Dimitry Andric
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=208341r2=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

2012-04-22 Thread Garrett Cooper
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=208341r2=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

2012-04-22 Thread Dimitry Andric
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=208341r2=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


Re: buildworld fails on FreeBSD 7.x for HEAD from 19.04.2012

2012-04-22 Thread Garrett Cooper
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=revisionrevision=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


Re: buildworld fails on FreeBSD 7.x for HEAD from 19.04.2012

2012-04-20 Thread Doug Barton
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.

-- 

This .signature sanitized for your protection
___
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 building _dtrace_tools

2010-07-01 Thread Ruslan Ermilov
On Wed, Jun 30, 2010 at 04:26:53PM +0200, Claude Buisson wrote:
 Anton Shterenlikht wrote:
  HI Claude
 
  http://www.mavetju.org/mail/view_message.php?list=freebsd-currentid=3145015
 
  Have you got a reply to your question?
  Have you solved it?
 
 
  I'm now seeing the same on i386.
 
  Any advice?
 
  many thanks
  anton
 
 
 Hi Anton,
 
 I never received any reply..
 
 I have done a binary search and found that the problem was introduced by svn
 revision r204339 dated February 25 by ru@

Let's admit that the problem was uncovered, not introduced.  The mentioned
commit of mine is correct (try building stuff statically linked to see).

 Reverting this revision by hand, I have been able to build a system 
 WITH_CDDL
 which could be used to rebuild from the current sources.
 
 But the original problem is always here: how to make a buildworld WITH_CDDL 
 on
 a system built WITHOUT_CDDL ?
 
 I sent a message to ru@ on April 11, without success..

Sorry, still swamped with real life issues.  I think there are basically
two options for bootstrapping:

- reinstall stuff from some release media (e.g., take the required
  bits from the nearby release tarballs)

- manually build/install the missing stuff from sources (if you have'em)

Then do a buildworld.  This problem is similar to the case when you
lose /usr/bin/make or some other host tool used during the build.
___
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

2003-11-16 Thread Aron Håkanson
Sön 2003-11-16 klockan 21.12 skrev Peter Ulrich Kruppa:
 Hi!
 
 I have a problem with today's sources.
 
 At my first try make buildworld and make kernel worked all-right
 and the new kernel could be booted, so I didn't check closely and
 made installworld. This failed *somewhere* , and now I am left
 with a defect system: no internet connection, no XFree86 and
 perhaps some more things I haven't found yet.
 
 Next I deleted /usr/obj/usr and /usr/src and cvsupped fresh
 sources (via a a basic 4.8 -RELEASE I have got on the same
 machine), but now buildworld fails very soon with
...

 sh /usr/src/tools/install.sh -C -o root -g wheel -m 444   libegacy.a /usr/obj/us
 r/src/i386/legacy/usr/lib
 *** Signal 11

There is a problem with the old install program when you make the
installworld with the new sources. You can solve this by installing the
new install program from the obj-directory. Just copy the
/usr/obj/usr/src/usr.bin/xinstall/xinstall to /usr/bin/install (ev. a
chmod 555 too) and it should work.

Aron
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: buildworld fails

2003-11-16 Thread Marcus Reid
On Mon, Nov 17, 2003 at 01:04:33AM +0100, Aron H?kanson wrote:
 S?n 2003-11-16 klockan 21.12 skrev Peter Ulrich Kruppa:
  Hi!
  
  I have a problem with today's sources.
  
  At my first try make buildworld and make kernel worked all-right
  and the new kernel could be booted, so I didn't check closely and
  made installworld. This failed *somewhere* , and now I am left
  with a defect system: no internet connection, no XFree86 and
  perhaps some more things I haven't found yet.
  
  Next I deleted /usr/obj/usr and /usr/src and cvsupped fresh
  sources (via a a basic 4.8 -RELEASE I have got on the same
  machine), but now buildworld fails very soon with
 ...
 
  sh /usr/src/tools/install.sh -C -o root -g wheel -m 444   libegacy.a /usr/obj/us
  r/src/i386/legacy/usr/lib
  *** Signal 11
 
 There is a problem with the old install program when you make the
 installworld with the new sources. You can solve this by installing the
 new install program from the obj-directory. Just copy the
 /usr/obj/usr/src/usr.bin/xinstall/xinstall to /usr/bin/install (ev. a
 chmod 555 too) and it should work.

If you don't already have a binary to work with, do a:

  cd /usr/src/usr.bin/xinstall
  make all

Then copy the resulting xinstall binary over /usr/bin/install.

Marcus

 Aron
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: buildworld fails with with de_AT locale

2003-10-29 Thread Andrey Chernov
On Wed, Oct 29, 2003 at 12:18:39AM +0100, Bernhard Valenti wrote:
 hi,
 
 a buildworld with a de_AT locale fails in src/lib/libedit, the file 
 fcnl.h that gets created is broken. i found that problem in the mailing 
 list(april this year), and wonder if this has still not been fixed?

It already fixed in -current and -stable is not affected (due to obsoleted 
tr there).

-- 
Andrey Chernov | http://ache.pp.ru/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: buildworld fails on Alpha?

2003-10-24 Thread Kris Kennaway
On Fri, Oct 24, 2003 at 11:03:31PM +0200, Wilko Bulte wrote:
 ll -Wno-format-y2k -Wno-uninitialized  -c /usr/src/lib/libfetch/fetch.c
 cc -O -pipe -mcpu=ev6 -mieee -I. -DINET6 -DWITH_SSL -Wsystem-headers -Werror
 -Wa
 ll -Wno-format-y2k -Wno-uninitialized  -c /usr/src/lib/libfetch/common.c
 /usr/src/lib/libfetch/common.c:58: error: `EAINONAME' undeclared here (not
 in a 
 function)

This was fixed yesterday.

Kris


pgp0.pgp
Description: PGP signature


Re: buildworld fails on Alpha?

2003-10-24 Thread Hajimu UMEMOTO
Hi,

 On Fri, 24 Oct 2003 23:03:31 +0200
 Wilko Bulte [EMAIL PROTECTED] said:

wkb ll -Wno-format-y2k -Wno-uninitialized  -c /usr/src/lib/libfetch/common.c
wkb /usr/src/lib/libfetch/common.c:58: error: `EAINONAME' undeclared here (not

It was fixed already.  Please re-cvsup.
Sorry for the mess.

Sincerely,

--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED]  [EMAIL PROTECTED]  [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: buildworld fails on Alpha?

2003-10-24 Thread Wilko Bulte
On Sat, Oct 25, 2003 at 06:06:24AM +0900, Hajimu UMEMOTO wrote:
 Hi,
 
  On Fri, 24 Oct 2003 23:03:31 +0200
  Wilko Bulte [EMAIL PROTECTED] said:
 
 wkb ll -Wno-format-y2k -Wno-uninitialized  -c /usr/src/lib/libfetch/common.c
 wkb /usr/src/lib/libfetch/common.c:58: error: `EAINONAME' undeclared here (not
 
 It was fixed already.  Please re-cvsup.
 Sorry for the mess.

No problem, I'll re-cvsup

-- 
|   / o / /_  _ [EMAIL PROTECTED]
|/|/ / / /(  (_)  Bulte 
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Buildworld fails in 5.1-CURRENT in wall

2003-10-21 Thread Dag-Erling Smørgrav
M. Warner Losh [EMAIL PROTECTED] writes:
 find /usr/obj -name .depend

 or better yet

 rm -rf /usr/obj/*

*ahem*

the correct incantation is:

# cd /usr/src
# make cleandir
# make cleandir

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Buildworld fails in 5.1-CURRENT in wall- SOLVED

2003-10-21 Thread Scott W
Dag-Erling Smørgrav wrote:

M. Warner Losh [EMAIL PROTECTED] writes:
 

find /usr/obj -name .depend

or better yet

rm -rf /usr/obj/*
   

*ahem*

the correct incantation is:

# cd /usr/src
# make cleandir
# make cleandir
DES
 

Removing the /usr/obj/* tree worked, back in business.  Will have to 
take a closer look at the 'master' Makefile, as I didn't see the 
cleandir target at first glance, so had been using 'make clean  make 
buildworld' for previous builds- I take it this is NOT needed as the 
build process does a 'make clean' prior to building?

Thanks to all...

Scott

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Buildworld fails in 5.1-CURRENT in wall

2003-10-20 Thread M. Warner Losh
I'd remove all the .depend files and try again.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


  1   2   >