FWIW I recently added logic to our local.rc.subr to
redirect output to a console.log if desired (some platforms boot quicker
with less output going to console). It does nothing for output from
kernel modules loaded by rc, but greatly reduces output and has the
major benefit that we can examine the
Nuno Teixeira wrote:
> Just to check that I'm using the correct setting for WITH_META_MODE
> since almost everytime I update main tree, I got clang compiled.
>
> Is that normal?
Quite possibly. You can add -dM to your make command line and meta mode
will explain why it thinks a target is out o
Ed Maste wrote:
> Pros of zstd:
> - Faster compression and decompression speeds.
> - Aligns with the compression method used for FreeBSD packages.
FWIW this should also allow the sets to be mountable using tarfs?
Browse the content without having to unpack.
bob prohaska wrote:
> What cleaning options minimize interference with the use of WITH_META_MODE ?
FWIW I very rarely clean a tree where I use META_MODE, maybe once a year
or so.
> Occasionally buildworld stops because of a missing dependency, usually
> just re-running git pull fixes the proble
Lexi Winter wrote:
> > meta mode makes very little difference for a clean tree build,
> > it is only update builds where the .meta files become super useful.
>
> this was a build updating an existing obj tree from
>
> ~53314e34d5e8e7f781ab990805b22f7a56bc0580
>
> to
>
> ~22429a464a5f4f6bb5a056
Would need more context to comment.
Do you have filemon(4) loaded?
meta mode makes very little difference for a clean tree build,
it is only update builds where the .meta files become super useful.
Though they are always good for build failure triage - helps if you have
MK_META_ERROR_TARGET=yes
Maku Bex wrote:
> * What (if any) "max_jobs" (make's "-j" parameter) are you using? 16
BTW if you use 'buildworld-jobs' jobs.mk will default to -j 1.33C (1.33 *
ncpu) and also save the output to ../buildworld.log
1.5C also works pretty well for me (the C isn't strictly needed so long
as arg to
FWIW make itself does not care about whether there is space after -j or
not. Both -j14 -j 14 will result in "-j 14" being added to .MAKEFLAGS
(something that really annoys me ;-)
So not even a makefile that is attempting to parse .MAKEFLAGS is likely
to be screwing things up.
In short; I would e
Dan Mack wrote:
> Ack, okay. I can't trigger it with a fresh or my /usr/obj but in any
> event the error number 6 is probably referring to a path or directory
> missing while doing a parallel build given some input state :-)
See the BUGS section of make(1):
In jobs mode, when a target fai
Michael Butler wrote:
> > I have found that *only* on arm64, locate errors like so:
> >
> > # sh /etc/periodic/weekly/310.locate
This runs /usr/libexec/locate.updatedb as nobody
and ensures that /var/db/locate.database exists and is owned by nobody,
but /var/db itself is root:wheel and 755 so the
Dag-Erling Smørgrav wrote:
> Loader I/O performance is much better these days so loading modules
> pre-boot doesn't slow the boot down much any more, but it's still more
That depends very much on the h/w, especially the storage attachment.
None of which applies to any machine likely to be using
Marek Zarychta wrote:
>
> What about filesystem perfomnace ? Have you benchmarked your FS and
> whole system with and without filemon loaded ?
FWIW filemon does nothing unless make opens the device.
and then it only impacts syscalls done by that pid and its children.
> I am not questionining t
nd
and thus we can use DIRDEPS_BUILD to optimize our builds.
--sjg
> Simon J. Gerraty escreveu (domingo, 28/01/2024 à(s) 01:43):
> >
> > > I use meta-mode in /etc/src-env.conf so that if (for example) a small
> > > change in the kernel config is made, the mac
> I use meta-mode in /etc/src-env.conf so that if (for example) a small
> change in the kernel config is made, the machine doesn't take hours
> recompiling.
> But, from time to time, one might be required to make
> cleanworld && make cleandir (to be sure) && make clean (to be *really* sure)
Almo
Rick Macklem wrote:
> > kern.rpctls.tls.snd_msgbytes: 20828
> > kern.rpctls.tls.snd_msgcnt: 57
> > kern.rpctls.tls.rcv_tmsgbytes: 12336
> > kern.rpctls.tls.rcv_msgcnt: 57
> >
> > which allows for sysctl kern.rpctls.tls
> Not sure what you mean?
If for some reason I only care about tls I can do
s
Freddie Cash wrote:
> Have no technical comments, but a style suggestion: put the tls at the end
> to make the output look nicer. :)
>
> kern.rpctls.snd_msgbytes: 21508
> kern.rpctls.snd_msgbytes_tls: 20828
> kern.rpctls.snd_msgcnt: 58
> kern.rpctls.snd_msgcnt_tls: 57
> kern.rpctls.rcv_msgbyte
> the loader program. You may also have to disable the lua build, since it uses
> more stack and is just a smidge
> larger than the forth build. _simp will be the smallest of them
> all. On my system, without bearssl, I see:
Back when I first did the LOADER_VERIEXEC bits, I found lua
pushed thing
Warner Losh wrote:
> > ld-elf.so.1: /usr/local/bin/git: Undefined symbol "__libc_start1@FBSD_1.7"
>
> This is a symptom of trying to run a prog built for target on a host
> which is not the same.
> Your path is messed up then. We always run (a copy of) the host's binaries
I wasn't using the tar
Mark Millard wrote:
> I will not get into why, but I executed a git built for 1400082
> in a 1400081 world context and got what was to me a surprise,
> given that /lib/libc.so.7 is part of 13.2-RELEASE :
>
> ld-elf.so.1: /usr/local/bin/git: Undefined symbol "__libc_start1@FBSD_1.7"
This is a sym
Mark Millard wrote:
> > Perhaps you want to be using
> >
> > .MAKE.META.IGNORE_PATHS+= ${MAKEOBJDIRPREFIX}/tmp/legacy/usr
> > or is that ${MAKEOBJDIRPREFIX}/${TARGET}.${TARGET_ARCH}/tmp/legacy/usr
> >
>
> I had started with trying to use MAKEOBJDIRPREFIX but it
> appeared to end up with an empty
>
> First some output log lines around a few sbin/realpath "is newer than"
> related Building lines, with the .info lines in place now (I've
> got both kmod.mk and kern.mk with the .info line, likely producing
> redundant output but I did not know up front for sure):
>
> make[4]: "/usr/main-src/s
Mark Millard wrote:
> Simplifying context . . .
> . . .
> > As I mentioned previously, there is no variablity of OBJTOP within the
> > context of a single make instance - at least not once it starts running
> > targets.
> >
> >> . . .
> >
> > .MAKE.META.IGNORE_PATHS += ${OBJTOP}/tmp/legacy/usr
>
Mark Millard wrote:
> [External Email. Be cautious of content]
>
>
> [Note for "how many separate bmake instances are in that log?":
> I do not know how to tell how many submakes are run total. It
> was with -j32 on the threadripper 1950X, if that is was you
> were after.]
You can get a clue f
Mark Millard wrote:
> So I was hoping for a "assigned once and
> inherited" status relative to submakes for
> .MAKE.META.IGNORE_PATHS .
No, .MAKE.* are specifically named to ensure they cannot come from the
environment. So bounding them in a check for level 0 pretty much
ensures they have no eff
Mark Millard wrote:
> So with -ddM why do I see lots of "cached_realpath:"
> notices for the same path? For example:
how many separate bmake instances are in that log?
>
> # grep "tmp/legacy/usr/sbin/ln\>"
> /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/typescript-make-amd64-nodbg-cla
Mark Millard wrote:
> >> Also, OBJTOP is not constant over all the parts of
> >> buildworld buildkernel . Having the late-substitution
> >> form of notation ${OBJTOP} might not be appropriate
> >> for the content of .MAKE.META.IGNORE_PATHS .
> >
> > Fwiw .MAKE.META.IGNORE_PATHS is evaluated when m
Mark Millard wrote:
> The contribution to the list is currently generated via
> use of:
>
> .if ${.MAKE.LEVEL} == 0
Why is this guarded by .MAKE.LEVEL 0?
.MAKE.META.IGNORE_* should be largely irrelevant at level 0
which in the DIRDEPS_BUILD is reserved for orchestration.
Even in the legacy build
Mark Millard wrote:
> It appears that for symbolic links being the target, META_MODE does
> not respect .MAKE.META.IGNORE_PATHS .
The handling of links is rather complicated ;-)
Among other things, the src needs to be treated as for a Read and the
target as for Write
Note that .MAKE.META.IGNORE
Mark Millard wrote:
> >
> > Is there anything under ${OBJTOP}/tmp that you don't want to ignore?
>
> More than just _bootstrap_tools_links entries end up in
> ${WORLDTMP}/legacy/bin/ (so in ${WORLDTMP}/legacy/sbin/
> via the symbolic link pointing to ${WORLDTMP}/legacy/bin/ ).
> So: yes.
>
> Al
Simon J. Gerraty wrote:
> > > strings `which bmake` | grep META.IGNORE
> > > .MAKE.META.IGNORE_PATHS
> > > .MAKE.META.IGNORE_PATTERNS
> > > ${.MAKE.META.IGNORE_PATHS:O:u:tA}
> >
> > The -dM output's "is newer than the target" lines
&
Mark Millard wrote:
> Thanks for the information.
>
> > strings `which bmake` | grep META.IGNORE
> > .MAKE.META.IGNORE_PATHS
> > .MAKE.META.IGNORE_PATTERNS
> > ${.MAKE.META.IGNORE_PATHS:O:u:tA}
>
> The -dM output's "is newer than the target" lines
> show the path from before the above transform
Mark Millard wrote:
> Since some of the paths reported ended up being links
> (symbolic, as I remember), what are the principles for
> which form of paths should be the basis for paths in
> the likes of:
>
> .MAKE.META_IGNORE_PATHS
.MAKE.META.IGNORE_PATHS
> .MAKE.META.IGNORE_PATTERNS
> .MAKE.ME
> The timestamp on . . ./tmp/legacy/usr/sbin/rm is not
> actually relevant to if libc++.a needs to be rebuilt.
> >>
> >> True.
> >> If there is nothing under .../tmp/legacy that should be counted you can
> >> just:
> >>
> >> .MAKE.META_IGNORE_PATHS += that path
>
> Was that supposed to b
This has been fixed upstream, I'll look at importing an update.
Stephane Rochoy wrote:
> It may be worth contacting BearSSL's maintainer directly: Thomas
> Pornin . The guy was very responsive and helpful
> back in 2020 :)
Indeed.
Warner Losh wrote:
> Would be nice if we could get upstream to actually fix this, but i don't even
> know how to submit bugs there…
>
> Agreed. I didn't recall off of the top of my head, so I did the quick bandaid.
I can reach out to the author, I don't know that he has a bug tracker.
What is
Warner Losh wrote:
> I think I broke it with my latest updates. I don't have a good ZFS testing
> setup
> so I'm spending a little time enhancing the bootable image generator to have
> one that I can easily test boot with qemu.
FWIW bhyve is *excellent* for mucking about with EFI and loader in g
Toomas Soome wrote:
> > Why should pxeboot have ZFS support?
>
> Well, the feature X can be helpful for recovery purposes. The root
> cause is not the feature X itself, but the size limit. And the
> unfortunate fact, the size limit is not fixed, but depends on the
> system. Therefore there are tw
Brooks Davis wrote:
> On Tue, Feb 08, 2022 at 02:52:27PM -0800, Simon J. Gerraty wrote:
> > Brooks Davis wrote:
> > >
> > > This would be fine, but should not be necessicary. The sys subdir should
> > > be created by AUTOOBJ.
> >
> > .OBJDIR sh
Brooks Davis wrote:
>
> This would be fine, but should not be necessicary. The sys subdir should
> be created by AUTOOBJ.
.OBJDIR should be (and is), not .OBJDIR/sys
making that subdir is up to the makefile and would also fix the problem,
but given the nature of what the makefile is doing just r
Warner Losh wrote:
> > Same here for me for the past couple of weeks. Haven't been able to
> > identify why it fails. My hunch was that a particular objdir wasn't
> > being created. As a workaround I edited the Makefile.inc1 to remove
> > the test-includes command (line 1128 I think).
>
> The sys
Warner Losh wrote:
> --- sys/abi_compat.c ---
> echo "#include " > sys/abi_compat.c
> sh: cannot create sys/abi_compat.c: No such file or directory
> *** [sys/abi_compat.c] Error code 2
>
> make[4]: stopped in /usr/src/tools/build/test-includes
> --- sys/acct.c ---
> echo "#include " > sys/acct.c
O. Hartmann wrote:
> > If reverting this does not help, can you try with:
> > sysctl vfs.cache_fast_lookup=0
>
> reverting the mentioned commit helped and made things working as expected
> again.
>
> Thank you very much.
Sorry looks like bsd.links.mk expects full paths.
Can you confirm the bel
dan_parte...@rdsor.ro wrote:
> [External Email. Be cautious of content]
>
>
> Hey guys,
>
> What are the config knobs for enabling the veriexec driver and veriexec
> mac modules for testing and playing with this new subystem ? User mode
> knob for user mode tool and lib is documented in man src
Mark Millard via freebsd-current wrote:
> >> Given an already built, installed and booted system version, I've
> >> noted a big difference for META_MODE in 2 rebuild contexts (no
> >> source updates involved):
> >>
> >> *) Prior buildworld buildkernel, installkernel, installworld, boot
> >> presu
Steve Kargl wrote:
> Suppose further that one had to re-install a 32-bit
> i386-*-freebsd with the 24 Dec 2020 image available
> from freebsd.org.
>
> uname -a for the booted kernel shows
>
> % uname -a
> FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #0 \
> 3cc0c0d66a0-c255241(main)-dirty: Th
Poul-Henning Kamp wrote:
> When I start cad/kicad (which I have not done in some time), the
> gui is horribly lagging and often downright confused about
> the cursors whereabouts.
May not be relevant but FWIW I saw similar issue with kdenlive-19.12 on
11.3 kdenlive-18.x worked fine [kdenlive] [Bu
Mark Millard wrote:
> > though the one in ports is real issue:
> >
> > $ make config
> > make: "/usr/ports/Mk/bsd.port.mk" line 2096: warning: String comparison
> > operator should be either == or !=
> > make: "/usr/ports/Mk/bsd.port.mk" line 2096: Malformed conditional
> > (defined(MAKE_JOBS_NU
Mark Millard wrote:
> [External Email. Be cautious of content]
>
>
> This seems to have broken doing buildworld buildkernel and
> other things using make:
Ouch sorry I saw this at one point but couldn't reproduce while trying
to work out what it was complaining about.
The line numbers did/do n
Warner Losh wrote:
> > loader.conf says
> >
> > rootfs_load="yes"
> > rootfs_name="contents.izo"
> > rootfs_type="md_image"
> > vfs.root.mountfrom="cd9660:/dev/md0.uzip"
> >
> > contents.izo is uzip'd contents.iso which file(1)
> > describes as ISO 9660 CD-ROM filesystem data ''
> >
> > That's for
Rodney W. Grimes wrote:
> > The "fake cd drive" is in the kernel, loader just copies the iso into
> > memory like any other module, and by the time that's done you just
> > reboot into the newly installed system, which again uses
> >
> > vfs.root.mountfrom="cd9660:/dev/md0.uzip"
>
Rodney W. Grimes wrote:
> > Are you refering to something like:
> >
> > vfs.root.mountfrom="cd9660:/dev/md0.uzip"
> >
> > we boot that way all the time.
>
> What provides the cd9660 driver to FreeBSD? When you load the .iso
> over a network card, aka PXE/HTTP, the code that does that usually
> c
Rodney W. Grimes wrote:
> > I'm curious if it should be possible to point to a img/iso directly (I
> > tried to use the img.xz unpacked it and make it available on a local web
> > server and that didn't seem to work for me) but maybe thats cause those
> > images miss something, so arm64 aside doe
Hi,
Interesting, maybe ng_eiface + if_bridge is a good idea .
Simon
20200422
On 4/21/20 8:51 PM, Jan Bramkamp wrote:
On 16.04.20 08:34, Pavel Timofeev wrote:
вт, 14 апр. 2020 г., 12:51 Kristof Provost :
Hi,
Thanks to support from The FreeBSD Foundation I’ve been able to work
on
Fixed in r359769
Hartmann, O. wrote:
> While recent CURRENT doesn't show any problems, 12-STABLE (r359768)
> drops out from buildworld with the error shown below when option
>
> WITH_BEARSSL= YES
>
> is set in /etc/src.conf
___
freebsd-current@freebs
Hartmann, O. wrote:
> While recent CURRENT doesn't show any problems, 12-STABLE (r359768)
> drops out from buildworld with the error shown below when option
>
> WITH_BEARSSL= YES
Sorry, I did buildworld just before committing r359735
but I use ficl, - missed the below for lua.
Will fix.
>
> i
Warner Losh wrote:
> True, but as we move from boot1.efi to loader.efi, the need will
> grow... Even if we keep boot1.efi, loader.efi will be needed for
> interesting secure systems, so we can't cop-out like we have in the
> past.
Sigh, that would force me to have to add verification to boot1.ef
Nathan Whitehorn wrote:
> It's basically this that has been the problem: we need a way to manage
> updates of the EFI loader in this situation, which we don't currently
> have. The ESP needs to be mounted at a standard point,
> installworld/freebsd-update/etc. need to know to replace files there,
Rebecca Cran wrote:
> That's another thing: we should be installing loader.efi as
> \efi\boot\bootx64.efi (as well as \boot\freebsd\loader.efi) since it's
> entirely possible to lose the Boot Manager entry and end up with an
> unbootable system as a result. Unfortunately people have had bad
> expe
Ed Maste wrote:
> Any comments on this plan? Does anyone use the -pg compiler flag and
> the _p.a profiling library archives?
We have teams that do - on a semi regular basis.
If there's an alternate method to allow them to find hot-spots etc in
userland code we can direct them accordingly I expe
Clay Daniels Jr. wrote:
> Simon, please do elaborate more on your implementation. I suspect you are
> talking about libsecureboot? I have played with the generation of certs
> with OpenSSL & LibreSSL, but libsecureboot seems to take a different
> approach. Please tell us mo
Tomasz CEDRO wrote:
> would be really nice also to get UEFI BOOT compatible with SECURE BOOT :-)
Unless you are using your own BIOS, the above means getting Microsoft
to sign boot1.efi or similar. Shims that simply work around lack of
acceptible signature don't help.
That would need to then ver
Cy Schubert wrote:
> > installworld is failing with:
> >
> > ===> lib/libc/tests/hash (install)
> > install -o root -g wheel -m 555 hash_test
> > /usr/tests/lib/libc/hash/hash_t
> > est
> > make[7]: don't know how to make _testsDATA_FILESINS1_data/md5test-in. Stop
Sorry about that. Looks li
Alan Somers wrote:
> I would've thought that immediately following a sync(8), the
> filesystem would be consistent. Why do I still see errors after a
sync(8) does little more than tell the kernel to start flushing some
pages - which the kernel would do anyway in about 30s
So, it does not really
Warner Losh wrote:
> > At the risk of being branded a wishful thinker, a firstboot script that
> > asked the user for some configuration information would be a great help
> > to both new and experienced foot-shooters. I'm thinking of Raspberry Pi,
> > but perhaps it applies to non-embedded platfor
O. Hartmann wrote:
> I'm able to reproduce this behaviour easily: make cleanworld; kldload filemon
> (if not
> already loaded); make buildworld buildkernel
Why are you doing cleanworld?
> After the build has finished, install everything accordingly and reboot. Then
> kldload
> filemon and make
O. Hartmann wrote:
> delete-old|-libs afterwards, I started again a build (filemon loaded!). And,
> surprise,
> surprise, compilation of all the long-haul taking LLVM/CLANG stuff starts
> again! That is
> not funny.
If you have META_MODE enabled -dM will tell you if meta_oodate
decided the targ
Rodney W. Grimes wrote:
> Thank you, that does help narrow it down: (I backed up a vew lines
> from the first place I saw src/.)
>
> ...
> Global:.PARSEFILE = bsd.kmod.mk
> Global:.PARSEDIR = /usr/src-topo/share/mk
> Global:.PARSEFILE = bsd.kmod.mk
> Result[] of :U is "/usr/src/sys"
> Result[] o
Rodney W. Grimes wrote:
> I am having a compile time issue for a patched that compiled fine on my
> r329294 system, but now failes to compile with what looks like a wrong
> header being included.
You may find it helpful to do something like:
make -dv -C sys/modules/vmm -V CFLAGS > /tmp/dvo 2>&1
Mark Millard wrote:
> [Plain "make" works (no -j ).]
>
> Is it expected that -j1 and the like get what I report below?
A bug in the makefile (eg conflict b/w .ORDER and dependencies)
will result in that sort of noise.
-j1 is still jobs mode
___
freeb
Simon J. Gerraty wrote:
> David Wolfskill wrote:
> > ===> Building for nvidia-driver-340-340.102
> > ===> src (all)
> > make[6]: "/usr/src/share/mk/bsd.obj.mk" line 89: Malformed conditional
> > (defined(SRCTOP) && (${CANONICALOBJDIR} == /${
David Wolfskill wrote:
> ===> Building for nvidia-driver-340-340.102
> ===> src (all)
> make[6]: "/usr/src/share/mk/bsd.obj.mk" line 89: Malformed conditional
> (defined(SRCTOP) && (${CANONICALOBJDIR} == /${RELDIR} || ${.OBJDIR} ==
> /${RELDIR}))
> make[6]: Fatal errors encountered -- cannot c
Mark Millard wrote:
> # ls -lTt /media/boot/kernel/if_igb.ko /mnt/boot/kerndb/if_igb.ko
> lrwxr-xr-x 1 root wheel 25 Sep 8 22:47:36 2017 /mnt/boot/kerndb/if_igb.ko
> -> /mnt/boot/kernel/if_em.ko
> lrwxr-xr-x 1 root wheel 68 Sep 6 20:27:20 2017
> /media/boot/kernel/if_igb.ko ->
> /usr/ob
O. Hartmann wrote:
> I just updated to r322769 and now I face this when trying to recompile
> kernel/world again:
>
> make: "/usr/src/share/mk/bsd.compiler.mk" line 142: warning: "cc --version ||
> echo 0.0.0"
> exited on a signal make: "/usr/src/share/mk/bsd.compiler.mk" line 155: Unable
>
Konstantin Belousov wrote:
> I just find is somewhat strange that make initiates a new session.
In jobs mode it does - to ensure the child and all progeny can be killed
in one fell swoop.
In compat mode it does not, but that does not mean the child cannot do
so.
> Did you verified that enabling
Hi Dmitry
Thanks for the detailed report.
Will take a look
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215572
> Now to fix this, I suggest that instead of killing itself, make should
> signal all its childs carefully and wait() on them, only then die
> itself.
>
> Now after a quick
blubee blubeeme wrote:
> Thanks for the reply, I haven't set any -static in my env variables or
> anything like that. Here's a brief output of my env
> the linking to ldl is being done automatically since I call autoreconf -fi
> and that sets up an m4 directory. grep -rn "\-ldl" in the root of t
blubee blubeeme wrote:
> I run autoreconf -fi and it asks me to add AC_CONFIG_MACRO_DIRS([m4]) to my
> configure.ac file, which I do. It creates a ./m4 directory and proceeds.
>
> After running .configure --prefix=/tmp [for testing] that' also goes fine,
> except .configure cannot find dlopen
> c
Thomas Mueller wrote:
> Just because I found a workaround does not mean it is not a bug.
Sorry I don't know what else to tell you.
make is behaving as it should, based on the way it is configured.
That setup was deemed the most useful by those working on src/,
so is not likely to be changed.
I
David Wolfskill wrote:
> On Thu, May 25, 2017 at 05:07:19AM -0700, David Wolfskill wrote:
> > This is on my "build machine"; running GENERIC/amd64 built yesterday:
> >
> > FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #353
> > r318739M/318739:1200031: Wed May 24 10:00:20 P
Thomas Mueller wrote:
> When I did those last examples, that last line was
> env MAKESYSPATH=/usr/share/mk make all-depends-list
ok, that makes sense.
> > > and then it seems to work correctly with no syntax error in
> > > /BETA1/usr/share/mk/bsd.compiler.mk
> >
> > > Maybe I need to file a bug.
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 r
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
Thomas Mueller wrote:
> I go into /BETA1/usr/ports/ports-mgmt/synth , run
> env MAKESYSPATH make all-depends-list
I assume you mean MAKESYSPATH=something? otherwise env itself should
vomit
> and then it seems to work correctly with no syntax error in
> /BETA1/usr/share/mk/bsd.compiler.mk
>
> M
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
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
Thomas Mueller wrote:
> For building the system, MAKESYSPATH should be $SRCDIR/share/mk , to be in
> sync.
>
> I tried "make -V MAKESYSPATH" from several SRCDIRs, and that's what happened.
Yes. If you look at share/mk/src.sys.env.mk
it detects that it was found via a .../ path, and replaces it
Thomas Mueller wrote:
> It seems to me that MAKESYSPATH should match the host building system
> FreeBSD version.
Which would only be correct if building the same version of FreeBSD as
is running on the host.
Many folk work on multiple branches on the same machine.
Thus for anyone working on src/
Thomas Mueller wrote:
> I tried building ports, starting with ports-mgmt/synth, on HEAD
> (12-current) and ran into difficulties with syntax error in
> bsd.compiler.mk .
>
> With PORTSDIR on another partition, mounted as /BETA1, I got these
> errors, but not when I null-mounted /BETA1/usr/ports
David Chisnall wrote:
> Ideally, we’d solve this by fixing bmake to behave more like a modern
> build tool and:
It's called meta mode ;-)
and makes the OP's real issue much easier - when build fails, the
failing .meta file is saved in src/../error/ providing no doubt and no
need to search.
Roger Pau Monné wrote:
> $ cd /home/royger/buildjob/freebsd
> $ make -j30 buildworld MAKEOBJDIRPREFIX=/home/royger/buildjob/obj/
That will not work as desired.
When you set VAR=val as an argument to make,
it overrides anything the makefiles want to do
and there are a number of points where the t
Bryan Drewery wrote:
> Oh now I get it too after updating system from head from r317177 to
> r318116. So it seems to be a bug in bmake-20170420.
What's in your env?
Eg.
env | grep MAKE
ls
> > ~/git/freebsd # make check-old
> > make warning: E No such file or directory.
> > make warning: E No s
David Wolfskill wrote:
> I placed it in /etc/src.conf; thus:
>
> g1-252(11.0-S)[1] cat /etc/src.conf
> KERNCONF=CANARY
> PORTS_MODULES=x11/nvidia-driver-340
> .MAKE.META.IGNORE_PATHS += /usr/local/etc/libmap.d
> WITHOUT_DEBUG_FILES=1
> IWN_DEBUG=1
> IEEE80211_DEBUG=1
> WITH_ELFCOPY_AS_OBJCOPY=1
Ngie Cooper (yaneurabeya) wrote:
> I see similar oddness when running some commands. It seems to be happening as
> of the last month or two.
>
> $ make buildenv TARGET_ARCH=armv6
> make warning: I: No such file or directory.
> make warning: I: No such file or directory.
> Entering world for armv
O. Hartmann wrote:
> > .MAKE.META.IGNORE_PATHS += /usr/local/etc/libmap.d
> >
> > --sjg
>
> I suppose I have to set this flag in
>
> /etc/src-env.conf
That should work.
Let us know how it goes
___
freebsd-current@freebsd.org mailing list
https://lis
Konstantin Belousov wrote:
> If I understand the motto of meta-mode, any file change is detected for any
> file accessed during the build. All dynamically-linked binary includes
> the rtld into the process image, and rtld reads all config files in the
> libmap.d subdirectories. The end result is
O. Hartmann wrote:
> It is weird!
>
> Today, after yesterday's built, I face the same 90 minutes build horror
> again, this time
> I switched on "-dM" with the make command.
>
> This happens:
>
> [...]
> /usr/obj/usr/src/lib/clang/libllvm/_usr_obj_usr_src_lib_clang_libllvm_CodeGen_SelectionDAG
Hi,
> I build CURRENT on two technically similar systems on a almost daily basis.
> Therefore, it
> was a great relief having WITH_META_MODE=yes set in /etc/src-env.conf for
> incremental
> builds. To make my understanding of this clear (just in case I'm wrong):
> setting
> WITH_META_MODE build
> > [Creating objdir /usr/obj/usr/obj/root/git/freebsd/sys/GENERIC...]
> Wrong^
>
> Note we have 'cd /usr/obj/' and 'MAKEOBJDIRPREFIX=/usr/obj' in
> there, so we get a nested /usr/obj/.CURDIR problem of /usr/obj/usr/obj.
The following would probably help that case:
Index: auto.obj.mk
===
1 - 100 of 321 matches
Mail list logo
