Re: Is cross-world building broken?

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,

Re: Undesirable bmake behavior

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 removed

Re: Problems building FreeBSD 9.2 on FreeBSD 10

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

Re: Problems building FreeBSD 9.2 on FreeBSD 10

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 buildworld I get

Re: Problems building FreeBSD 9.2 on FreeBSD 10

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 invoked,

Re: Problems building FreeBSD 9.2 on FreeBSD 10

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 ensure

Re: Problems building FreeBSD 9.2 on FreeBSD 10

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).

Re: [RFC] Removin the old make

Ian Lepore i...@freebsd.org 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} ==

Re: bmake and .USEBEFORE

Julian Elischer jul...@freebsd.org 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

Re: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?

Garrett Cooper yaneurab...@gmail.com 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

Re: toolchain target

Andriy Gapon a...@freebsd.org 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

Re: toolchain target

Dimitry Andric d...@freebsd.org 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

Re: FreeBSD_HEAD_amd64_gcc4.9 - Build #85 - Failure

Konstantin Belousov kostik...@gmail.com 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

Re: FreeBSD_HEAD_amd64_gcc4.9 - Build #85 - Failure

Garrett Cooper yaneurab...@gmail.com wrote: On Jun 14, 2015, at 14:18, Simon J. Gerraty s...@juniper.net wrote: Craig Rodrigues rodr...@crodrigues.org wrote: On Sun, Jun 14, 2015 at 8:09 AM, Adrian Chadd adr...@freebsd.org wrote: + make -j 4 CROSS_TOOLCHAIN=amd64-gcc buildworld

Re: FreeBSD_HEAD_amd64_gcc4.9 - Build #85 - Failure

Craig Rodrigues rodr...@crodrigues.org wrote: On Sun, Jun 14, 2015 at 8:09 AM, Adrian Chadd adr...@freebsd.org 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

Re: toolchain target

Andriy Gapon a...@freebsd.org 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

Re: Error building x11/nvidia-driver kernel module @r284408

Garrett Cooper yaneurab...@gmail.com 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

Re: geom classe's geom_*.so installed /usr/lib/ instead of /lib/geom (crochet build)

Garrett Cooper yaneurab...@gmail.com 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.

Re: Error building x11/nvidia-driver kernel module @r284408

Thanks very much for the test David David Wolfskill da...@catwhisker.org 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

Re: Error building x11/nvidia-driver kernel module @r284408

Rainer Hurling rhur...@gwdg.de 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

Re: FreeBSD_HEAD_amd64_gcc4.9 - Build #85 - Failure

Garrett Cooper yaneurab...@gmail.com 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

Re: Parallel release failed on pwd_mkdb

Oliver Pinter oliver.pin...@hardenedbsd.org 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?

Re: proper way or unworkable idea ?

Jeffrey Bouquet jbt...@iherebuywisely.com 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

Re: powerpc and powerpc64 builds broken

Justin Hibbits jhibb...@freebsd.org 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

Re: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?

Bryan Drewery bdrew...@freebsd.org 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

Re: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?

Bryan Drewery bdrew...@freebsd.org 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

Re: -current broken when src is on NFS

O'Connor, Daniel dar...@dons.net.au 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

Re: -current broken when MAKEOBJDIRPREFIX is set (was: src is on NFS)

O'Connor, Daniel dar...@dons.net.au 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

Re: -current broken when MAKEOBJDIRPREFIX is set (was: src is on NFS)

O'Connor, Daniel dar...@dons.net.au 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

Re: -current broken when src is on NFS

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

Re: [CFT] Buildworld ccache support

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

Re: Failing buildword due to execution permission (with fix)

> >> 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

Re: libXO-ification - Why - and is it a symptom of deeper issues?

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

Re: Need help fixing failing locale tests

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

Re: libXO-ification - Why - and is it a symptom of deeper issues?

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

Re: libXO-ification - Why - and is it a symptom of deeper issues?

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

Re: libXO-ification - Why - and is it a symptom of deeper issues?

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

Re: libXO-ification - Why - and is it a symptom of deeper issues?

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

Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect

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

Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect

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

Re: [PATCH] uart_core: start countdown for non-interrupt mode

Aleksey Kuleshov rnd...@yandex.ru 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

Re: sys/modules "make clean" seems broken again

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

Re: 11.0-CURRENT SRC_ENV_CONF file vs. MAKEOBJDIRPREFIX in the file: they do not mix

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

Re: 11.0-CURRENT SRC_ENV_CONF file vs. MAKEOBJDIRPREFIX in the file: they do not mix

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. >

Re: My build work and goals

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

Re: My build work and goals

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

Re: make .SUFFIXES bug?

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

Re: make .SUFFIXES bug?

Simon J. Gerraty <s...@juniper.net> wrote: > Carsten Kunze <carsten.ku...@arcor.de> 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

Re: Aw: Re: make .SUFFIXES bug?

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

Re: 11.0 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"? [still true of -r301815]

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

Re: 11.0 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"? [still true of -r301815]

Simon J. Gerraty <s...@juniper.net> 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.

Re: 11.0 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"? [still true of -r301815]

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

Re: mergemaster internally using make [for example] vs. WITH_META_MODE?

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 && > >

Re: 11.0 -r301815 to -r310873 using WITH_META_MODE=yes : an empty filename failure

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

Re: 11.0 -r301815 to -r310873 using WITH_META_MODE=yes : an empty filename failure

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

Re: 11.0 -r301815 to -r310873 using WITH_META_MODE=yes : an empty filename failure

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.

Re: 11.0 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"? [still true of -r301815]

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

Re: 11.0 -r301815 to -r310873 using WITH_META_MODE=yes : an empty filename failure

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,

Re: [CFT] WITH_META_MODE: Working incremental build

> 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}

Re: [CFT] WITH_META_MODE: Working incremental build

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

Re: 11.0 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"?

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

Re: 11.0 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"?

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

Re: [CFT] WITH_META_MODE: Working incremental build [only on i386 and amd64]

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

Re: xo_config.h missing?

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 ___

Re: /usr/bin/make segmentation fault

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

Re: Possible race condition building libraries: head/amd64 r303329 -> r303379

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

Re: Fix /etc/rc.d/random umask handling (/entropy permissions)

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

Re: bmake core dump

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

Re: bmake core dump

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

Re: bmake core dump

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... ___

Re: 1st build stops when WITH_AUTO_OBJ=yes

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

Re: 1st build stops when WITH_AUTO_OBJ=yes

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:

Re: MANPATH not handled correctly

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

Re: MANPATH not handled correctly

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:

Re: MANPATH not handled correctly

Steve Kargl <s...@troutmask.apl.washington.edu> wrote: > On Mon, Jan 09, 2017 at 05:19:01PM -0800, Simon J. Gerraty wrote: > > Steve Kargl <s...@troutmask.apl.washington.edu> wrote: > > > > > MANPATH is not handled correctly. According to the documentat

Re: Secure Boot

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

Re: Apparent build race(s), r315238 -> r315298

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

Re: buildkernel broken for META_MODE

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). >

Re: buildkernel broken for META_MODE

> > [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

Re: buildkernel broken for META_MODE

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

Re: [bmake] bmake sigint handling causing tty corruption

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

Re: [bmake] bmake sigint handling causing tty corruption

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

Re: .configure && make fails to find ld [dlopen]

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

Re: .configure && make fails to find ld [dlopen]

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

Re: make warning: ?: No such file or directory.

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. >

Re: filemon: weird full-time build although filemon enabled

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 >

Re: buildworld not working with MAKEOBJDIRPREFIX

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

Re: make warning: ?: No such file or directory.

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. >

Re: Bug in make setting wrong MAKESYSPATH

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

Re: Bug in make setting wrong MAKESYSPATH

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 .../

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

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

Re: Bug in make setting wrong MAKESYSPATH

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 >

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

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

Re: Build failure in sys/modules/drm2/radeonkmsfw/ARUBA_pfp

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 > >

Re: Bug in make setting wrong MAKESYSPATH

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

Re: build src with colored output?

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

Re: Bug in make setting wrong MAKESYSPATH

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

Re: filemon: weird full-time build although filemon enabled

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

Re: filemon: weird full-time build although filemon enabled

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: > > [...] >

Re: filemon: weird full-time build although filemon enabled

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

  1   2   >