W dniu 24.02.2021 o 20:03, Kyle Evans pisze:
On Wed, Feb 24, 2021 at 12:57 PM Dean E. Weimer <dwei...@dweimer.net> wrote:
On 2021-02-23 12:34 pm, Kyle Evans wrote:
The more I look at `make -dm` output, the less sense it makes. Your
patch is decidedly correct regardless of how this specific scenario is
playing out:
1.) As you noted, it's wrong to clean something that's built
elsewhere. You can reasonably expect `make clean all` to work pretty
much everywhere else.
2.) i386/loader cannot make an informed decision about whether it's
out-of-date, which is sufficient to tell that the existing addition to
OBJS was not the correct implementation in hindsight.
3.) The failure mode if it's *missing* is exactly the same before and
after your patch; file can't be found, cannot build it.
On Tue, Feb 23, 2021 at 12:09 PM Warner Losh <i...@bsdimp.com> wrote:
I'm unsure of the mechanics as well. I do know that we shouldn't
delete stuff in OTHER directories, though. the btx stuff is trying to
do a bit of an end run around the link only with the installed stuff
here and using crt0.o as a library from the 'where it was built'
directory which I think creates one too many dependencies... I've not
yet puzzled through all of them to find out which one is causing us to
think we need to rebuild though.
Warner
On Tue, Feb 23, 2021 at 9:21 AM Kyle Evans <kev...@freebsd.org> wrote:
Hi,
What I don't understand here is, why are these being considered
out-of-date? That seems like it is indicative of a larger problem
that
we'd surely fall over elsewhere on if not for here, that the source
tree's timestamps are post-dated w.r.t. the objdir.
Thanks,
Kyle Evans
On Mon, Feb 22, 2021 at 5:52 PM Warner Losh <i...@bsdimp.com> wrote:
What does this patch do for you?
diff --git a/stand/i386/loader/Makefile b/stand/i386/loader/Makefile
index ad95948ec50a..cbbe15bd1fc0 100644
--- a/stand/i386/loader/Makefile
+++ b/stand/i386/loader/Makefile
@@ -90,7 +90,8 @@ FILES+= ${LOADER}
FILESMODE_${LOADER}= ${BINMODE} -b
# XXX crt0.o needs to be first for pxeboot(8) to work
-OBJS= ${BTXCRT}
+# Can't add it to OBJS w/o pain and suffering
+LDFLAGS+= ${BTXCRT}
DPADD= ${LDR_INTERP32} ${LIBFIREWIRE} ${LIBI386} ${LIBSA32}
LDADD= ${LDR_INTERP32} ${LIBFIREWIRE} ${LIBI386} ${LIBSA32}
Anything?
Warner
On Mon, Feb 22, 2021 at 4:17 PM Dean E. Weimer <dwei...@dweimer.net> wrote:
On 2021-02-22 10:53 am, Dean E. Weimer wrote:
On 2021-02-22 9:38 am, Dean E. Weimer via freebsd-stable wrote:
On 2021-02-22 9:29 am, Warner Losh wrote:
On Mon, Feb 22, 2021 at 8:24 AM Dean E. Weimer via freebsd-stable
<freebsd-stable@freebsd.org> wrote:
I was able to successfully build and install BETA2 from source,
however
I am now attempting to upgrade the same machine to BETA3 buildworld
and
buildkernel complete. installkernel also completes, but installworld
fails, it appears to not find a file for i386 boot.
/jails/devel/ROOT/usr/obj/jails/devel/ROOT/usr/src/amd64.amd64/stand/i386/btx/btx/btx
-l boot2.ldr -o boot2.ld -P 1 boot2.bin
make[6]: exec(btxld) failed (No such file or directory)
Does this happen every time, or only sometimes? Do you have the
complete log? Why we're trying to run btxld and objcopy in the
*INSTALL* phase is likely why (paths are different between the two)
Warner
mail to "freebsd-stable-unsubscr...@freebsd.org"
Everytime, not sure why I am trying to run btxld and objcopy in
install phase, I am simply running the command make installworld
I do use env variables to change paths, as I install to a ZFS clone of
the original system dataset then change boot setting on pool and
reboot.
Environment Variables used during build and install, been doing this
process ever since I started using ZFS boot on FreeBSD 9.2.
setenv MAKEOBJDIRPREFIX /jails/devel/ROOT/usr/obj
setenv DESTDIR /jails/devel/ROOT
setenv __MAKE_CONF /jails/devel/ROOT/etc/make.conf
setenv SRCCONF /jails/devel/ROOT/etc/src.conf
I had already started a new build specifying CPUTYPE=silvermont in
make.conf, as attempt work around. It failed as well. I did check and
the path above exists on the system
:/jails/devel/ROOT/usr/obj/jails/devel/ROOT/usr/src/amd64.amd64/stand/i386/btx/btx
# ll
total 10
-rw-r--r-- 1 root wheel 117B Feb 22 10:13 .depend.btx.o
-rwxr-xr-x 1 root wheel 1.7K Feb 22 10:37 btx*
-rw-r--r-- 1 root wheel 5.4K Feb 22 10:13 btx.o
drwxr-xr-x 2 root wheel 4B Feb 22 10:13 include/
I have removed my CPU Type specification and will run a new make and
install capturing full logs so that I can post a link to full logs.
I did a new build and capture output from full buildworld and
installworld, but first I cleared ccache same error was a result.
Here is the entire output along with my make.conf and src.conf files.
https://nextcloud.dweimer.net/index.php/s/YYx6WX7KieatM9L
--
Thanks,
Dean E. Weimer
http://www.dweimer.net/
_______________________________________________
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Do you guys know which part of my configuration is triggering this
issue, so I can work around it for now? My last build attempt with the
latest updates for the security fixes failed to install even with patch.
I've been able to reproduce it locally with a stock config twice or
so, but it's non-trivial and only seems to reproduce with at least a
nullfs objdir. A good data point would be to point your
MAKEOBJDIRPREFIX at /jails/devel/host-usr-obj (assuming that's not
null-mounted) -- as long as you're still operating out of
/jails/devel/ROOT/usr/src, the paths relative to it will work out the
same.
Thanks,
Kyle Evans
_______________________________________________
I am hitting this very often on stable/13. If you are building world
WITH_META_MODE, then it can be worked around by making world again with
only one make job.
--
Marek Zarychta
_______________________________________________
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
