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
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
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
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
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
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
>
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
On Fri, 30 Nov 2012 08:15:03 -0700, Ian Lepore writes:
>So when did this break, and why can't it be fixed? I've been using
Sorry I missed the begining of this thread,
is anything broken?
>Also, how about "make DESTDIR=foo buildkernel installkernel" which is
>something I've been doing for years,
On Tue, 17 Jun 2014 11:35:42 -0700, Craig Rodrigues writes:
>Do you know if there is some sort of patch that can be applied to
>FreeBSD stable/9 sources so that it can be built on a FreeBSD
>10/stable, or FreeBSD CURRENT
>host with bmake?
You would likely need to apply many of the changes made in
Sorry, I didn't speak to the problem you hit...
On Tue, 17 Jun 2014 11:35:42 -0700, Craig Rodrigues writes:
>> If I build like this:
>>
>> env TARGET=amd64 TARGET_ARCH=amd64 make -j 9 SRCCONF=/dev/null
>> __MAKE_CONF=/opt/local/branches/freenas/os-base/amd64/make.conf.build
>> NO_CLEAN=1 buildworl
>> Why not use fmake in that scenario?
>
>That might work. Is using the devel/fmake port sufficient for using fmake?
So long as it is recent enough to have :tu and :tl I would expect so.
>If I typed "make something", is there a way inside the make environment to
>detect if bmake or fmake was in
>Removal of EARLY_BUILD is not the issue here, I have no idea where the
>hell the came into play.
>
>It is a race in the chain with what make(1) gets built for the stable/9
>userland. It is why the 'make make buildworld' thing I mentioned works.
IIRC all the fixes I put into src/Makefile to ensur
On Sat, 21 Jun 2014 18:55:40 -0400, Glen Barber writes:
>> make make && make -j8 -DNO_CLEAN buildworld
>
>This is, IMHO, the worst solution I've heard on this topic so far.
I didn't say it was a good solution - but if you want -j you may not
have a choice (unless you fix src/Makefile).
__
>today I got confronted with this little curiosity from bmake. I have
>built and installed the world, and after reboot I ran 'make delete-old'
>as root to get rid of accumulated stale files. This is what I got back:
>
Removing old files (only deletes safe to delete libs)
>
Old files r
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
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.
This has been fixed upstream, I'll look at importing an update.
> 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
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
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
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:
> >
> > 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
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:
> 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:
> >> 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:
> 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:
> 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:
> [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:
> 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
>
>
> 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:
> > 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
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
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
> 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
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
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
> 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
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
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
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
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
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} == /${
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
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
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
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
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
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,
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
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
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
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
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:
> > 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"
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
101 - 178 of 178 matches
Mail list logo
