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 tuit,
>
> sys.mk is setup such that m
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 makes the target
out
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 circumstances. It's blatently b
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 steps.
>
>I see a number of places in src/Ma
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 added to env of things
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 tends to err
> on the side
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 I'm not running around li
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
> particular meta mode tends
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
https://lists.freebsd.org
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
> 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
> r...@freebeast.catwhisker.org:/common/S3/obj/usr/
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 no
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
> > > latest
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.
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 p
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: linke
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)
> > *** [libc.so.7]
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. T
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 successfully. That said, it
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 follo
20 matches
Mail list logo