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
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
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
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
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
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
still mucking about trying to get a VM image booting using efi...]
>
> Clay
>
> On Mon, Oct 14, 2019 at 1:52 PM Simon J. Gerraty via freebsd-security <
> freebsd-secur...@freebsd.org> wrote:
>
> > Tomasz CEDRO wrote:
> >
> > > would be really nice a
Julian Elischer wrote:
> On 1/28/15 1:41 PM, Julian Elischer wrote:
> > If I try the following:
> >
> > bar: .USE
> > @echo @ = $(@)
> > all: bar
> > @echo here is all
> oops
> the failing example should be .USEBEFORE.. I pasted the wrong clip.
> >
> > I always get "bar is up to
Ian Lepore wrote:
> under bmake. It's especially annoying because :L is really common in
> fmake and its meaning in bmake is all but useless.
Actually it is very useful. eg.
.if defined(NO_POSIX_SHELL) || ${type printf:L:sh:Mbuiltin} == ""
___
freebsd
Craig Rodrigues wrote:
> On Sun, Jun 14, 2015 at 8:09 AM, Adrian Chadd wrote:
>
> + make -j 4 CROSS_TOOLCHAIN=amd64-gcc buildworld
> __MAKE_CONF=/builds/FreeBSD_HEAD_amd64_gcc4.9/make.conf
> make: "/builds/FreeBSD_HEAD_amd64_gcc4.9/Makefile" line 102: Malformed
> conditional (${M
Garrett Cooper wrote:
> On Jun 14, 2015, at 14:18, Simon J. Gerraty wrote:
>
> > Craig Rodrigues wrote:
> >> On Sun, Jun 14, 2015 at 8:09 AM, Adrian Chadd wrote:
> >>
> >>+ make -j 4 CROSS_TOOLCHAIN=amd64-gcc buildworld
> >>__MAKE_
Konstantin Belousov wrote:
> I see the same problem on the up-to-date stable/10 host, trying to build
I'm building HEAD on stable/10, I just updated the tree and did a clean
tree buildworld ok.
> HEAD. This is completely unacceptable, we have documented and always
> supported just
> make
Garrett Cooper wrote:
> > Now that "vanilla" head @284408 builds (& boots):
I fixed this the other day - just realized I haven't committed it.
> > make[6]: don't know how to make
> > /common/S3/obj/usr/src/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-346.47/src/machine.
Garrett Cooper wrote:
> More breakage from projects/bmake. This should be fixed in theory, but
> bapt/sjg can confirm if it’s fixed. Cheers,
Yes, sorry everyone - took a bit to identify the root cause
(ie. specific line)
*Should* be fixed now.
___
fre
Garrett Cooper wrote:
> >> There is yet another issue with the build system, I have
> >>INSTALL+=-CS
> >> in make.conf for around 15 years. Apparently it is broken now.
> >
> > Ah! make.conf is getting included earlier.
> > So that {local,src}.sys.mk can be included earlier so that any of th
Thanks very much for the test David
David Wolfskill wrote:
> OK; following up: I see Simon committed r284420; after hand-appling that
> (1-line fix); I performed:
...
> Each was successful:
___
freebsd-current@freebsd.org mailing list
http://lists.freeb
Rainer Hurling wrote:
> I just tried r284421 and get another error. My '/etc/src.conf' includes
> 'WITH_LLDB=1':
A couple of folk have issue with WITH_LLDB
seeing if I can reproduce
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org
Andriy Gapon wrote:
> > Seems like there is some problem with 'toolchain' target in the latest head.
> > Output of running `make toolchain TARGET=i386` on amd64 system can be found
> > here: http://dpaste.com/3RD3C4V
> >
>
> AFAICS, it still worked as of r283188.
There has been a clang update s
Andriy Gapon wrote:
> > do you have anything interesting in /etc/make.conf?
>
> Thank you for the hint -- __MAKE_CONF=/dev/null SRC_CONF=/dev/null fix the
> problem.
>
> Now I am trying to figure out what the problem is.
The problem will be that I shifted the include of make.conf and etc
to ea
Dimitry Andric wrote:
> Hmm, is this still not fixed? This was broken by Simon's large
> "meta-mode" commit r284345. but I would assume Baptiste's fixes after
> that might have fixed it. I can't test this myself at the moment, due to
> ENOTIME...
I think https://reviews.freebsd.org/D2860 will fi
Garrett Cooper wrote:
> > Am I the only one who fails to build recent base/head (r284673) on
> > pretty recent base/head (r284639)? This is on amd64 with ZFS and BEs.
>
> ...
>
> > CC=clang
> > CXX=clang++
> > CPP=clang-cpp
> You need to remove these lines. They shouldn’t have been set be
Justin Hibbits wrote:
> > Yeah, crossbuilds work fine. It's the actual run-on-real-hardware bit
> > that doesn't.
> >
> > (powerpc64 runs fine in qemu-devel; people should try it!)
>
> r284345 (introduction of metamode) is the problem. I bisected it on
> the power8 and it reliably fails this way
Jeffrey Bouquet wrote:
> If I've a spare /mnt/usr/src , it seems buildworld quite soon fails,
> where it otherwise may succeed in /usr/src. Any CLI parameters or> the
> build system is hardcoded enough so that there will always be
> problems?
The only thing hard coded is the default MAKEOBJDIRPR
Oliver Pinter wrote:
> We got this build failure, when two release make release running in parallel:
Can you elaborate what you mean by "two release make release" ?
Do you mean two separate builds running in the same tree at the same
time using the same DESTDIR?
> >>> stage 4.4: building everyth
Aleksey Kuleshov wrote:
> The uart_intr will never be called if interrupts are not available.
> Start counter with callout_reset call.
FWIW this fixed an issue we were investgating.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org
O'Connor, Daniel wrote:
> However, Crochet _does_ build on the NFS client _and_ when the source
> tree isn't in /usr/src which makes this issue very strange :-/
I've seen similar errors in rescue... (no NFS) though I cannot
quite recall the cause other than it seems very sensitive
to MAKEOBJDIRP
> Given that we have (or at least had at one time) some of those magical
> "..." paths that cause bmake to search up the hierarchy for its .mk
> files, I wonder if an odd relationship between src and obj dir confuses
> it, or if it somehow wanders into a wrong src tree while searching?
Based on Da
O'Connor, Daniel wrote:
> Yeah the subject is wrong (I just updated it).
>
> I just did a build like so and it worked..
> env MAKEOBJDIRPREFIX=/src/obj-amd64 make -j 8 buildworld
That's the right way to use it.
> But this did not..
> make -j 8 buildworld MAKEOBJDIRPREFIX=/src/obj-amd64
Nor sho
O'Connor, Daniel wrote:
> >> So, it seems MAKEOBJDIRPREFIX only works as an environmental variable
> Weird, I could have sworn I have set it on the command line and had it
> work, but..
In most "normal" usage you will likely not notice a difference.
It is only when a makefile is "being clever" t
Bryan Drewery wrote:
> 1: subdir make
> src.conf: STRIP=
> rescue/rescue% make all
> -> make -f OBJDIR/rescue.mk
>
> STRIP= is not passed down into rescue.mk, resulting in 'strip rescue'.
unless src.conf does .export STRIP, or submake reads src.conf for itself
this isn't surprising.
The r
Bryan Drewery wrote:
> I think the problem here is the use of -m for SUB_MAKE in /Makefile.
> Specifying -m share/mk causes all of the issues I've seen (expected
> including of /etc/src.conf), while not using -m does not include
> /etc/src.conf even though the build is being done in a src dir.
So
Bryan Drewery wrote:
> https://people.freebsd.org/~bdrewery/patches/world-ccache.diff
In the Junos build - where we used ccache for quite some time
I did:
_CC := ${CC}
CC = ${CCACHE_ENV} ${_CC}
Since sometimes you want the compiler without ccache - eg when linking.
That needs to happen after C
NGie Cooper wrote:
> I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS
> and I ran into this linker issue below. I have no idea (yet) why it’s trying
> to compile an x64 object when I specify powerpc/powerpc — and more
> importantly, why is the object not being put in o
NGie Cooper wrote:
> And here’s the real issue — .PATH is completely broken when
> TARGET/TARGET_ARCH are specified as explicit values:
It would help if you could indicate what you think the right value
should be.
> $ env MAKEOBJDIRPREFIX=/scratch/tmp/ngie/obj/ make buildenv TARGET=powerpc
>
> >> include/Makefile:MK_OSRELDATE_SH= ${.CURDIR}/mk-osreldate.sh
> >> include/Makefile: sh ${MK_OSRELDATE_SH}
>
> I actually wrote up a patch recently to use ${SH} in all places of 'sh'
> and '/bin/sh', and noted on SHELL?= that was not useful to use, but did
> not commit it (yet)
Hi Dan
> Meaning, is that simple to push things in head , if somone does the
> work, even with with no proper review of the problem at hand , and the
> proposed solutions ?
Not sure what sort of review you are looking for.
But I can speak to some of the history behind this.
FreeBSD holds regular
Craig Rodrigues wrote:
> I don't know much about locales, so don't know what to do.
I find LANG=C LC_ALL=C solves most locale induced issues.
I suspect the tests in question assume the above anyway.
___
freebsd-current@freebsd.org mailing list
https://l
Garrett Cooper wrote:
> We lack a [dtd/json] spec for tools, so programming for xo'ification
> doesn't seems like the best idea in the world to me from a end-user
> sysadmin/developer perspective.
A dtd etc is good for sure, and we (Juniper) do have them, as well as
ui-police to help ensure thing
Dan Partelly wrote:
> >> The ability to get machine parsable output from OS components is a big
> >> part of the success of Junos CLI, netconf etc.
>
> Once you get machine parsable output, and feed it to your GUIs , WEB,
> other tools, and modify it, how do you feed it back to your underlying
>
Dan Partelly wrote:
> Juniper can further help FreeBSD by donating the code of their
> system management daemon and their fine granularity permissions
At the cost of i18n etc?
The Junos UI is totally data driven, syntax is verified term by term
(since depending on your permissions some terms
Dan Partelly wrote:
> Management daemon with fine grained permission, extremely
> useful. Would Juniper consider donating to FreeBSD under a BSD license
> portions of this code, the MGD, which could be reused in FreeBSD ? A
Right now I suspect the answer to that might be "no".
We know we have com
John Baldwin wrote:
> +CLEANFILES+= ${_MFILES:R:S/$/.c/} ${_MFILES:R:S/$/.h/}
Since CLEANFILES is given to rm, you can use globs
CLEANFILES+= ${_MFILES:R:S/$/.[ch]/} or .?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman
Mark Millard wrote:
> My guess is that it is picking up the
>
> MAKEOBJDIRPREFIX=/usr/obj/xtoolchain
You should use ?= if you want this to work.
There are many places in Makefile.inc1 where MAKEOBJDIRPREFIX is tweaked
in the environment of a sub-make.
By using = above, you break that.
_
Mark Millard wrote:
> >> MAKEOBJDIRPREFIX=/usr/obj/xtoolchain
> >
> > You should use ?= if you want this to work.
> > There are many places in Makefile.inc1 where MAKEOBJDIRPREFIX is tweaked
> > in the environment of a sub-make.
> >
> > By using = above, you break that.
>
> That presumes that M
Firstly, nice writup - a few extra blank lines might have helped my eyes
though.
Bryan Drewery wrote:
> This mail is to outline my recent work, goals and motivations. This is
> long. This is not really a architectural review or discussion mail. I
...
> Some problems with the combined DIRDEPS_
Julian Elischer wrote:
> > Some improvements I have made recently:
> > - WITH_FAST_DEPEND: Replacing the antiquated 'make depend'/'mkdep' with
> > compiler dependency flags to generate the .depend files as a side-effect
> > of compiling. This saves tremendous time in buildworld and buildkernel.
>
Carsten Kunze wrote:
> current groff doesn't build on FreeBSD. I had noticed the same issue
> some months ago on NetBSD and cross checked on FreeBSD and it had
> worked on FreeBSD. There must have somethig changed since then. How
> to reproduce:
FreeBSD now uses same make as NetBSD ;-)
> Whe
Simon J. Gerraty wrote:
> Carsten Kunze wrote:
> > current groff doesn't build on FreeBSD. I had noticed the same issue
> > some months ago on NetBSD and cross checked on FreeBSD and it had
> > worked on FreeBSD. There must have somethig changed since then. How
Carsten Kunze wrote:
> Thomas Dickey wrote:
> > On Tue, Dec 15, 2015 at 04:01:41PM +0100, Carsten Kunze wrote:
> > > current groff doesn't build on FreeBSD. I had noticed the same issue some
> > > months ago on NetBSD and cross checked on FreeBSD and it had worked on
This should be fixed in he
Jung-uk Kim wrote:
> The attached patch fixed the build issues for me.
Since xo_config.h does not look like part of public api, this seems
appropriate.
I've committed this, while I check for other fallout.
Thanks
> Jung-uk Kim
___
freebsd-current@fre
Roger Marquis wrote:
> Don't know how to debug this and cannot post the Makefile in question but it
Can you provide something similar that triggers the issue?
It's rather hard to tell what's wrong without knowing what *should* be
happening.
> last worked in 8.4. In 11-CURRENT Var_Value appears
Mark Millard wrote:
> > .if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64"
> . . .
> > _filemon= filemon
> . . .
>
> Thus, for example, arm variants (32 bit and 64 bit) and powerpc
> variants (32bit and 64 bit) do not have WITH_META_MODE as an option as
> things are set up.
> Another reported issue just now is that right after an installworld,
> everything rebuilds due to changed /bin/sh (-dM flag to make tells you
> why things rebuild). I'll look into some mitigations for this.
It is probably sufficient to just add
.MAKE.META.IGNORE_PATHS += ${__MAKE_SHELL}
__
Bryan Drewery wrote:
> Yup, it's not really simple to fix. This problem defeats the goal of
> the feature too. I had not ran into this case in all of my testing since
> I wasn't installing to /.
I never do that either (except for bmake).
I'm guessing that installworld it is a rare event - compar
Mark Millard wrote:
> Building /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/make_keys
> sh: ./make_keys: Exec format error
This is an arm host or cross-building?
The error suggests HOST_CC got the wrong value.
You should be able to look at
/usr/obj/clang/arm.armv6/usr/src/li
BTW Mark, thanks very much for testing this.
> > # grep make_keys
> > ~/sys_typescripts/typescript_make_rpi2_nodebug_clang_bootstrap-amd64-host-2016-06-01:15:17:28
> > Building /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/make_keys
> > Building /usr/obj/clang/arm.armv6/usr/src/lib/ncurse
Mark Millard wrote:
> > # grep -i make /usr/sbin/mergemaster | more
> . . .
> > MM_MAKE="make ${ARCHSTRING} -m ${SOURCEDIR}/share/mk"
> > ${MM_MAKE} DESTDIR=${DESTDIR} distrib-dirs >/dev/null
> > ${MM_MAKE} DESTDIR=${TEMPROOT} distrib-dirs >/dev/null &&
> > ${MM_MAKE} _obj SUBD
Mark Millard wrote:
> > --- build-tools_lib/ncurses/ncursesw ---
> > Building /usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/make_keys
I must have been looking at on of our internal FreeBSD trees last
time...
In FreeBSD lib/ncurses/ncursesw/Makefile and other places I checked
just uses ${
Simon J. Gerraty wrote:
> If you want cross-building to work, the simple solution is to ensure
> that you use HOST_CC rather than CC when building things that need to
> run on the build host.
FWIW there are not many makefiles to fix:
bin/csh/Makefile
gnu/usr.bin/cc/cc_tools/Mak
Mark Millard wrote:
> Cross builds work just fine based on the FreeBSD tree when omitting
> WITH_META_MODE=.
>
Hmm must do something odd then.
> As of -r301825 there is almost no use of HOST_CC at the upper levels or in
> share/mk/*:
Yes, which means if cross-building works it must be requri
Bryan Drewery wrote:
> > eg. in our internal tree - which cross builds fine:
> >
> > make_keys: make_keys.c names.c ncurses_def.h ${HEADERS}
> > ${HOST_CC} -o $@ ${HOST_CFLAGS}
> > ${NCURSES_DIR}/ncurses/tinfo/make_keys.c
>
> I like this method but am going to put it off for a while. T
Bryan Drewery wrote:
> >> ${_FIRM}: ${.CURDIR}/../../../../contrib/dev/drm2/radeonkmsfw/${_FIRM}.uu
> >> uudecode -p $? > ${.TARGET}
Targets like this that use $? or ${.OODATE} are a bad fit with META mode.
If the normal make rules think the target is up to date, .OODATE will be
empty, t
Bryan Drewery wrote:
> The problem is missing-meta requiring a .meta file here. The $?/.OODATE
> comparison exception is only used meta_oodate() if there is already a
> .meta file, not for the new missing .meta logic.
Even if there is already a .meta file, if meta_oodate ever returns TRUE
the ta
Bryan Drewery wrote:
> Actually it does seem to be meta-missing bug since $? (.OODATE) is empty
> and yet it is requiring a .meta file.
As I said; .meta files and targets that use $? (.OODATE)
are fundamentally incompatible.
Such a target will not work correctly, if meta_oodate returns TRUE
so a
Bryan Drewery wrote:
> I think my point is getting lost. With the new missing-meta feature, if
> Yet, via meta_oodate, if there is already a .meta file and .OODATE is
> used and has an empty source list then $.OODATE is forced to be .ALLSRC:
Ah yes forgot about that.
___
David Wolfskill wrote:
> The build failed (initially -- a restart worked):
That's usually a good indicator of a race.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail t
Renato Botelho wrote:
> I decided to give a try to WITH_AUTO_OBJ and noted the first time I ran
> buildworld it failed with following message:
>
> /u/src # ❯❯❯ make WITH_AUTO_OBJ=yes buildworld
> [Creating objdir obj...]
> make: "/usr/src/share/mk/auto.obj.mk" line 61: could not use obj:
> .OB
Renato Botelho wrote:
> > Interesting; what .OBJDIR do you end up with for say bin/cat ?
>
>
> In this case it fails the first time pointing to expected .OBJDIR, then
> second time I run it builds
>
> /u/s/b/cat # ❯❯❯ make -DWITH_AUTO_OBJ
> [Creating objdir obj...]
> make: "/usr/src/share/mk/a
Steve Kargl wrote:
> MANPATH is not handled correctly. According to the documentation
> in apropos(1) and whatis(1):
Can you clarify where you are seeing this documentation?
I don't see it in 7.x 10.x or current.
Eg, in 10.2 apropos(1) says only:
ENVIRONMENT
The following environment var
Steve Kargl wrote:
> On Mon, Jan 09, 2017 at 05:19:01PM -0800, Simon J. Gerraty wrote:
> > Steve Kargl wrote:
> >
> > > MANPATH is not handled correctly. According to the documentation
> > > in apropos(1) and whatis(1):
> >
> > Can you clarify w
Steve Kargl wrote:
> Well, yes, it is the manpage that gets installed.
>
> > usr.bin/man/apropos.1
> >
> > is the one that matches apropos(1)
I should have said "in 10.x" ;-)
In current, MK_MANDOCDB defaults yes, so you are right.
So the script needs an update.
Is there a PR filed?
___
Johannes Lundberg wrote:
> https://wiki.freebsd.org/SecureBoot
>
Interested in this too - though for proprietary systems where we have
control over BIOS. The design should hopefully accommodate both.
In particular any plan for how the loader would verify kernel and any
pre-loaded modules, and
Jilles Tjoelker wrote:
> Index: etc/rc.d/random
> ===
> --- etc/rc.d/random (revision 311446)
> +++ etc/rc.d/random (working copy)
> @@ -20,12 +20,14 @@
>
> save_dev_random()
> {
> + oumask=`umask`
why not simply use a su
Hi Iblis
> I encounted core dump with `make -f - ...`
can you share the content of stdin? or a relevant snippet?
Also what version of bmake? (make -r -f /dev/null -V MAKE_VERSION)
Your patch risks overflow, so would like to reproduce first...
___
fre
Iblis Lin wrote:
> Accutally, I made it core dump via a julia script.
> Please checkout this code
I'm not familiar with juila, in most scripting languages
cmd = `/usr/bin/make -f - -V MAKE_ENV`
would run that command and assign the output to cmd.
The make instance would be reading from stdin whic
Iblis Lin wrote:
> > Could you perhaps run that with ktrace?
> >
> > Eg.
> >
> > ktrace -i -t cnis -f /var/tmp/make.kt whatever command you ran
> > kdump -m 128 -f /var/tmp/make.kt > /var/tmp/make.kd
> >
> > that would show what make is actually reading
> >
>
> I uploaded the ktrace to the gi
Ngie Cooper (yaneurabeya) wrote:
> Alternatively, could you please revert just r313650 in another
> branch/workspace (I wonder if changing from .OBJDIR to OBJTOP had some
> unintended consequences that unrooted issues with how bmake evaluates paths)?
The only change to dir handling in recent bm
Bryan Drewery wrote:
> Aha /usr/obj/usr/obj.
>
> That was in Renato's report as well.
>
> The bug is WITH_AUTO_OBJ. I just confirmed that. A bunch of errors occur
> when doing the first build and the opt_*.h files are not generated in
> the "proper" place by config(8).
>
> WITH_AUTO_OBJ is not
Bryan Drewery wrote:
> > What is the issue above? diff?
>
> I don't know what the issue is with buildkernel specifically, I never
> looked into it. Buildworld had other issues like rescue/rescue not being
> AUTO_OBJ safe. That's fixed. I forget the details of buildworld as well.
> One of the simp
> > [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
===
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
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
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:
> > .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
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
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
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
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
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.
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
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:
> 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
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
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
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
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:
> 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
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
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.
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
1 - 100 of 178 matches
Mail list logo
