installkernel with PORTS_MODULES+=graphics/drm-515-kmod stopped working

[Bakul Shah]

I build{world,kernel} on one machine but install
everything from the target machine, with /usr/obj
and /usr/src from the build machine nfs mounted.
/etc/src.conf (on target and build machines) has
PORTS_MODULES+=graphics/drm-515-kmod to build
this port at the same time. This used to work at
least until Nov 1, 2023 but now stopped working.

What I don't understand is why is install trying
to install to /usr/obj/..., which is really on
the build tree.

It this known? Is this style of building .ko ports
still supported?

The make infrastructure has gotten far too complicated
and baroque over the years so before diving into it
I am looking any shortcuts! Thanks!

[note: /usr/ports is mounted from the build machine
/usr/src is symlinked to /home/FreeBSD/stable-14
/etc/src.conf is the same on both machines.
From target (as root) I can create root owned files
under /usr/obj on the target]

===>   drm-515-kmod not installed, skipping
===>  Staging for drm-515-kmod-5.15.118_2
No name and/or group mapping for uid,gid:(0,0)
No name and/or group mapping for uid,gid:(0,0)
...
No name and/or group mapping for uid,gid:(0,0)
===>   Generating temporary packing list
===> dmabuf (install)
install -T release -o root -g wheel -m 555   dmabuf.ko 
/usr/obj/home/FreeBSD/stable-14/amd64.amd64/sys/GENERIC/usr/ports/graphics/drm-515-kmod/work/stage/boot/modules/
===> ttm (install)
install -T release -o root -g wheel -m 555   ttm.ko 
/usr/obj/home/FreeBSD/stable-14/amd64.amd64/sys/GENERIC/usr/ports/graphics/drm-515-kmod/work/stage/boot/modules/
===> drm (install)
install -T release -o root -g wheel -m 555   drm.ko 
/usr/obj/home/FreeBSD/stable-14/amd64.amd64/sys/GENERIC/usr/ports/graphics/drm-515-kmod/work/stage/boot/modules/
No name and/or group mapping for uid,gid:(0,0)
install: 
/usr/obj/home/FreeBSD/stable-14/amd64.amd64/sys/GENERIC/usr/ports/graphics/drm-515-kmod/work/stage/boot/modules/drm.ko:
 chown/chgrp: Operation not permitted
*** Error code 71

Stop.
make[6]: stopped in 
/usr/obj/home/FreeBSD/stable-14/amd64.amd64/sys/GENERIC/usr/ports/graphics/drm-515-kmod/work/drm-kmod-drm_v5.15.118_3/drm
*** Error code 1

Stop.
make[5]: stopped in 
/usr/obj/home/FreeBSD/stable-14/amd64.amd64/sys/GENERIC/usr/ports/graphics/drm-515-kmod/work/drm-kmod-drm_v5.15.118_3
*** Error code 1

Re: PORTS_MODULES fails with beinstall.sh

[Nuno Teixeira]

Hello Gary,

Thanks for the hint, I will try it.
I've forgot to mention a PR about it:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263620

Thanks,

Gary Jennejohn  escreveu no dia terça, 7/03/2023 à(s) 15:11:

> On Tue, 7 Mar 2023 13:47:53 +
> Nuno Teixeira  wrote:
>
> > Hello all,
> >
> > I'm trying make.conf PORTS_MODULES=x11/nvidia-driver and it fails with
> > beinstall.sh:
> > ---
> >  [...]
> > cd ${PORTSDIR:-/usr/ports}/x11/nvidia-driver; env  -u CC  -u CXX  -u CPP
> >  -u MAKESYSPATH  -u MK_AUTO_OBJ  -u MAKEOBJDIR
> >  MAKEFLAGS="DESTDIR=/tmp/beinstall.6sMgsC/mnt KERNEL=kernel TARGET=amd64
> > TARGET_ARCH=amd64"  SYSDIR=/usr/src/sys
> >
> PATH=/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
> >  SRC_BASE=/usr/src  OSVERSION=1400081
> >  WRKDIRPREFIX=/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG make -B
> > deinstall reinstall
> >  [...]
> > cd: /tmp/mountpoint.CagxU8/usr/ports/x11/nvidia-driver: No such file or
> > directory
> > make: don't know how to make deinstall. Stop
> > ---
> >
> > Any hints?
> >
>
> Read the shell script.
>
> It only mounts srcdir, objdir and devfs under BE_MNTPT.  The shell script
> has absolutely no knowledge of other directories.
>
> You could hack the script by adding e.g. portsdir=/usr/ports and then mount
> it with
> mount -t nullfs "${portsdir}" "${BE_MNTPT}${portsdir}" || errx "Unable to
> mount ports"
>
> Probably best to create a private copy named e.g. beinstall+ports.sh and
> put it in your home directory.
>
> --
> Gary Jennejohn
>


-- 
Nuno Teixeira
FreeBSD Committer (ports)

Re: PORTS_MODULES fails with beinstall.sh

[Gary Jennejohn]

On Tue, 7 Mar 2023 13:47:53 +
Nuno Teixeira  wrote:

> Hello all,
>
> I'm trying make.conf PORTS_MODULES=x11/nvidia-driver and it fails with
> beinstall.sh:
> ---
>  [...]
> cd ${PORTSDIR:-/usr/ports}/x11/nvidia-driver; env  -u CC  -u CXX  -u CPP
>  -u MAKESYSPATH  -u MK_AUTO_OBJ  -u MAKEOBJDIR
>  MAKEFLAGS="DESTDIR=/tmp/beinstall.6sMgsC/mnt KERNEL=kernel TARGET=amd64
> TARGET_ARCH=amd64"  SYSDIR=/usr/src/sys
>  
> PATH=/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
>  SRC_BASE=/usr/src  OSVERSION=1400081
>  WRKDIRPREFIX=/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG make -B
> deinstall reinstall
>  [...]
> cd: /tmp/mountpoint.CagxU8/usr/ports/x11/nvidia-driver: No such file or
> directory
> make: don't know how to make deinstall. Stop
> ---
>
> Any hints?
>

Read the shell script.

It only mounts srcdir, objdir and devfs under BE_MNTPT.  The shell script
has absolutely no knowledge of other directories.

You could hack the script by adding e.g. portsdir=/usr/ports and then mount
it with
mount -t nullfs "${portsdir}" "${BE_MNTPT}${portsdir}" || errx "Unable to
mount ports"

Probably best to create a private copy named e.g. beinstall+ports.sh and
put it in your home directory.

--
Gary Jennejohn

PORTS_MODULES fails with beinstall.sh

[Nuno Teixeira]

Hello all,

I'm trying make.conf PORTS_MODULES=x11/nvidia-driver and it fails with
beinstall.sh:
---
===> Ports module x11/nvidia-driver (install)
cd ${PORTSDIR:-/usr/ports}/x11/nvidia-driver; env  -u CC  -u CXX  -u CPP
 -u MAKESYSPATH  -u MK_AUTO_OBJ  -u MAKEOBJDIR
 MAKEFLAGS="DESTDIR=/tmp/beinstall.6sMgsC/mnt KERNEL=kernel TARGET=amd64
TARGET_ARCH=amd64"  SYSDIR=/usr/src/sys
 
PATH=/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
 SRC_BASE=/usr/src  OSVERSION=1400081
 WRKDIRPREFIX=/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG make -B
deinstall reinstall
===>  Creating some important subdirectories
===>  Starting chrooted make in /tmp/beinstall.6sMgsC/mnt...
cd: /tmp/mountpoint.CagxU8/usr/ports/x11/nvidia-driver: No such file or
directory
make: don't know how to make deinstall. Stop
---

Any hints?

Thanks,


-- 
Nuno Teixeira
FreeBSD Committer (ports)

Re: buildkernel doesn't respect PORTSDIR with PORTS_MODULES

[Yuri]

Juraj Lutter wrote:
> 
> 
>> On 24 Nov 2022, at 15:16, Juraj Lutter  wrote:
>>>
>>> bsd.port.mk and bsd.port.subdir.mk use _PORTSDIR.  You could try adding
>>> that to your list.
>>>
>>
>> PORTS_MODULES are being built from within kern.post.mk. I’d put PORTSDIR 
>> into src-env.conf instead of /etc/src.conf, for that purpose.
> 
> Fingers are quicker than the brain: I’d put PORTSDIR into /etc/src.conf 
> instead of /etc/make.conf for that purpose.

Does it work for you?  I have tried putting it in all of the
/etc/src.conf, /etc/src-env.conf, and /etc/make.conf; still /usr/ports
is being used.

Looks like the expansion does not happen properly (for me, at least) in
kern.post.mk and the following seems to help (with PORTSDIR specified in
one of those 3 conf files or in environment):

diff --git a/sys/conf/kern.post.mk b/sys/conf/kern.post.mk
index d08dfe30d7d..7b208510483 100644
--- a/sys/conf/kern.post.mk
+++ b/sys/conf/kern.post.mk
@@ -133,7 +133,7 @@ PORTSMODULESENV=\
 all:
 .for __i in ${PORTS_MODULES}
@${ECHO} "===> Ports module ${__i} (all)"
-   cd $${PORTSDIR:-/usr/ports}/${__i}; ${PORTSMODULESENV} ${MAKE}
-B clean build
+   cd ${PORTSDIR:U/usr/ports}/${__i}; ${PORTSMODULESENV} ${MAKE} -B
clean build
 .endfor

 .for __target in install reinstall clean
@@ -141,7 +141,7 @@ ${__target}: ports-${__target}
 ports-${__target}:
 .for __i in ${PORTS_MODULES}
@${ECHO} "===> Ports module ${__i} (${__target})"
-   cd $${PORTSDIR:-/usr/ports}/${__i}; ${PORTSMODULESENV} ${MAKE}
-B ${__target:C/(re)?install/deinstall reinstall/}
+   cd ${PORTSDIR:U/usr/ports}/${__i}; ${PORTSMODULESENV} ${MAKE} -B
${__target:C/(re)?install/deinstall reinstall/} .endfor
 .endfor
 .endif

Re: buildkernel doesn't respect PORTSDIR with PORTS_MODULES

[Juraj Lutter]

> On 24 Nov 2022, at 15:16, Juraj Lutter  wrote:
>> 
>> bsd.port.mk and bsd.port.subdir.mk use _PORTSDIR.  You could try adding
>> that to your list.
>> 
> 
> PORTS_MODULES are being built from within kern.post.mk. I’d put PORTSDIR into 
> src-env.conf instead of /etc/src.conf, for that purpose.

Fingers are quicker than the brain: I’d put PORTSDIR into /etc/src.conf instead 
of /etc/make.conf for that purpose.

otis

—
Juraj Lutter
o...@freebsd.org

Re: buildkernel doesn't respect PORTSDIR with PORTS_MODULES

[Juraj Lutter]

> On 24 Nov 2022, at 15:05, Gary Jennejohn  wrote:
> 
> On Thu, 24 Nov 2022 12:02:35 +
> Nuno Teixeira  wrote:
> 
>> Hello,
>> 
>> I'm trying PORT_MODULES with make.conf:
>> ---
>> PORTSDIR=/work/freebsd/ports
>> DISTDIR=/work/DISTFILES
>> PORTS_MODULES=graphics/drm-kmod x11/nvidia-driver
>> 
> 
> bsd.port.mk and bsd.port.subdir.mk use _PORTSDIR.  You could try adding
> that to your list.
> 

PORTS_MODULES are being built from within kern.post.mk. I’d put PORTSDIR into 
src-env.conf instead of /etc/src.conf, for that purpose.

—
Juraj Lutter
o...@freebsd.org

Re: buildkernel doesn't respect PORTSDIR with PORTS_MODULES

[Gary Jennejohn]

On Thu, 24 Nov 2022 12:02:35 +
Nuno Teixeira  wrote:

> Hello,
>
> I'm trying PORT_MODULES with make.conf:
> ---
> PORTSDIR=/work/freebsd/ports
> DISTDIR=/work/DISTFILES
> PORTS_MODULES=graphics/drm-kmod x11/nvidia-driver
> ---
> and `make buildkernel` fails:
> ---
> linking kernel.full
> ctfmerge -L VERSION -g -o kernel.full ...
>   text  data   bssdec hex   filename
>   22977071   1848409   4437760   29263240   0x1be8588   kernel.full
> cd: /usr/ports/graphics/drm-kmod: No such file or directory
> ---
>
> Any hint?
> Thanks,
>

bsd.port.mk and bsd.port.subdir.mk use _PORTSDIR.  You could try adding
that to your list.

--
Gary Jennejohn

buildkernel doesn't respect PORTSDIR with PORTS_MODULES

[Nuno Teixeira]

Hello,

I'm trying PORT_MODULES with make.conf:
---
PORTSDIR=/work/freebsd/ports
DISTDIR=/work/DISTFILES
PORTS_MODULES=graphics/drm-kmod x11/nvidia-driver
---
and `make buildkernel` fails:
---
linking kernel.full
ctfmerge -L VERSION -g -o kernel.full ...
  text  data   bssdec hex   filename
  22977071   1848409   4437760   29263240   0x1be8588   kernel.full
cd: /usr/ports/graphics/drm-kmod: No such file or directory
---

Any hint?
Thanks,

-- 
Nuno Teixeira
FreeBSD Committer (ports)

Re: (239489) buildkernel fails if PORTS_MODULES= includes openzfs-kmod

[Ryan Moeller]

On 12/13/20 12:25 PM, John Kennedy wrote:

On Sun, Dec 13, 2020 at 08:19:30AM +, Graham Perrin wrote:

Please: is there some way to include openzfs-kmod at buildkernel time?



Not that I'm aware of, but you can write a script to build your system 
the way you like it and then build the kmod, clone a BE, etc, so you 
don't forget anything.




To work around
 I habitually
remove openzfs-kmod from /etc/src.conf _and_ modify /boot/loader.conf
before performing the build:

zfs_load="YES"
openzfs_load="NO"

Isn't openzfs-kmod on 13-CURRENT more or less moot since r36474, the OpenZFS
merge, ~2020/8/25?  That ticket was opened on 2019/7/28, pre-merge.



The port tracks the openzfs/zfs master branch while the base system 
tracks the zfs-2.0-release branch. However, that is planned to switch to 
master once base makes the transition to git.




Now, I still see recent updates on openzfs-kmod port so the question might
still be relevant for non-13 or if you're just using the port for reasons or
anywhere older than 13 (12.2, etc).



If the newer features in master (eg draid) aren't needed, the base zfs 
is at least less likely to break from kernel changes that haven't been 
coordinated well with the openzfs upstream and the port, which does 
happen from time to time.



-Ryan

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: (239489) buildkernel fails if PORTS_MODULES= includes openzfs-kmod

[John Kennedy]

On Sun, Dec 13, 2020 at 06:49:07PM +, Graham Perrin wrote:
> Not entirely moot; for 
>  the description for 
> the most recent commit refers to building on 13-CURRENT

Well, it's a port, so they'll want it to compile if nothing else.  It just
necessarily needed on 13, since it should be nearly par (if slightly behind in
some MFC-ish interval) the kernel.  Of course, when we get into 14 and 13
becomes more stable, 13-releng might be where 12 is now.

This was just a comment on a old ticket (with "latest" OS) in the -current
mailing list which is the potential edge case (13) of an edge case (need
to match kmod with kernel) where you might not need it.  I'm not saying
that it couldn't use some fixing in the medium/long term.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: (239489) buildkernel fails if PORTS_MODULES= includes openzfs-kmod

[Graham Perrin]

On 13/12/2020 17:25, John Kennedy wrote:

On Sun, Dec 13, 2020 at 08:19:30AM +, Graham Perrin wrote:

Please: is there some way to include openzfs-kmod at buildkernel time?

To work around
 I habitually
remove openzfs-kmod from /etc/src.conf _and_ modify /boot/loader.conf
before performing the build:

zfs_load="YES"
openzfs_load="NO"

Isn't openzfs-kmod on 13-CURRENT more or less moot since r36474, the OpenZFS
merge, ~2020/8/25? …


Not entirely moot; for 
 the description for 
the most recent commit refers to building on 13-CURRENT


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: (239489) buildkernel fails if PORTS_MODULES= includes openzfs-kmod

[John Kennedy]

On Sun, Dec 13, 2020 at 08:19:30AM +, Graham Perrin wrote:
> Please: is there some way to include openzfs-kmod at buildkernel time?
> 
> To work around 
>  I habitually 
> remove openzfs-kmod from /etc/src.conf _and_ modify /boot/loader.conf 
> before performing the build:
> 
> zfs_load="YES"
> openzfs_load="NO"

Isn't openzfs-kmod on 13-CURRENT more or less moot since r36474, the OpenZFS
merge, ~2020/8/25?  That ticket was opened on 2019/7/28, pre-merge.

Now, I still see recent updates on openzfs-kmod port so the question might
still be relevant for non-13 or if you're just using the port for reasons or
anywhere older than 13 (12.2, etc).
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

(239489) buildkernel fails if PORTS_MODULES= includes openzfs-kmod

[Graham Perrin]

Please: is there some way to include openzfs-kmod at buildkernel time?

To work around 
 I habitually 
remove openzfs-kmod from /etc/src.conf _and_ modify /boot/loader.conf 
before performing the build:


zfs_load="YES"
openzfs_load="NO"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

PORTS_MODULES if you built head between r359681 - r359690

[David Wolfskill]

TL;DR: You may want to take evasive action, such as manually copying
the r359690 (or later) from src/share/mk/bsd.sys.mk to
/usr/share/mk/bsd.sys.mk before attempting to make use of the
PORTS_MODULES specificsation if the current version of
/usr/share/mk/bsd.sys.mk is from r359681.

Details & rationale:
I track head daily on my laptop, which uses x11/nvidia-driver, so I
have:

PORTS_MODULES=x11/nvidia-driver

in /etc/src.conf -- and that has served well for years.

Yesterday, I had updated head from r359656 to r359686 without incident
(as far as I could tell at the time).

Today, during the attempt to update from r359686 to r359724 -- which
had worked on my headless "build machine" -- failed during the attempt
to rebuild nividia.ko, whining:

make[6]: "/usr/share/mk/bsd.sys.mk" line 219: Malformed conditional 
(${MK_CLANG_BOOTSTRAP} == "no" && ${COMPILER_RESOURCE_DIR} != "unknown" &&  
!defined(BOOTSTRAPPING))
make[6]: Fatal errors encountered -- cannot continue
make[6]: stopped in 
/common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-440.64/doc
*** Error code 1


Once I finally(!) had a chance to look at the commits between r359686
and r359724, I found r359690 ... and looking at the whine, I note
that the path for share/mk/bsd.sys.mk starts with /usr -- which,
of course, had not yet been updated, since this was part of "make
buildkernel," and "make installworld" comes rather later in the sequence
(ref src/UPDATING).

Once I realized the above, I made the r359690 changes in
/usr/share/mk/bsd.sys.mk, then re-ran the build/install, which worked
without issue.

Peace and good health,
david
--
David H. Wolfskill  da...@catwhisker.org
"The most basic duty of government is to defend the lives of its own
citizens.  Any government that fails to do so is a government unworthy
to lead." -- Donald Trump, to the RNC, 2016

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

[Ian FREISLICH]

On 02/14/18 03:42, Vladimir Zakharov wrote:
> On Tue, Feb 13, 2018, Bryan Drewery wrote:
>> On 2/13/2018 1:48 AM, Vladimir Zakharov wrote:
>>> On Mon, Feb 12, 2018, Bryan Drewery wrote:
>>>> On 2/12/2018 6:54 AM, Vladimir Zakharov wrote:
>>>>> Hello, Bryan!
>>>>>
>>>>> On Fri, Feb 09, 2018, Bryan Drewery wrote:
>>>>>> On 2/1/2018 1:10 AM, Vladimir Zakharov wrote:
>>>>>>> Hello!
>>>>>>>
>>>>>>> For some time (about a week) building and installing kernel fails with
>>>>>>> the error "Variable OBJTOP is recursive." when going to build/install
>>>>>>> module from ports.
>>>>>>>
>>>>>>> Last successful build was at r328426. Next build at r328527 failed and
>>>>>>> still broken at r328649.
>>>>>>>
>>>>>>> Without PORTS_MODULES building and installing kernel succeeds. Another
>>>>>>> workaround: ignore error and build/install module directly from ports.
>>>>>>> ...
>>>>>> For some reason I cannot recreate this issue.
>>>>> It seems, setting WITH_AUTO_OBJ in /etc/src-env.conf causes an error.
>>>>> At least, removing it fixes build for me.
>>>>>
>>>>> Build successful with the following settings:
>>>>> # cat /etc/src-env.conf
>>>>> WITH_META_MODE=
>>>>> #WITH_AUTO_OBJ=
>>>>>
>>>> Please try this patch (requires a buildkernel).
>>>>
>>>> https://people.freebsd.org/~bdrewery/patches/kernel-portsmodules.diff
>>>>
>>> Fixed partly:
>>> | buildkernel  | installkernel |
>>> r329196 | OK   | FAIL(*)   |
>>> r329169 + patch | OK   | OK|
>>> r329196 + WITH_AUTO_OBJ | FAIL |   |
>>> r329169 + WITH_AUTO_OBJ + patch | FAIL |   |
>>>
>>> (*) - same error "Variable OBJTOP is recursive".
>>>
>> Thanks, r329232 should fix it.
> Not yet. 'installkernel' still fails (see below). Can be fixed either by
> explicit setting WITHOUT_AUTO_OBJ in /etc/src-env.conf or by applying
> previous patch (s/build/stage/ in kern.post.mk:89).
>
> # svn info
> Path: .
> Working Copy Root Path: /usr/src
> URL: https://svn.freebsd.org/base/head
> Relative URL: ^/head
> Repository Root: https://svn.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 329259
> Node Kind: directory
> Schedule: normal
> Last Changed Author: eadler
> Last Changed Rev: 329259
> Last Changed Date: 2018-02-14 10:59:30 +0300 (Wed, 14 Feb 2018)
>
> # cat /etc/src-env.conf
> WITH_META_MODE=
> #WITH_AUTO_OBJ=
>
> # env | grep MAKE
> MAKEOBJDIRPREFIX=/home/obj
>
> # make -j 4 buildkernel && make installkernel
> ...
> ===> Ports module graphics/drm-next-kmod (all)
> cd ${PORTSDIR:-/usr/ports}/graphics/drm-next-kmod; env  -u CC  -u CXX  -u CPP 
>  -u MAKESYSPATH  -u MAKEOBJDIR  MAKEFLAGS="-j 4 -J 15,16 -j 4 -J 15,16 -D 
> NO_MODULES_OBJ .MAKE.LEVEL.ENV=MAKELEVEL KERNEL=kernel TARGET=amd64 
> TARGET_ARCH=amd64"  SYSDIR=/usr/src/sys  
> PATH=/home/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/home/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/home/obj/usr/src/amd64.amd64/tmp/legacy/bin:/home/obj/usr/src/amd64.amd64/tmp/usr/sbin:/home/obj/usr/src/amd64.amd64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
>   SRC_BASE=/usr/src  OSVERSION=1200058  
> WRKDIRPREFIX=/home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG make -B clean 
> build
> ===>  Cleaning for drm-next-kmod-g20180117
> ===>  License BSD2CLAUSE MIT GPLv2 accepted by the user
> ===>   drm-next-kmod-g20180117 depends on file: /usr/local/sbin/pkg - found
> ===> Fetching all distfiles required by drm-next-kmod-g20180117 for building
> ===>  Extracting for drm-next-kmod-g20180117
> => SHA256 Checksum OK for FreeBSDDesktop-kms-drm-g20180117-622fdd1_GH0.tar.gz.
> ===>  Patching for drm-next-kmod-g20180117
> ===>   drm-next-kmod-g20180117 depends on file: /usr/local/bin/ccache - found
> ===>  Configuring for drm-next-kmod-g20180117
> ===>  Building for drm-next-kmod-g20180117
> [Creating objdir obj...]
> ...
> --
>>>> Kernel build for GENERIC-NODEBUG completed on Wed Feb 14 11:09:45 MSK 2018
> -

Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

[Vladimir Zakharov]

On Tue, Feb 13, 2018, Bryan Drewery wrote:
> On 2/13/2018 1:48 AM, Vladimir Zakharov wrote:
> > On Mon, Feb 12, 2018, Bryan Drewery wrote:
> >> On 2/12/2018 6:54 AM, Vladimir Zakharov wrote:
> >>> Hello, Bryan!
> >>>
> >>> On Fri, Feb 09, 2018, Bryan Drewery wrote:
> >>>> On 2/1/2018 1:10 AM, Vladimir Zakharov wrote:
> >>>>> Hello!
> >>>>>
> >>>>> For some time (about a week) building and installing kernel fails with
> >>>>> the error "Variable OBJTOP is recursive." when going to build/install
> >>>>> module from ports.
> >>>>>
> >>>>> Last successful build was at r328426. Next build at r328527 failed and
> >>>>> still broken at r328649.
> >>>>>
> >>>>> Without PORTS_MODULES building and installing kernel succeeds. Another
> >>>>> workaround: ignore error and build/install module directly from ports.
> >>>>> ...
> >>>>
> >>>> For some reason I cannot recreate this issue.
> >>>
> >>> It seems, setting WITH_AUTO_OBJ in /etc/src-env.conf causes an error.
> >>> At least, removing it fixes build for me.
> >>>
> >>> Build successful with the following settings:
> >>> # cat /etc/src-env.conf
> >>> WITH_META_MODE=
> >>> #WITH_AUTO_OBJ=
> >>>
> >>
> >> Please try this patch (requires a buildkernel).
> >>
> >> https://people.freebsd.org/~bdrewery/patches/kernel-portsmodules.diff
> >>
> > 
> > Fixed partly:
> > | buildkernel  | installkernel |
> > r329196 | OK   | FAIL(*)   |
> > r329169 + patch | OK   | OK|
> > r329196 + WITH_AUTO_OBJ | FAIL |   |
> > r329169 + WITH_AUTO_OBJ + patch | FAIL |   |
> > 
> > (*) - same error "Variable OBJTOP is recursive".
> > 
> 
> Thanks, r329232 should fix it.

Not yet. 'installkernel' still fails (see below). Can be fixed either by
explicit setting WITHOUT_AUTO_OBJ in /etc/src-env.conf or by applying
previous patch (s/build/stage/ in kern.post.mk:89).

# svn info
Path: .
Working Copy Root Path: /usr/src
URL: https://svn.freebsd.org/base/head
Relative URL: ^/head
Repository Root: https://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 329259
Node Kind: directory
Schedule: normal
Last Changed Author: eadler
Last Changed Rev: 329259
Last Changed Date: 2018-02-14 10:59:30 +0300 (Wed, 14 Feb 2018)

# cat /etc/src-env.conf
WITH_META_MODE=
#WITH_AUTO_OBJ=

# env | grep MAKE
MAKEOBJDIRPREFIX=/home/obj

# make -j 4 buildkernel && make installkernel
...
===> Ports module graphics/drm-next-kmod (all)
cd ${PORTSDIR:-/usr/ports}/graphics/drm-next-kmod; env  -u CC  -u CXX  -u CPP  
-u MAKESYSPATH  -u MAKEOBJDIR  MAKEFLAGS="-j 4 -J 15,16 -j 4 -J 15,16 -D 
NO_MODULES_OBJ .MAKE.LEVEL.ENV=MAKELEVEL KERNEL=kernel TARGET=amd64 
TARGET_ARCH=amd64"  SYSDIR=/usr/src/sys  
PATH=/home/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/home/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/home/obj/usr/src/amd64.amd64/tmp/legacy/bin:/home/obj/usr/src/amd64.amd64/tmp/usr/sbin:/home/obj/usr/src/amd64.amd64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
  SRC_BASE=/usr/src  OSVERSION=1200058  
WRKDIRPREFIX=/home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG make -B clean 
build
===>  Cleaning for drm-next-kmod-g20180117
===>  License BSD2CLAUSE MIT GPLv2 accepted by the user
===>   drm-next-kmod-g20180117 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by drm-next-kmod-g20180117 for building
===>  Extracting for drm-next-kmod-g20180117
=> SHA256 Checksum OK for FreeBSDDesktop-kms-drm-g20180117-622fdd1_GH0.tar.gz.
===>  Patching for drm-next-kmod-g20180117
===>   drm-next-kmod-g20180117 depends on file: /usr/local/bin/ccache - found
===>  Configuring for drm-next-kmod-g20180117
===>  Building for drm-next-kmod-g20180117
[Creating objdir obj...]
...
--
>>> Kernel build for GENERIC-NODEBUG completed on Wed Feb 14 11:09:45 MSK 2018
--
--
>>> Installing kernel GENERIC-NODEBUG on Wed Feb 14 11:09:45 MSK 2018
--
...
kldxref /boot/kernel
===> Ports module graphics/drm-next-kmod (install)
cd ${PORTSDIR:-/usr/ports}/graphics

Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

[Conrad Meyer]

On Tue, Feb 13, 2018 at 6:02 AM, David Wolfskill  wrote:
> On Tue, Feb 13, 2018 at 12:48:19PM +0300, Vladimir Zakharov wrote:
>> 
>> > > It seems, setting WITH_AUTO_OBJ in /etc/src-env.conf causes an error.
>> > > At least, removing it fixes build for me.
>
> FWIW, I have never specified WITH_AUTO_OBJ -- and I do encounter the
> "Variable OBJTOP is recursive" during the "make install kernel" phase
> unless I take evasive action (patches).

FYI, it is on by default since r325520.

Best,
Conrad
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

[Bryan Drewery]

On 2/13/2018 1:48 AM, Vladimir Zakharov wrote:
> On Mon, Feb 12, 2018, Bryan Drewery wrote:
>> On 2/12/2018 6:54 AM, Vladimir Zakharov wrote:
>>> Hello, Bryan!
>>>
>>> On Fri, Feb 09, 2018, Bryan Drewery wrote:
>>>> On 2/1/2018 1:10 AM, Vladimir Zakharov wrote:
>>>>> Hello!
>>>>>
>>>>> For some time (about a week) building and installing kernel fails with
>>>>> the error "Variable OBJTOP is recursive." when going to build/install
>>>>> module from ports.
>>>>>
>>>>> Last successful build was at r328426. Next build at r328527 failed and
>>>>> still broken at r328649.
>>>>>
>>>>> Without PORTS_MODULES building and installing kernel succeeds. Another
>>>>> workaround: ignore error and build/install module directly from ports.
>>>>> ...
>>>>
>>>> For some reason I cannot recreate this issue.
>>>
>>> It seems, setting WITH_AUTO_OBJ in /etc/src-env.conf causes an error.
>>> At least, removing it fixes build for me.
>>>
>>> Build successful with the following settings:
>>> # cat /etc/src-env.conf
>>> WITH_META_MODE=
>>> #WITH_AUTO_OBJ=
>>>
>>
>> Please try this patch (requires a buildkernel).
>>
>> https://people.freebsd.org/~bdrewery/patches/kernel-portsmodules.diff
>>
> 
> Fixed partly:
> | buildkernel  | installkernel |
> r329196 | OK   | FAIL(*)   |
> r329169 + patch | OK   | OK|
> r329196 + WITH_AUTO_OBJ | FAIL |   |
> r329169 + WITH_AUTO_OBJ + patch | FAIL |   |
> 
> (*) - same error "Variable OBJTOP is recursive".
> 

Thanks, r329232 should fix it.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

[David Wolfskill]

On Tue, Feb 13, 2018 at 12:48:19PM +0300, Vladimir Zakharov wrote:
> 
> > > It seems, setting WITH_AUTO_OBJ in /etc/src-env.conf causes an error.
> > > At least, removing it fixes build for me.

FWIW, I have never specified WITH_AUTO_OBJ -- and I do encounter the
"Variable OBJTOP is recursive" during the "make install kernel" phase
unless I take evasive action (patches).

> ...
> > Please try this patch (requires a buildkernel).
> > 
> > https://people.freebsd.org/~bdrewery/patches/kernel-portsmodules.diff
> > 
> 
> Fixed partly:
> | buildkernel  | installkernel |
> r329196 | OK   | FAIL(*)   |
> r329169 + patch | OK   | OK|
> r329196 + WITH_AUTO_OBJ | FAIL |   |
> r329169 + WITH_AUTO_OBJ + patch | FAIL |   |
> 
> (*) - same error "Variable OBJTOP is recursive".
> 

In my case, I started with r329155, updated sources to r329197,
reverted an earlier patch to src/sys/conf/kern.post.mk, applied the
above, and rebuilt with no issues -- both on my headless build machine
(which runs a GENERIC kernel, has no kernel modules from ports, did not
exhibit the problem, and verified that the patch doesn't break the
"vanilla" configuration.

My laptop, which runs a moderately-customized kernel ("CANARY") based on
GENERIC, uses the x11/nvidia-driver-340 kernel module, and has exhibited
the problem in the past, made it through the build/install/smoke test
without issue (with the above patch).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
The circus around that memo helps confirm that Mr. Trump is unfit for office.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

[Vladimir Zakharov]

On Mon, Feb 12, 2018, Bryan Drewery wrote:
> On 2/12/2018 6:54 AM, Vladimir Zakharov wrote:
> > Hello, Bryan!
> > 
> > On Fri, Feb 09, 2018, Bryan Drewery wrote:
> >> On 2/1/2018 1:10 AM, Vladimir Zakharov wrote:
> >>> Hello!
> >>>
> >>> For some time (about a week) building and installing kernel fails with
> >>> the error "Variable OBJTOP is recursive." when going to build/install
> >>> module from ports.
> >>>
> >>> Last successful build was at r328426. Next build at r328527 failed and
> >>> still broken at r328649.
> >>>
> >>> Without PORTS_MODULES building and installing kernel succeeds. Another
> >>> workaround: ignore error and build/install module directly from ports.
> >>> ...
> >>
> >> For some reason I cannot recreate this issue.
> > 
> > It seems, setting WITH_AUTO_OBJ in /etc/src-env.conf causes an error.
> > At least, removing it fixes build for me.
> > 
> > Build successful with the following settings:
> > # cat /etc/src-env.conf
> > WITH_META_MODE=
> > #WITH_AUTO_OBJ=
> > 
> 
> Please try this patch (requires a buildkernel).
> 
> https://people.freebsd.org/~bdrewery/patches/kernel-portsmodules.diff
> 

Fixed partly:
| buildkernel  | installkernel |
r329196 | OK   | FAIL(*)   |
r329169 + patch | OK   | OK|
r329196 + WITH_AUTO_OBJ | FAIL |   |
r329169 + WITH_AUTO_OBJ + patch | FAIL |   |

(*) - same error "Variable OBJTOP is recursive".

-- 
Regards, | "In theory there is no difference between theory
  Vladimir Zakharov  | and practice. In practice there is."- Yogi Berra
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

[Bryan Drewery]

On 2/12/2018 6:54 AM, Vladimir Zakharov wrote:
> Hello, Bryan!
> 
> On Fri, Feb 09, 2018, Bryan Drewery wrote:
>> On 2/1/2018 1:10 AM, Vladimir Zakharov wrote:
>>> Hello!
>>>
>>> For some time (about a week) building and installing kernel fails with
>>> the error "Variable OBJTOP is recursive." when going to build/install
>>> module from ports.
>>>
>>> Last successful build was at r328426. Next build at r328527 failed and
>>> still broken at r328649.
>>>
>>> Without PORTS_MODULES building and installing kernel succeeds. Another
>>> workaround: ignore error and build/install module directly from ports.
>>>
>>> # cat /etc/make.conf
>>> MALLOC_PRODUCTION=yes
>>> KERNCONF=GENERIC-NODEBUG GENERIC
>>> #KERNCONF= GENERIC-NODEBUG
>>> CPUTYPE?=native
>>> #PORTS_MODULES = graphics/drm-next-kmod emulators/virtualbox-ose-kmod
>>> PORTS_MODULES = graphics/drm-next-kmod 
>>>
>>> DOC_LANG = en_US.ISO8859-1 ru_RU.KOI8-R 
>>>
>>> WITH_DEBUG_PORTS = mail/neomutt
>>>
>>> WITH_CCACHE_BUILD=yes
>>> CCACHE_DIR=/home/ccache
>>>
>>> #DEVELOPER=yes
>>>
>>> ...
>>> Building /home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/kernel.full
>>> --- kernel.full ---
>>> linking kernel.full
>>> ctfmerge -L VERSION -g -o kernel.full ...
>>>   text  data   bssdec hex   filename
>>>   22584632   1376209   474   28709729   0x1b61361   kernel.full
>>> Building /home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/kernel.debug
>>> Building /home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/kernel
>>> --- all ---
>>> ===> Ports module graphics/drm-next-kmod (all)
>>> cd ${PORTSDIR:-/usr/ports}/graphics/drm-next-kmod; env  -u CC  -u CXX
>>> -u CPP  -u MAKESYSPATH  MAKEFLAGS="-j 4 -J 15,16 -j 4 -J 15,16 -D
>>> NO_MODULES_OBJ .MAKE.LEVEL.ENV=MAKELEVEL KERNEL=kernel TARGET=amd64
>>> TARGET_ARCH=amd64"  SYSDIR=/usr/src/sys
>>> PATH=
>>> SRC_BASE=/usr/src  OSVERSION=1200056
>>> WRKDIRPREFIX=/home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG make -B
>>> clean build
>>> ===>  Cleaning for drm-next-kmod-g20180117
>>> ===>  License BSD2CLAUSE MIT GPLv2 accepted by the user
>>> ===>   drm-next-kmod-g20180117 depends on file: /usr/local/sbin/pkg - found
>>> ===> Fetching all distfiles required by drm-next-kmod-g20180117 for building
>>> ===>  Extracting for drm-next-kmod-g20180117
>>> => SHA256 Checksum OK for 
>>> FreeBSDDesktop-kms-drm-g20180117-622fdd1_GH0.tar.gz.
>>> ===>  Patching for drm-next-kmod-g20180117
>>> ===>   drm-next-kmod-g20180117 depends on file: /usr/local/bin/ccache - 
>>> found
>>> ===>  Configuring for drm-next-kmod-g20180117
>>> ===>  Building for drm-next-kmod-g20180117
>>> ===> drm (all)
>>> Variable OBJTOP is recursive.
>>
>> For some reason I cannot recreate this issue.
> 
> It seems, setting WITH_AUTO_OBJ in /etc/src-env.conf causes an error.
> At least, removing it fixes build for me.
> 
> Build successful with the following settings:
> # cat /etc/src-env.conf
> WITH_META_MODE=
> #WITH_AUTO_OBJ=
> 
> # env | grep MAKE
> MAKEOBJDIRPREFIX=/home/obj
> 
> # cat /etc/make.conf
> MALLOC_PRODUCTION=yes
> KERNCONF= GENERIC-NODEBUG
> CPUTYPE?=native
> PORTS_MODULES= graphics/drm-next-kmod 
> DOC_LANG = en_US.ISO8859-1 ru_RU.KOI8-R 
> WITH_DEBUG_PORTS = mail/neomutt
> WITH_CCACHE_BUILD=yes
> CCACHE_DIR=/home/ccache
> DEVELOPER=yes
> 

Please try this patch (requires a buildkernel).

https://people.freebsd.org/~bdrewery/patches/kernel-portsmodules.diff

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

[Vladimir Zakharov]

Hello, Bryan!

On Fri, Feb 09, 2018, Bryan Drewery wrote:
> On 2/1/2018 1:10 AM, Vladimir Zakharov wrote:
> > Hello!
> > 
> > For some time (about a week) building and installing kernel fails with
> > the error "Variable OBJTOP is recursive." when going to build/install
> > module from ports.
> > 
> > Last successful build was at r328426. Next build at r328527 failed and
> > still broken at r328649.
> > 
> > Without PORTS_MODULES building and installing kernel succeeds. Another
> > workaround: ignore error and build/install module directly from ports.
> > 
> > # cat /etc/make.conf
> > MALLOC_PRODUCTION=yes
> > KERNCONF=GENERIC-NODEBUG GENERIC
> > #KERNCONF= GENERIC-NODEBUG
> > CPUTYPE?=native
> > #PORTS_MODULES = graphics/drm-next-kmod emulators/virtualbox-ose-kmod
> > PORTS_MODULES = graphics/drm-next-kmod 
> > 
> > DOC_LANG = en_US.ISO8859-1 ru_RU.KOI8-R 
> > 
> > WITH_DEBUG_PORTS = mail/neomutt
> > 
> > WITH_CCACHE_BUILD=yes
> > CCACHE_DIR=/home/ccache
> > 
> > #DEVELOPER=yes
> > 
> > ...
> > Building /home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/kernel.full
> > --- kernel.full ---
> > linking kernel.full
> > ctfmerge -L VERSION -g -o kernel.full ...
> >   text  data   bssdec hex   filename
> >   22584632   1376209   474   28709729   0x1b61361   kernel.full
> > Building /home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/kernel.debug
> > Building /home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/kernel
> > --- all ---
> > ===> Ports module graphics/drm-next-kmod (all)
> > cd ${PORTSDIR:-/usr/ports}/graphics/drm-next-kmod; env  -u CC  -u CXX
> > -u CPP  -u MAKESYSPATH  MAKEFLAGS="-j 4 -J 15,16 -j 4 -J 15,16 -D
> > NO_MODULES_OBJ .MAKE.LEVEL.ENV=MAKELEVEL KERNEL=kernel TARGET=amd64
> > TARGET_ARCH=amd64"  SYSDIR=/usr/src/sys
> > PATH=
> > SRC_BASE=/usr/src  OSVERSION=1200056
> > WRKDIRPREFIX=/home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG make -B
> > clean build
> > ===>  Cleaning for drm-next-kmod-g20180117
> > ===>  License BSD2CLAUSE MIT GPLv2 accepted by the user
> > ===>   drm-next-kmod-g20180117 depends on file: /usr/local/sbin/pkg - found
> > ===> Fetching all distfiles required by drm-next-kmod-g20180117 for building
> > ===>  Extracting for drm-next-kmod-g20180117
> > => SHA256 Checksum OK for 
> > FreeBSDDesktop-kms-drm-g20180117-622fdd1_GH0.tar.gz.
> > ===>  Patching for drm-next-kmod-g20180117
> > ===>   drm-next-kmod-g20180117 depends on file: /usr/local/bin/ccache - 
> > found
> > ===>  Configuring for drm-next-kmod-g20180117
> > ===>  Building for drm-next-kmod-g20180117
> > ===> drm (all)
> > Variable OBJTOP is recursive.
> 
> For some reason I cannot recreate this issue.

It seems, setting WITH_AUTO_OBJ in /etc/src-env.conf causes an error.
At least, removing it fixes build for me.

Build successful with the following settings:
# cat /etc/src-env.conf
WITH_META_MODE=
#WITH_AUTO_OBJ=

# env | grep MAKE
MAKEOBJDIRPREFIX=/home/obj

# cat /etc/make.conf
MALLOC_PRODUCTION=yes
KERNCONF= GENERIC-NODEBUG
CPUTYPE?=native
PORTS_MODULES= graphics/drm-next-kmod 
DOC_LANG = en_US.ISO8859-1 ru_RU.KOI8-R 
WITH_DEBUG_PORTS = mail/neomutt
WITH_CCACHE_BUILD=yes
CCACHE_DIR=/home/ccache
DEVELOPER=yes

-- 
Regards, | "In theory there is no difference between theory
  Vladimir Zakharov  | and practice. In practice there is."- Yogi Berra
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

[Bryan Drewery]

On 2/1/2018 1:10 AM, Vladimir Zakharov wrote:
> Hello!
> 
> For some time (about a week) building and installing kernel fails with
> the error "Variable OBJTOP is recursive." when going to build/install
> module from ports.
> 
> Last successful build was at r328426. Next build at r328527 failed and
> still broken at r328649.
> 
> Without PORTS_MODULES building and installing kernel succeeds. Another
> workaround: ignore error and build/install module directly from ports.
> 
> # cat /etc/make.conf
> MALLOC_PRODUCTION=yes
> KERNCONF=GENERIC-NODEBUG GENERIC
> #KERNCONF= GENERIC-NODEBUG
> CPUTYPE?=native
> #PORTS_MODULES = graphics/drm-next-kmod emulators/virtualbox-ose-kmod
> PORTS_MODULES = graphics/drm-next-kmod 
> 
> DOC_LANG = en_US.ISO8859-1 ru_RU.KOI8-R 
> 
> WITH_DEBUG_PORTS = mail/neomutt
> 
> WITH_CCACHE_BUILD=yes
> CCACHE_DIR=/home/ccache
> 
> #DEVELOPER=yes
> 
> ...
> Building /home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/kernel.full
> --- kernel.full ---
> linking kernel.full
> ctfmerge -L VERSION -g -o kernel.full ...
>   text  data   bssdec hex   filename
>   22584632   1376209   474   28709729   0x1b61361   kernel.full
> Building /home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/kernel.debug
> Building /home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/kernel
> --- all ---
> ===> Ports module graphics/drm-next-kmod (all)
> cd ${PORTSDIR:-/usr/ports}/graphics/drm-next-kmod; env  -u CC  -u CXX
> -u CPP  -u MAKESYSPATH  MAKEFLAGS="-j 4 -J 15,16 -j 4 -J 15,16 -D
> NO_MODULES_OBJ .MAKE.LEVEL.ENV=MAKELEVEL KERNEL=kernel TARGET=amd64
> TARGET_ARCH=amd64"  SYSDIR=/usr/src/sys
> PATH=
> SRC_BASE=/usr/src  OSVERSION=1200056
> WRKDIRPREFIX=/home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG make -B
> clean build
> ===>  Cleaning for drm-next-kmod-g20180117
> ===>  License BSD2CLAUSE MIT GPLv2 accepted by the user
> ===>   drm-next-kmod-g20180117 depends on file: /usr/local/sbin/pkg - found
> ===> Fetching all distfiles required by drm-next-kmod-g20180117 for building
> ===>  Extracting for drm-next-kmod-g20180117
> => SHA256 Checksum OK for FreeBSDDesktop-kms-drm-g20180117-622fdd1_GH0.tar.gz.
> ===>  Patching for drm-next-kmod-g20180117
> ===>   drm-next-kmod-g20180117 depends on file: /usr/local/bin/ccache - found
> ===>  Configuring for drm-next-kmod-g20180117
> ===>  Building for drm-next-kmod-g20180117
> ===> drm (all)
> Variable OBJTOP is recursive.

For some reason I cannot recreate this issue.

-- 
Regards,
Bryan Drewery
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

[Vladimir Zakharov]

On Sun, Feb 04, 2018, O. Hartmann wrote:
> Am Sat, 3 Feb 2018 11:17:06 +0100
> "O. Hartmann" <o.hartm...@walstatt.org> schrieb:
> 
> > Am Sat, 3 Feb 2018 11:10:53 +0300
> > Vladimir Zakharov <zakharov...@gmail.com> schrieb:
> > 
> > > Hello, Oliver!
> > > 
> > > On Fri, Feb 02, 2018, O. Hartmann wrote:  
> > > > On Thu, 1 Feb 2018 12:10:30 +0300
> > > > Vladimir Zakharov <zakharov...@gmail.com> wrote:
> > > > 
> > > > > Hello!
> > > > > 
> > > > > For some time (about a week) building and installing kernel fails with
> > > > > the error "Variable OBJTOP is recursive." when going to build/install
> > > > > module from ports.
> > > > > 
> > > > > Last successful build was at r328426. Next build at r328527 failed and
> > > > > still broken at r328649.
> > > > > 
> > > > > Without PORTS_MODULES building and installing kernel succeeds. Another
> > > > > workaround: ignore error and build/install module directly from ports.
> > > > > 
> > > > 
> > > > I have had the very same issue!
> > > > 
> > > > You need to perform a "installworld" first (just comment out the 
> > > > PORTS_MODULES=
> > > > parts of /etc/src.conf or /etc/make.conf, buildworld and buildkernel 
> > > > (maybe not
> > > > a full buildworld, but I do not know the state of your source tree) and 
> > > > perform
> > > > a regular installation of the world.  It could be something easier by 
> > > > direkctly
> > > > install-only the mk-portions, but recently, some changes to world 
> > > > (LLVM) made
> > > > it worth anyway to buildworld.
> > > > 
> > > > As recommended by others earlier on this list according to this 
> > > > subject, this
> > > > procedure makes the problem go away.
> > > 
> > > Thanks for your answer. Unfortunately, this didn't help.
> > >   
> > 
> > You are correct! I made a mistake and had the portions still commented out. 
> > I'm very
> > sorry.
> > 
> > This remains a bug!
> > 
> 
> This problem has been introduced with
> 
> svn commit: r328489 - head/sys/conf
> 
> The the appropriate list for reference.
> 

Indeed, reverting r328489 fixes the problem.


-- 
Regards, | "In theory there is no difference between theory
  Vladimir Zakharov  | and practice. In practice there is."- Yogi Berra
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

[O. Hartmann]

Am Sat, 3 Feb 2018 11:17:06 +0100
"O. Hartmann" <o.hartm...@walstatt.org> schrieb:

> Am Sat, 3 Feb 2018 11:10:53 +0300
> Vladimir Zakharov <zakharov...@gmail.com> schrieb:
> 
> > Hello, Oliver!
> > 
> > On Fri, Feb 02, 2018, O. Hartmann wrote:  
> > > On Thu, 1 Feb 2018 12:10:30 +0300
> > > Vladimir Zakharov <zakharov...@gmail.com> wrote:
> > > 
> > > > Hello!
> > > > 
> > > > For some time (about a week) building and installing kernel fails with
> > > > the error "Variable OBJTOP is recursive." when going to build/install
> > > > module from ports.
> > > > 
> > > > Last successful build was at r328426. Next build at r328527 failed and
> > > > still broken at r328649.
> > > > 
> > > > Without PORTS_MODULES building and installing kernel succeeds. Another
> > > > workaround: ignore error and build/install module directly from ports.
> > > > 
> > > 
> > > I have had the very same issue!
> > > 
> > > You need to perform a "installworld" first (just comment out the 
> > > PORTS_MODULES=
> > > parts of /etc/src.conf or /etc/make.conf, buildworld and buildkernel 
> > > (maybe not
> > > a full buildworld, but I do not know the state of your source tree) and 
> > > perform
> > > a regular installation of the world.  It could be something easier by 
> > > direkctly
> > > install-only the mk-portions, but recently, some changes to world (LLVM) 
> > > made
> > > it worth anyway to buildworld.
> > > 
> > > As recommended by others earlier on this list according to this subject, 
> > > this
> > > procedure makes the problem go away.
> > 
> > Thanks for your answer. Unfortunately, this didn't help.
> >   
> 
> You are correct! I made a mistake and had the portions still commented out. 
> I'm very
> sorry.
> 
> This remains a bug!
> 

This problem has been introduced with

svn commit: r328489 - head/sys/conf

The the appropriate list for reference.

oh
-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpFzlyQrHsoq.pgp
Description: OpenPGP digital signature

Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

[O. Hartmann]

Am Sat, 3 Feb 2018 11:10:53 +0300
Vladimir Zakharov <zakharov...@gmail.com> schrieb:

> Hello, Oliver!
> 
> On Fri, Feb 02, 2018, O. Hartmann wrote:
> > On Thu, 1 Feb 2018 12:10:30 +0300
> > Vladimir Zakharov <zakharov...@gmail.com> wrote:
> >   
> > > Hello!
> > > 
> > > For some time (about a week) building and installing kernel fails with
> > > the error "Variable OBJTOP is recursive." when going to build/install
> > > module from ports.
> > > 
> > > Last successful build was at r328426. Next build at r328527 failed and
> > > still broken at r328649.
> > > 
> > > Without PORTS_MODULES building and installing kernel succeeds. Another
> > > workaround: ignore error and build/install module directly from ports.
> > >   
> > 
> > I have had the very same issue!
> > 
> > You need to perform a "installworld" first (just comment out the 
> > PORTS_MODULES=
> > parts of /etc/src.conf or /etc/make.conf, buildworld and buildkernel (maybe 
> > not
> > a full buildworld, but I do not know the state of your source tree) and 
> > perform
> > a regular installation of the world.  It could be something easier by 
> > direkctly
> > install-only the mk-portions, but recently, some changes to world (LLVM) 
> > made
> > it worth anyway to buildworld.
> > 
> > As recommended by others earlier on this list according to this subject, 
> > this
> > procedure makes the problem go away.  
> 
> Thanks for your answer. Unfortunately, this didn't help.
> 

You are correct! I made a mistake and had the portions still commented out. I'm 
very
sorry.

This remains a bug!

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpUOEYTcpLE6.pgp
Description: OpenPGP digital signature

Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

[Vladimir Zakharov]

Hello, Oliver!

On Fri, Feb 02, 2018, O. Hartmann wrote:
> On Thu, 1 Feb 2018 12:10:30 +0300
> Vladimir Zakharov <zakharov...@gmail.com> wrote:
> 
> > Hello!
> > 
> > For some time (about a week) building and installing kernel fails with
> > the error "Variable OBJTOP is recursive." when going to build/install
> > module from ports.
> > 
> > Last successful build was at r328426. Next build at r328527 failed and
> > still broken at r328649.
> > 
> > Without PORTS_MODULES building and installing kernel succeeds. Another
> > workaround: ignore error and build/install module directly from ports.
> > 
> 
> I have had the very same issue!
> 
> You need to perform a "installworld" first (just comment out the 
> PORTS_MODULES=
> parts of /etc/src.conf or /etc/make.conf, buildworld and buildkernel (maybe 
> not
> a full buildworld, but I do not know the state of your source tree) and 
> perform
> a regular installation of the world.  It could be something easier by 
> direkctly
> install-only the mk-portions, but recently, some changes to world (LLVM) made
> it worth anyway to buildworld.
> 
> As recommended by others earlier on this list according to this subject, this
> procedure makes the problem go away.

Thanks for your answer. Unfortunately, this didn't help.

-- 
Regards, | "In theory there is no difference between theory
  Vladimir Zakharov  | and practice. In practice there is."- Yogi Berra
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

[O. Hartmann]

On Thu, 1 Feb 2018 12:10:30 +0300
Vladimir Zakharov <zakharov...@gmail.com> wrote:

> Hello!
> 
> For some time (about a week) building and installing kernel fails with
> the error "Variable OBJTOP is recursive." when going to build/install
> module from ports.
> 
> Last successful build was at r328426. Next build at r328527 failed and
> still broken at r328649.
> 
> Without PORTS_MODULES building and installing kernel succeeds. Another
> workaround: ignore error and build/install module directly from ports.
> 
> # cat /etc/make.conf
> MALLOC_PRODUCTION=yes
> KERNCONF=GENERIC-NODEBUG GENERIC
> #KERNCONF= GENERIC-NODEBUG
> CPUTYPE?=native
> #PORTS_MODULES = gPORTS_MODULES raphics/drm-next-kmod
> emulators/virtualbox-ose-kmod PORTS_MODULES = graphics/drm-next-kmod 
> 
> DOC_LANG = en_US.ISO8859-1 ru_RU.KOI8-R 
> 
> WITH_DEBUG_PORTS = mail/neomutt
> 
> WITH_CCACHE_BUILD=yes
> CCACHE_DIR=/home/ccache
> 
> #DEVELOPER=yes
> 
> ...
> Building /home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/kernel.full
> --- kernel.full ---
> linking kernel.full
> ctfmerge -L VERSION -g -o kernel.full ...
>   text  data   bssdec hex   filename
>   22584632   1376209   474   28709729   0x1b61361   kernel.full
> Building /home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/kernel.debug
> Building /home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/kernel
> --- all ---
> ===> Ports module graphics/drm-next-kmod (all)  
> cd ${PORTSDIR:-/usr/ports}/graphics/drm-next-kmod; env  -u CC  -u CXX
> -u CPP  -u MAKESYSPATH  MAKEFLAGS="-j 4 -J 15,16 -j 4 -J 15,16 -D
> NO_MODULES_OBJ .MAKE.LEVEL.ENV=MAKELEVEL KERNEL=kernel TARGET=amd64
> TARGET_ARCH=amd64"  SYSDIR=/usr/src/sys
> PATH=
> SRC_BASE=/usr/src  OSVERSION=1200056
> WRKDIRPREFIX=/home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG make -B
> clean build
> ===>  Cleaning for drm-next-kmod-g20180117
> ===>  License BSD2CLAUSE MIT GPLv2 accepted by the user
> ===>   drm-next-kmod-g20180117 depends on file: /usr/local/sbin/pkg - found
> ===> Fetching all distfiles required by drm-next-kmod-g20180117 for building
> ===>  Extracting for drm-next-kmod-g20180117
> => SHA256 Checksum OK for FreeBSDDesktop-kms-drm-g20180117-622fdd1_GH0.tar.gz.
> ===>  Patching for drm-next-kmod-g20180117
> ===>   drm-next-kmod-g20180117 depends on file: /usr/local/bin/ccache - found
> ===>  Configuring for drm-next-kmod-g20180117
> ===>  Building for drm-next-kmod-g20180117
> ===> drm (all)  
> Variable OBJTOP is recursive.
> 
> make[6]: stopped in 
> *** Error code 2
> 
> Stop.
> make[5]: stopped in 
> ===> Compilation failed unexpectedly.  
> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
> the maintainer.
> *** Error code 1
> 
> Stop.
> make[4]: stopped in /home/ports/graphics/drm-next-kmod
> *** Error code 1
> 
> Stop.
> make[3]: stopped in /home/ports/graphics/drm-next-kmod
> *** [all] Error code 1
> ...
> 

I have had the very same issue!

You need to perform a "installworld" first (just comment out the PORTS_MODULES=
parts of /etc/src.conf or /etc/make.conf, buildworld and buildkernel (maybe not
a full buildworld, but I do not know the state of your source tree) and perform
a regular installation of the world.  It could be something easier by direkctly
install-only the mk-portions, but recently, some changes to world (LLVM) made
it worth anyway to buildworld.

As recommended by others earlier on this list according to this subject, this
procedure makes the problem go away.

Kind regards,

Oliver
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

[Vladimir Zakharov]

Hello!

For some time (about a week) building and installing kernel fails with
the error "Variable OBJTOP is recursive." when going to build/install
module from ports.

Last successful build was at r328426. Next build at r328527 failed and
still broken at r328649.

Without PORTS_MODULES building and installing kernel succeeds. Another
workaround: ignore error and build/install module directly from ports.

# cat /etc/make.conf
MALLOC_PRODUCTION=yes
KERNCONF=GENERIC-NODEBUG GENERIC
#KERNCONF= GENERIC-NODEBUG
CPUTYPE?=native
#PORTS_MODULES = graphics/drm-next-kmod emulators/virtualbox-ose-kmod
PORTS_MODULES = graphics/drm-next-kmod 

DOC_LANG = en_US.ISO8859-1 ru_RU.KOI8-R 

WITH_DEBUG_PORTS = mail/neomutt

WITH_CCACHE_BUILD=yes
CCACHE_DIR=/home/ccache

#DEVELOPER=yes

...
Building /home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/kernel.full
--- kernel.full ---
linking kernel.full
ctfmerge -L VERSION -g -o kernel.full ...
  text  data   bssdec hex   filename
  22584632   1376209   474   28709729   0x1b61361   kernel.full
Building /home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/kernel.debug
Building /home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/kernel
--- all ---
===> Ports module graphics/drm-next-kmod (all)
cd ${PORTSDIR:-/usr/ports}/graphics/drm-next-kmod; env  -u CC  -u CXX
-u CPP  -u MAKESYSPATH  MAKEFLAGS="-j 4 -J 15,16 -j 4 -J 15,16 -D
NO_MODULES_OBJ .MAKE.LEVEL.ENV=MAKELEVEL KERNEL=kernel TARGET=amd64
TARGET_ARCH=amd64"  SYSDIR=/usr/src/sys
PATH=
SRC_BASE=/usr/src  OSVERSION=1200056
WRKDIRPREFIX=/home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG make -B
clean build
===>  Cleaning for drm-next-kmod-g20180117
===>  License BSD2CLAUSE MIT GPLv2 accepted by the user
===>   drm-next-kmod-g20180117 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by drm-next-kmod-g20180117 for building
===>  Extracting for drm-next-kmod-g20180117
=> SHA256 Checksum OK for FreeBSDDesktop-kms-drm-g20180117-622fdd1_GH0.tar.gz.
===>  Patching for drm-next-kmod-g20180117
===>   drm-next-kmod-g20180117 depends on file: /usr/local/bin/ccache - found
===>  Configuring for drm-next-kmod-g20180117
===>  Building for drm-next-kmod-g20180117
===> drm (all)
Variable OBJTOP is recursive.

make[6]: stopped in 
*** Error code 2

Stop.
make[5]: stopped in 
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make[4]: stopped in /home/ports/graphics/drm-next-kmod
*** Error code 1

Stop.
make[3]: stopped in /home/ports/graphics/drm-next-kmod
*** [all] Error code 1
...

-- 
Regards, | "In theory there is no difference between theory
  Vladimir Zakharov  | and practice. In practice there is."- Yogi Berra
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: PORTS_MODULES breakage on HEAD

[Don Lewis]

On 12 Aug, Bryan Drewery wrote:
> On 8/10/2016 4:20 PM, Bryan Drewery wrote:
>> On 8/7/16 5:44 PM, Don Lewis wrote:
>>> Adding PORTS_MODULES=emulators/virtualbox-ose-kmod recently broke on
>>> HEAD.  When I do that I get this failure:
>>>
>>> ===> Ports module emulators/virtualbox-ose-kmod (all)
>>> cd ${PORTSDIR:-/usr/ports}/emulators/virtualbox-ose-kmod; 
>>> PATH=/usr/obj/usr/src/
>>> tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/leg
>>> acy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/u
>>> sr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin  SRC_BASE=/usr/src  
>>> OSVERSION=12
>>> 0  WRKDIRPREFIX=/usr/obj/usr/src/sys/ make -B clean all
>>> ===>  Cleaning for virtualbox-ose-kmod-5.0.26_1
>>> ===>  License GPLv2 accepted by the user
>>> ===>  Found saved configuration for virtualbox-ose-kmod-4.3.34
>>> ===>   virtualbox-ose-kmod-5.0.26_1 depends on file: /usr/local/sbin/pkg - 
>>> found
>>> ===> Fetching all distfiles required by virtualbox-ose-kmod-5.0.26_1 for 
>>> buildin
>>> g
>>> ===>  Extracting for virtualbox-ose-kmod-5.0.26_1
>>> => SHA256 Checksum OK for VirtualBox-5.0.26.tar.bz2.
>>> ===>  Patching for virtualbox-ose-kmod-5.0.26_1
>>> ===>  Applying FreeBSD patches for virtualbox-ose-kmod-5.0.26_1
>>> ===>   virtualbox-ose-kmod-5.0.26_1 depends on executable: kmk - found
>>> ===>  Configuring for virtualbox-ose-kmod-5.0.26_1
>>> Checking for environment: Determined build machine: freebsd.amd64, target 
>>> machin
>>> e: freebsd.amd64, OK.
>>> Checking for kBuild: found, OK.
>>> Checking for gcc:
>>>   ** cc -target x86_64-unknown-freebsd12.0 --sysroot (variable CC) not 
>>> found!
>>> Check 
>>> /usr/obj/usr/src/sys/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualB
>>> ox-5.0.26/configure.log for details
>>> ===>  Script "configure" failed unexpectedly.
>>> Please report the problem to v...@freebsd.org [maintainer] and attach the
>>> "/usr/obj/usr/src/sys//usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5
>>> .0.26/config.log"
>>>
>>>
>>> It appears that the problem is due to CC being set to:
>>> cc -target x86_64-unknown-freebsd12.0 --sysroot
>>> and the Makefile for the port passes this:
>>> --with-gcc="${CC}"
>>> to configure.  The configure script passes $CC to check_avail, which
>>> does a -z test on it.
>>>
>>> I think that CC should just be set to "cc" and the rest should get added
>>> to CFLAGS.  I suspect this got broken by the recent crossbuild changes.
>>>
>> 
>> 
>> It's a SYSTEM_COMPILER bug.  I'll look into fixing it.
>> 
>> For now you can try passing WITHOUT_SYSTEM_COMPILER=yes as a workaround.
>> 
>> 
> 
> I've committed a fix to head in r304005. I will MFC it to stable/11 in
> about a week.

Thanks!

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: PORTS_MODULES breakage on HEAD

[Bryan Drewery]

On 8/10/2016 4:20 PM, Bryan Drewery wrote:
> On 8/7/16 5:44 PM, Don Lewis wrote:
>> Adding PORTS_MODULES=emulators/virtualbox-ose-kmod recently broke on
>> HEAD.  When I do that I get this failure:
>>
>> ===> Ports module emulators/virtualbox-ose-kmod (all)
>> cd ${PORTSDIR:-/usr/ports}/emulators/virtualbox-ose-kmod; 
>> PATH=/usr/obj/usr/src/
>> tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/leg
>> acy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/u
>> sr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin  SRC_BASE=/usr/src  
>> OSVERSION=12
>> 0  WRKDIRPREFIX=/usr/obj/usr/src/sys/ make -B clean all
>> ===>  Cleaning for virtualbox-ose-kmod-5.0.26_1
>> ===>  License GPLv2 accepted by the user
>> ===>  Found saved configuration for virtualbox-ose-kmod-4.3.34
>> ===>   virtualbox-ose-kmod-5.0.26_1 depends on file: /usr/local/sbin/pkg - 
>> found
>> ===> Fetching all distfiles required by virtualbox-ose-kmod-5.0.26_1 for 
>> buildin
>> g
>> ===>  Extracting for virtualbox-ose-kmod-5.0.26_1
>> => SHA256 Checksum OK for VirtualBox-5.0.26.tar.bz2.
>> ===>  Patching for virtualbox-ose-kmod-5.0.26_1
>> ===>  Applying FreeBSD patches for virtualbox-ose-kmod-5.0.26_1
>> ===>   virtualbox-ose-kmod-5.0.26_1 depends on executable: kmk - found
>> ===>  Configuring for virtualbox-ose-kmod-5.0.26_1
>> Checking for environment: Determined build machine: freebsd.amd64, target 
>> machin
>> e: freebsd.amd64, OK.
>> Checking for kBuild: found, OK.
>> Checking for gcc:
>>   ** cc -target x86_64-unknown-freebsd12.0 --sysroot (variable CC) not found!
>> Check 
>> /usr/obj/usr/src/sys/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualB
>> ox-5.0.26/configure.log for details
>> ===>  Script "configure" failed unexpectedly.
>> Please report the problem to v...@freebsd.org [maintainer] and attach the
>> "/usr/obj/usr/src/sys//usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5
>> .0.26/config.log"
>>
>>
>> It appears that the problem is due to CC being set to:
>>  cc -target x86_64-unknown-freebsd12.0 --sysroot
>> and the Makefile for the port passes this:
>>  --with-gcc="${CC}"
>> to configure.  The configure script passes $CC to check_avail, which
>> does a -z test on it.
>>
>> I think that CC should just be set to "cc" and the rest should get added
>> to CFLAGS.  I suspect this got broken by the recent crossbuild changes.
>>
> 
> 
> It's a SYSTEM_COMPILER bug.  I'll look into fixing it.
> 
> For now you can try passing WITHOUT_SYSTEM_COMPILER=yes as a workaround.
> 
> 

I've committed a fix to head in r304005. I will MFC it to stable/11 in
about a week.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: PORTS_MODULES breakage on HEAD

[Bryan Drewery]

On 8/7/16 5:44 PM, Don Lewis wrote:
> Adding PORTS_MODULES=emulators/virtualbox-ose-kmod recently broke on
> HEAD.  When I do that I get this failure:
> 
> ===> Ports module emulators/virtualbox-ose-kmod (all)
> cd ${PORTSDIR:-/usr/ports}/emulators/virtualbox-ose-kmod; 
> PATH=/usr/obj/usr/src/
> tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/leg
> acy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/u
> sr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin  SRC_BASE=/usr/src  
> OSVERSION=12
> 0  WRKDIRPREFIX=/usr/obj/usr/src/sys/ make -B clean all
> ===>  Cleaning for virtualbox-ose-kmod-5.0.26_1
> ===>  License GPLv2 accepted by the user
> ===>  Found saved configuration for virtualbox-ose-kmod-4.3.34
> ===>   virtualbox-ose-kmod-5.0.26_1 depends on file: /usr/local/sbin/pkg - 
> found
> ===> Fetching all distfiles required by virtualbox-ose-kmod-5.0.26_1 for 
> buildin
> g
> ===>  Extracting for virtualbox-ose-kmod-5.0.26_1
> => SHA256 Checksum OK for VirtualBox-5.0.26.tar.bz2.
> ===>  Patching for virtualbox-ose-kmod-5.0.26_1
> ===>  Applying FreeBSD patches for virtualbox-ose-kmod-5.0.26_1
> ===>   virtualbox-ose-kmod-5.0.26_1 depends on executable: kmk - found
> ===>  Configuring for virtualbox-ose-kmod-5.0.26_1
> Checking for environment: Determined build machine: freebsd.amd64, target 
> machin
> e: freebsd.amd64, OK.
> Checking for kBuild: found, OK.
> Checking for gcc:
>   ** cc -target x86_64-unknown-freebsd12.0 --sysroot (variable CC) not found!
> Check 
> /usr/obj/usr/src/sys/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualB
> ox-5.0.26/configure.log for details
> ===>  Script "configure" failed unexpectedly.
> Please report the problem to v...@freebsd.org [maintainer] and attach the
> "/usr/obj/usr/src/sys//usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5
> .0.26/config.log"
> 
> 
> It appears that the problem is due to CC being set to:
>   cc -target x86_64-unknown-freebsd12.0 --sysroot
> and the Makefile for the port passes this:
>   --with-gcc="${CC}"
> to configure.  The configure script passes $CC to check_avail, which
> does a -z test on it.
> 
> I think that CC should just be set to "cc" and the rest should get added
> to CFLAGS.  I suspect this got broken by the recent crossbuild changes.
> 


It's a SYSTEM_COMPILER bug.  I'll look into fixing it.

For now you can try passing WITHOUT_SYSTEM_COMPILER=yes as a workaround.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: PORTS_MODULES breakage on HEAD

[Kevin Oberman]

On Sun, Aug 7, 2016 at 5:44 PM, Don Lewis <truck...@freebsd.org> wrote:

> Adding PORTS_MODULES=emulators/virtualbox-ose-kmod recently broke on
> HEAD.  When I do that I get this failure:
>
> ===> Ports module emulators/virtualbox-ose-kmod (all)
> cd ${PORTSDIR:-/usr/ports}/emulators/virtualbox-ose-kmod;
> PATH=/usr/obj/usr/src/
> tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/
> usr/obj/usr/src/tmp/leg
> acy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/
> usr/bin:/sbin:/bin:/u
> sr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin  SRC_BASE=/usr/src
> OSVERSION=12
> 0  WRKDIRPREFIX=/usr/obj/usr/src/sys/ make -B clean all
> ===>  Cleaning for virtualbox-ose-kmod-5.0.26_1
> ===>  License GPLv2 accepted by the user
> ===>  Found saved configuration for virtualbox-ose-kmod-4.3.34
> ===>   virtualbox-ose-kmod-5.0.26_1 depends on file: /usr/local/sbin/pkg -
> found
> ===> Fetching all distfiles required by virtualbox-ose-kmod-5.0.26_1 for
> buildin
> g
> ===>  Extracting for virtualbox-ose-kmod-5.0.26_1
> => SHA256 Checksum OK for VirtualBox-5.0.26.tar.bz2.
> ===>  Patching for virtualbox-ose-kmod-5.0.26_1
> ===>  Applying FreeBSD patches for virtualbox-ose-kmod-5.0.26_1
> ===>   virtualbox-ose-kmod-5.0.26_1 depends on executable: kmk - found
> ===>  Configuring for virtualbox-ose-kmod-5.0.26_1
> Checking for environment: Determined build machine: freebsd.amd64, target
> machin
> e: freebsd.amd64, OK.
> Checking for kBuild: found, OK.
> Checking for gcc:
>   ** cc -target x86_64-unknown-freebsd12.0 --sysroot (variable CC) not
> found!
> Check /usr/obj/usr/src/sys/usr/ports/emulators/virtualbox-
> ose-kmod/work/VirtualB
> ox-5.0.26/configure.log for details
> ===>  Script "configure" failed unexpectedly.
> Please report the problem to v...@freebsd.org [maintainer] and attach the
> "/usr/obj/usr/src/sys//usr/ports/emulators/virtualbox-
> ose-kmod/work/VirtualBox-5
> .0.26/config.log"
>
>
> It appears that the problem is due to CC being set to:
> cc -target x86_64-unknown-freebsd12.0 --sysroot
> and the Makefile for the port passes this:
> --with-gcc="${CC}"
> to configure.  The configure script passes $CC to check_avail, which
> does a -z test on it.
>
> I think that CC should just be set to "cc" and the rest should get added
> to CFLAGS.  I suspect this got broken by the recent crossbuild changes.
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>

Same issue on 11.0-BETA4 (and at least BETA3). It's not just HEAD.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

PORTS_MODULES breakage on HEAD

[Don Lewis]

Adding PORTS_MODULES=emulators/virtualbox-ose-kmod recently broke on
HEAD.  When I do that I get this failure:

===> Ports module emulators/virtualbox-ose-kmod (all)
cd ${PORTSDIR:-/usr/ports}/emulators/virtualbox-ose-kmod; PATH=/usr/obj/usr/src/
tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/leg
acy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/u
sr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin  SRC_BASE=/usr/src  OSVERSION=12
0  WRKDIRPREFIX=/usr/obj/usr/src/sys/ make -B clean all
===>  Cleaning for virtualbox-ose-kmod-5.0.26_1
===>  License GPLv2 accepted by the user
===>  Found saved configuration for virtualbox-ose-kmod-4.3.34
===>   virtualbox-ose-kmod-5.0.26_1 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by virtualbox-ose-kmod-5.0.26_1 for buildin
g
===>  Extracting for virtualbox-ose-kmod-5.0.26_1
=> SHA256 Checksum OK for VirtualBox-5.0.26.tar.bz2.
===>  Patching for virtualbox-ose-kmod-5.0.26_1
===>  Applying FreeBSD patches for virtualbox-ose-kmod-5.0.26_1
===>   virtualbox-ose-kmod-5.0.26_1 depends on executable: kmk - found
===>  Configuring for virtualbox-ose-kmod-5.0.26_1
Checking for environment: Determined build machine: freebsd.amd64, target machin
e: freebsd.amd64, OK.
Checking for kBuild: found, OK.
Checking for gcc:
  ** cc -target x86_64-unknown-freebsd12.0 --sysroot (variable CC) not found!
Check /usr/obj/usr/src/sys/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualB
ox-5.0.26/configure.log for details
===>  Script "configure" failed unexpectedly.
Please report the problem to v...@freebsd.org [maintainer] and attach the
"/usr/obj/usr/src/sys//usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5
.0.26/config.log"


It appears that the problem is due to CC being set to:
cc -target x86_64-unknown-freebsd12.0 --sysroot
and the Makefile for the port passes this:
--with-gcc="${CC}"
to configure.  The configure script passes $CC to check_avail, which
does a -z test on it.

I think that CC should just be set to "cc" and the rest should get added
to CFLAGS.  I suspect this got broken by the recent crossbuild changes.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: PORTS_MODULES

[Daniel Braniss]

 Howdy,
 
 This is an FYI to let people know about a really nice feature for those
 that have ports installed which include kernel modules. You can place a
 list in /etc/src.conf like this:
 
 PORTS_MODULES=  emulators/virtualbox-ose-kmod sysutils/fusefs-kmod
 x11/nvidia-driver
 
 which will cause those modules to be built and installed with all the
 proper matching stuff at the same time as buildkernel and installkernel.
 
 This feature has existed for a while, but has had issues. Thanks to a
 team effort it's a lot more robust now, and ready for prime time (in
 HEAD, and the -STABLE branches for now, soon to be in 9.1-RELEASE).
 
 Enjoy,
 
 Doug

nice!
does it also work when cross-compiling? ie, using an amd64-freebsd-8.3 kernel
to compile for i386-freebsd-8.2

thanks,
danny


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: PORTS_MODULES

[Garrett Cooper]

On Mon, Jun 18, 2012 at 12:40 AM, Daniel Braniss da...@cs.huji.ac.il wrote:
 Howdy,

 This is an FYI to let people know about a really nice feature for those
 that have ports installed which include kernel modules. You can place a
 list in /etc/src.conf like this:

 PORTS_MODULES=  emulators/virtualbox-ose-kmod sysutils/fusefs-kmod
 x11/nvidia-driver

 which will cause those modules to be built and installed with all the
 proper matching stuff at the same time as buildkernel and installkernel.

 This feature has existed for a while, but has had issues. Thanks to a
 team effort it's a lot more robust now, and ready for prime time (in
 HEAD, and the -STABLE branches for now, soon to be in 9.1-RELEASE).

 Enjoy,

 Doug

 nice!
 does it also work when cross-compiling? ie, using an amd64-freebsd-8.3 kernel
 to compile for i386-freebsd-8.2

In theory, yes, however some of the environment required to
bootstrap some ports might be missing, depending on how the ports
module pokes around for data in /usr/src, etc.
Thanks!
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

PORTS_MODULES

[Doug Barton]

Howdy,

This is an FYI to let people know about a really nice feature for those
that have ports installed which include kernel modules. You can place a
list in /etc/src.conf like this:

PORTS_MODULES=  emulators/virtualbox-ose-kmod sysutils/fusefs-kmod
x11/nvidia-driver

which will cause those modules to be built and installed with all the
proper matching stuff at the same time as buildkernel and installkernel.

This feature has existed for a while, but has had issues. Thanks to a
team effort it's a lot more robust now, and ready for prime time (in
HEAD, and the -STABLE branches for now, soon to be in 9.1-RELEASE).

Enjoy,

Doug

-- 

This .signature sanitized for your protection

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: PORTS_MODULES fix

[Doug Barton]

On 06/09/2012 16:51, Doug Barton wrote:
 Ok, never mind the last one ... this patch I've actually tested. :)

Committed to HEAD and MFC'ed. Thanks everyone for the feedback and help.

Doug

-- 

This .signature sanitized for your protection


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

PORTS_MODULES fix

[Doug Barton]

I have recently tried the PORTS_MODULES knob, and found a problem. The
ports tree searches for some dependencies by finding a binary in PATH,
and that fails since by default /usr/local/ isn't there. The attached
patch fixes that problem.

It would be more robust to use PREFIX there instead of /usr/local
explicitly, but I'm not sure how to unravel the mk maze to get that
value. If anyone has a suggestion for that, I'd be happy to include it.

Any objections to making this change?

Doug

-- 

This .signature sanitized for your protection
Index: kern.post.mk
===
--- kern.post.mk(revision 236818)
+++ kern.post.mk(working copy)
@@ -38,7 +38,7 @@
 
 # Handle out of tree ports 
 .if !defined(NO_MODULES)  defined(PORTS_MODULES)
-PORTSMODULESENV=SYSDIR=${SYSDIR}
+PORTSMODULESENV=SYSDIR=${SYSDIR} PATH=${PATH}:/usr/local/bin:/usr/local/sbin
 .for __target in all install reinstall clean
 ${__target}: ports-${__target}
 ports-${__target}:
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: PORTS_MODULES fix

[Chris Rees]

On 9 June 2012 18:15, Doug Barton do...@freebsd.org wrote:
 I have recently tried the PORTS_MODULES knob, and found a problem. The
 ports tree searches for some dependencies by finding a binary in PATH,
 and that fails since by default /usr/local/ isn't there. The attached
 patch fixes that problem.

 It would be more robust to use PREFIX there instead of /usr/local
 explicitly, but I'm not sure how to unravel the mk maze to get that
 value. If anyone has a suggestion for that, I'd be happy to include it.

As you mention, PREFIX is only defined in ports/Mk, and it'd
definitely be undesirable to be including any of those files :)

The most robust (but unpleasant) solution would be one of the following:

PREFIX?=/usr/local
PORTSMODULESENV=SYSDIR=${SYSDIR} PATH=${PATH}:${PREFIX}/bin:${PREFIX}/sbin

or the equivalent (and perhaps cleaner, not leaving PREFIX defined)

.if !defined(PREFIX)
PORTSMODULESENV=SYSDIR=${SYSDIR} PATH=${PATH}:/usr/local/bin:/usr/local/sbin
.else
PORTSMODULESENV=SYSDIR=${SYSDIR} PATH=${PATH}:${PREFIX}/bin:${PREFIX}/sbin
.endif

Both of these will respect make.conf's setting of PREFIX.

Chris
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: PORTS_MODULES fix

[Matthew Seaman]

On 09/06/2012 18:26, Chris Rees wrote:
 On 9 June 2012 18:15, Doug Barton do...@freebsd.org wrote:
 I have recently tried the PORTS_MODULES knob, and found a problem. The
 ports tree searches for some dependencies by finding a binary in PATH,
 and that fails since by default /usr/local/ isn't there. The attached
 patch fixes that problem.

 It would be more robust to use PREFIX there instead of /usr/local
 explicitly, but I'm not sure how to unravel the mk maze to get that
 value. If anyone has a suggestion for that, I'd be happy to include it.
 
 As you mention, PREFIX is only defined in ports/Mk, and it'd
 definitely be undesirable to be including any of those files :)
 
 The most robust (but unpleasant) solution would be one of the following:
 
 PREFIX?=/usr/local
 PORTSMODULESENV=SYSDIR=${SYSDIR} PATH=${PATH}:${PREFIX}/bin:${PREFIX}/sbin
 
 or the equivalent (and perhaps cleaner, not leaving PREFIX defined)
 
 .if !defined(PREFIX)
 PORTSMODULESENV=SYSDIR=${SYSDIR} PATH=${PATH}:/usr/local/bin:/usr/local/sbin
 .else
 PORTSMODULESENV=SYSDIR=${SYSDIR} PATH=${PATH}:${PREFIX}/bin:${PREFIX}/sbin
 .endif
 
 Both of these will respect make.conf's setting of PREFIX.
 

Shouldn't you be looking for LOCALBASE rather than PREFIX in this context?

Cheers,

Matthew


-- 
Dr Matthew J Seaman MA, D.Phil.   7 Priory Courtyard
  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk   Kent, CT11 9PW





signature.asc
Description: OpenPGP digital signature

Re: PORTS_MODULES fix

[Doug Barton]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

On 06/09/2012 10:40, Matthew Seaman wrote:
 On 09/06/2012 18:26, Chris Rees wrote:
 On 9 June 2012 18:15, Doug Barton do...@freebsd.org wrote:
 I have recently tried the PORTS_MODULES knob, and found a
 problem. The ports tree searches for some dependencies by
 finding a binary in PATH, and that fails since by default
 /usr/local/ isn't there. The attached patch fixes that
 problem.
 
 It would be more robust to use PREFIX there instead of
 /usr/local explicitly, but I'm not sure how to unravel the mk
 maze to get that value. If anyone has a suggestion for that,
 I'd be happy to include it.
 
 As you mention, PREFIX is only defined in ports/Mk, and it'd 
 definitely be undesirable to be including any of those files :)
 
 The most robust (but unpleasant) solution would be one of the
 following:
 
 PREFIX?=/usr/local PORTSMODULESENV=SYSDIR=${SYSDIR}
 PATH=${PATH}:${PREFIX}/bin:${PREFIX}/sbin
 
 or the equivalent (and perhaps cleaner, not leaving PREFIX
 defined)
 
 .if !defined(PREFIX) PORTSMODULESENV=SYSDIR=${SYSDIR}
 PATH=${PATH}:/usr/local/bin:/usr/local/sbin .else 
 PORTSMODULESENV=SYSDIR=${SYSDIR}
 PATH=${PATH}:${PREFIX}/bin:${PREFIX}/sbin .endif
 
 Both of these will respect make.conf's setting of PREFIX.
 
 
 Shouldn't you be looking for LOCALBASE rather than PREFIX in this
 context?

Both good points. New and improved attached.

Doug

- -- 

This .signature sanitized for your protection
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)

iEYEAREDAAYFAk/TkJkACgkQyIakK9Wy8Pv36QCeMyL31kOIIwYX/6rCoKFqhufW
unsAnjoUG31Cr5TB0GZ1YPv4+zGuz+XY
=mM5z
-END PGP SIGNATURE-
Index: kern.post.mk
===
--- kern.post.mk(revision 236818)
+++ kern.post.mk(working copy)
@@ -38,7 +38,9 @@
 
 # Handle out of tree ports 
 .if !defined(NO_MODULES)  defined(PORTS_MODULES)
-PORTSMODULESENV=SYSDIR=${SYSDIR}
+# The ports tree looks for dependencies in PATH, so we need to accommodate
+LOCALBASE?=/usr/local
+PORTSMODULESENV=SYSDIR=${SYSDIR} 
PATH=${PATH}:${LOCALBASE}/bin:${LOCALBASE}/sbin
 .for __target in all install reinstall clean
 ${__target}: ports-${__target}
 ports-${__target}:
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: PORTS_MODULES fix

[Garrett Cooper]

On Sat, Jun 9, 2012 at 11:06 AM, Doug Barton do...@freebsd.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: RIPEMD160

 On 06/09/2012 10:40, Matthew Seaman wrote:
 On 09/06/2012 18:26, Chris Rees wrote:
 On 9 June 2012 18:15, Doug Barton do...@freebsd.org wrote:
 I have recently tried the PORTS_MODULES knob, and found a
 problem. The ports tree searches for some dependencies by
 finding a binary in PATH, and that fails since by default
 /usr/local/ isn't there. The attached patch fixes that
 problem.

 It would be more robust to use PREFIX there instead of
 /usr/local explicitly, but I'm not sure how to unravel the mk
 maze to get that value. If anyone has a suggestion for that,
 I'd be happy to include it.

 As you mention, PREFIX is only defined in ports/Mk, and it'd
 definitely be undesirable to be including any of those files :)

 The most robust (but unpleasant) solution would be one of the
 following:

 PREFIX?=/usr/local PORTSMODULESENV=SYSDIR=${SYSDIR}
 PATH=${PATH}:${PREFIX}/bin:${PREFIX}/sbin

 or the equivalent (and perhaps cleaner, not leaving PREFIX
 defined)

 .if !defined(PREFIX) PORTSMODULESENV=SYSDIR=${SYSDIR}
 PATH=${PATH}:/usr/local/bin:/usr/local/sbin .else
 PORTSMODULESENV=SYSDIR=${SYSDIR}
 PATH=${PATH}:${PREFIX}/bin:${PREFIX}/sbin .endif

 Both of these will respect make.conf's setting of PREFIX.


 Shouldn't you be looking for LOCALBASE rather than PREFIX in this
 context?

 Both good points. New and improved attached.

Looks like my patch, only with LOCALBASE being tunable and with
with ${LOCALBASE}/sbin (in short I found a few different bugs from you
a few months ago):
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/161452 .
Thanks!
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: PORTS_MODULES fix

[Doug Barton]

Ok, after reading your PR and discussion on IRC I have the following 
which incorporates all the suggestions so far. I haven't actually tested 
this yet, but if people agree that this is the right direction to go I 
will before I commit it of course.


Doug

--

It's always a long day; 86400 doesn't fit into a short.

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/
Index: kern.post.mk
===
--- kern.post.mk(revision 236818)
+++ kern.post.mk(working copy)
@@ -36,9 +36,30 @@
 .endif
 .endfor
 
-# Handle out of tree ports 
+# Handle ports (as defined by the user) that build kernel modules
 .if !defined(NO_MODULES)  defined(PORTS_MODULES)
-PORTSMODULESENV=SYSDIR=${SYSDIR}
+#
+# The ports tree needs some environment variables defined to match the new 
kernel
+#
+# Ports search for some dependencies in PATH, so add the location of the 
installed files
+LOCALBASE?=/usr/local
+# SRC_BASE is how the ports tree refers to the location of the base source 
files
+.if !defined(SRC_BASE)
+SRC_BASE!= realpath ${SYSDIR:H}/
+.endif
+# OSVERSION is used by some ports to determine build options
+.if !defined(OSRELDATE)
+# Definition copied from src/Makefile.inc1
+OSRELDATE!=awk '/^\#define[[:space:]]*__FreeBSD_version/ { print $$3 }' \
+   ${MAKEOBJDIRPREFIX}${SRC_BASE}/include/osreldate.h
+.endif
+# Keep the related ports builds in the obj directory so that they are only 
rebuilt once per kernel build
+WRKDIRPREFIX?= ${MAKEOBJDIRPREFIX}${SRC_BASE}/sys/${KERNCONF}/${__i}
+PORTSMODULESENV=\
+   PATH=   ${PATH}:${LOCALBASE}/bin:${LOCALBASE}/sbin \
+   SRC_BASE=   ${SRC_BASE} \
+   OSVERSION=  ${OSRELDATE} \
+   WRKDIRPREFIX=   ${WRKDIRPREFIX}
 .for __target in all install reinstall clean
 ${__target}: ports-${__target}
 ports-${__target}:
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: PORTS_MODULES fix

[Doug Barton]

Ok, never mind the last one ... this patch I've actually tested. :)

Doug

-- 

This .signature sanitized for your protection


Index: kern.post.mk
===
--- kern.post.mk(revision 236818)
+++ kern.post.mk(working copy)
@@ -36,9 +36,30 @@
 .endif
 .endfor
 
-# Handle out of tree ports 
+# Handle ports (as defined by the user) that build kernel modules
 .if !defined(NO_MODULES)  defined(PORTS_MODULES)
-PORTSMODULESENV=SYSDIR=${SYSDIR}
+#
+# The ports tree needs some environment variables defined to match the new 
kernel
+#
+# Ports search for some dependencies in PATH, so add the location of the 
installed files
+LOCALBASE?=/usr/local
+# SRC_BASE is how the ports tree refers to the location of the base source 
files
+.if !defined(SRC_BASE)
+SRC_BASE!= realpath ${SYSDIR:H}/
+.endif
+# OSVERSION is used by some ports to determine build options
+.if !defined(OSRELDATE)
+# Definition copied from src/Makefile.inc1
+OSRELDATE!=awk '/^\#define[[:space:]]*__FreeBSD_version/ { print $$3 }' \
+   ${MAKEOBJDIRPREFIX}${SRC_BASE}/include/osreldate.h
+.endif
+# Keep the related ports builds in the obj directory so that they are only 
rebuilt once per kernel build
+WRKDIRPREFIX?= ${MAKEOBJDIRPREFIX}${SRC_BASE}/sys/${KERNCONF}
+PORTSMODULESENV=\
+   PATH=${PATH}:${LOCALBASE}/bin:${LOCALBASE}/sbin \
+   SRC_BASE=${SRC_BASE} \
+   OSVERSION=${OSRELDATE} \
+   WRKDIRPREFIX=${WRKDIRPREFIX}
 .for __target in all install reinstall clean
 ${__target}: ports-${__target}
 ports-${__target}:
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: PORTS_MODULES fix

[Garrett Cooper]

On Jun 9, 2012, at 4:51 PM, Doug Barton wrote:

 Ok, never mind the last one ... this patch I've actually tested. :)

This one looks good :) (and fixes the item I briefly mentioned in IRC); 
I'll test it one out.
Thanks!
-Garrett___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org