Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-25 Thread Simon J. Gerraty
Simon J. Gerraty wrote: > Peter Jeremy wrote: > > In my case, I have "WITH_META_MODE=yes" in /etc/src-env.conf and was > > using "make buildworld" - which failed. The upgrade worked cleanly > > when I manually deleted all the .meta files. If I get a round

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Simon J. Gerraty
Peter Jeremy wrote: > In my case, I have "WITH_META_MODE=yes" in /etc/src-env.conf and was > using "make buildworld" - which failed. The upgrade worked cleanly > when I manually deleted all the .meta files. If I get a round tuit, sys.mk is setup such that missing .meta file

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Peter Jeremy
On 2017-May-24 20:21:54 +0300, Konstantin Belousov wrote: >No SIGSEGV etc, so I think that the effects seen are due to build system. >rm -rf obj/* is the safest trick, I believe. But the behaviour does indicate that meta mode is not doing the right thing under all

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Peter Jeremy
On 2017-May-24 18:01:42 -0700, "Simon J. Gerraty" wrote: >Peter Jeremy wrote: >> as follows. My suspicion is that meta mode isn't seeing enough of the >> differences between the bootstrap and main build steps and so causing make >> to incorrectly skip

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Simon J. Gerraty
Peter Jeremy wrote: > as follows. My suspicion is that meta mode isn't seeing enough of the > differences between the bootstrap and main build steps and so causing make > to incorrectly skip steps. I see a number of places in src/Makefile* where BUILD_TOOLS_META=.NOMETA is

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Peter Jeremy
On 2017-May-24 08:47:41 -0700, Ngie Cooper wrote: >There was another report on the list about a stale MAKEOBJDIRPREFIX > causing someone grief. I think it's safe to say that meta mode and -DNO_CLEAN > might not work across this transition--in particular meta mode

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread David Wolfskill
On Wed, May 24, 2017 at 01:42:39PM -0700, Simon J. Gerraty wrote: > David Wolfskill wrote: > > As far as I can tell, the "ld" command was: > > Since you have the .meta file, it should tell you exactly what the > command was and what path was actually exec'd And now that

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Simon J. Gerraty
Ngie Cooper wrote: > There was another report on the list about a stale > MAKEOBJDIRPREFIX causing someone grief. Pointer? What does stale MAKEOBJDIRPREFIX mean? >I think it's safe to say that > meta mode and -DNO_CLEAN might not work across this transition--in >

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Simon J. Gerraty
David Wolfskill wrote: > As far as I can tell, the "ld" command was: Since you have the .meta file, it should tell you exactly what the command was and what path was actually exec'd ___ freebsd-current@freebsd.org mailing list

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Konstantin Belousov
On Wed, May 24, 2017 at 08:15:09AM -0700, David Wolfskill wrote: > On Wed, May 24, 2017 at 07:20:01AM -0700, David Wolfskill wrote: > > ... > > > > I have updated /usr/src back to 318781, then started a new build. > > > So are you building stock 318781, or did you reverted r318750 ? > > > > Stock

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Ngie Cooper
> On May 24, 2017, at 08:15, David Wolfskill wrote: ... > It completed successfully and a reboot shows: > > FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #354 > r318781M/318781:1200031: Wed May 24 07:31:48 PDT 2017 >

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread David Wolfskill
On Wed, May 24, 2017 at 07:20:01AM -0700, David Wolfskill wrote: > ... > > > I have updated /usr/src back to 318781, then started a new build. > > So are you building stock 318781, or did you reverted r318750 ? > > Stock 318781 [*]. I revert as a (nearly) last resort. :-) > > > > While it has

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread David Wolfskill
On Wed, May 24, 2017 at 05:16:38PM +0300, Konstantin Belousov wrote: > On Wed, May 24, 2017 at 06:59:05AM -0700, David Wolfskill wrote: > > On Wed, May 24, 2017 at 04:35:58PM +0300, Konstantin Belousov wrote: > > > If build of r318739 succed, can you try, please, to rebuild the current > > >

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Konstantin Belousov
On Wed, May 24, 2017 at 06:59:05AM -0700, David Wolfskill wrote: > On Wed, May 24, 2017 at 04:35:58PM +0300, Konstantin Belousov wrote: > > If build of r318739 succed, can you try, please, to rebuild the current > > latest sources, but now with reverted r318750 ? > > It did complete successfully.

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread David Wolfskill
On Wed, May 24, 2017 at 04:35:58PM +0300, Konstantin Belousov wrote: > ... > > (lldb) bt > > * thread #1, name = 'ld', stop reason = signal SIGSEGV > > * frame #0: 0x > > (lldb) > > > > which isn't entirely unexpected, I suppose, given the nature of SIGSEGV. > Useful gdb is in

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Konstantin Belousov
On Wed, May 24, 2017 at 06:01:43AM -0700, David Wolfskill wrote: > On Wed, May 24, 2017 at 02:10:08PM +0200, Dimitry Andric wrote: > > ... > > > building special pic c library > > > --- libc.so.7 --- > > > cc: error: unable to execute command: Segmentation fault (core dumped) > > > cc: error:

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread David Wolfskill
On Wed, May 24, 2017 at 02:10:08PM +0200, Dimitry Andric wrote: > ... > > building special pic c library > > --- libc.so.7 --- > > cc: error: unable to execute command: Segmentation fault (core dumped) > > cc: error: linker command failed due to signal (use -v to see invocation) > > ***

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Konstantin Belousov
On Wed, May 24, 2017 at 04:59:31AM -0700, David Wolfskill wrote: > Yesterday's in-place src update (r318606 -> r318739) was a bit more > "interesting" than usual; as has been noted elsewhere, it really is > necessary to boot the new kernel before the "make installworld" > completes successfully.

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Dimitry Andric
On 24 May 2017, at 13:59, David Wolfskill wrote: > > Yesterday's in-place src update (r318606 -> r318739) was a bit more > "interesting" than usual; as has been noted elsewhere, it really is > necessary to boot the new kernel before the "make installworld" > completes

ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread David Wolfskill
Yesterday's in-place src update (r318606 -> r318739) was a bit more "interesting" than usual; as has been noted elsewhere, it really is necessary to boot the new kernel before the "make installworld" completes successfully. That said, it ("make installworld") did complete successfully, and a