Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C

2023-03-07 Thread Mark Millard
Dimitry Andric  wrote on
Date: Thu, 02 Mar 2023 10:13:51 UTC :

> On 2 Mar 2023, at 06:41, FreeBSD User  wrote:
>> 
>> Am Mon, 27 Feb 2023 23:46:21 +0100
>> Dimitry Andric  schrieb:
> ...
>> 
>> I tried to find some documentation on my CURRENT host regarding 
>> "WITH_SYSTEM_COMPILER". None
>> found via man src.conf, nor via make make.conf. Please delegate me to some 
>> place where I can
>> find such infos.
> 
> Ah I was confused, WITH_SYSTEM_COMPILER is actually the default, and it
> means that you want to skip building the bootstrap compiler, and just
> use the host compiler.

If allowed?: Having a 13.* build 14.0 does not allow
skipping building the bootstrap compiler for buildworld
or kernel-toolchain (for the same processor family), for
example, if I understand right.

In other words, one does not have to explicitly use
WITHOUT_SYSTEM_COMPILER for such FreeBSD version-
increase builds, even for self-hosted builds: the
default works and is WITH_SYSTEM_COMPILER .

> The src.conf(5) man page documents the inverse
> settings instead:
> 
> WITHOUT_SYSTEM_COMPILER
> Do not opportunistically skip building a cross-compiler during
> the bootstrap phase of the build. Normally, if the currently
> installed compiler matches the planned bootstrap compiler type
> and revision, then it will not be built. This does not prevent a
> compiler from being built for installation though, only for
> building one for the build itself. The WITHOUT_CLANG option
> controls that.

Explicit WITHOUT_SYSTEM_COMPILER usage is unconditional,
unlike WITH_SYSTEM_COMPILER usage (implicit or explicit)
depending on both the FreeBSD version differences and
the processor family relationship, if I understand right.

> WITHOUT_SYSTEM_LINKER
> Do not opportunistically skip building a cross-linker during the
> bootstrap phase of the build. Normally, if the currently
> installed linker matches the planned bootstrap linker type and
> revision, then it will not be built. This does not prevent a
> linker from being built for installation though, only for
> building one for the build itself. The WITHOUT_LLD option
> controls that.
> 
> This option is only relevant when WITH_LLD_BOOTSTRAP is set.
> 
> I find the double negative phrasing "do not skip" always confusing. But
> the logic is normally:
> 
> * The early phase of buildworld retrieves the versions of your host's
> compiler and linker
> * It compares it against the versions in the source tree
> * If the host compiler and linker are deemed "good enough", they are
> used as-is

(So I've effectively noted some of the not "good
enough" criteria above.)

> * If the host compiler or linker are not suitable, the compiler or
> linker are bootstrapped from the source tree
> 
> But WITH_SYSTEM_COMPILER turns off all these checks and forces it to use
> the host compiler,

Are you saying that an implicit WITH_SYSTEM_COMPILER
(no explicit WITHOUT_SYSTEM_COMPILER either) works
differently than an explicit WITH_SYSTEM_COMPILER for
FreeBSD version transitions? If so, I need to correct
my expectations.

> which might or might not work, depending on the
> circumstances. You may have to use NO_WERROR or other tricks.
> 
> 
> ...
>>> The safest solution is to let cross-tools do its thing, which will check
>>> the host compiler, and automatically build an appropriate version of the
>>> compiler and linker for the stable branch, if required.
>> 
>> I had a misunderstanding in the terminus "cross compiling", I check now the 
>> build with this
>> option set to be enabled.
> 
> Yes, this is a bit confusing, but in fact it *can* be a real cross
> compiler, if you are targeting another architecture, for example doing
> "make buildworld TARGET=arm64" from an x86_64 host.


In my view/expectation the differences between the Target
defaults for the likes of:

Target: x86_64-unknown-freebsd13.1
vs:
Target: x86_64-unknown-freebsd13.2
vs:
Target: x86_64-unknown-freebsd14.0

system compilers is enough to make having FreeBSD
from earlier in the list above build targeting a
later one in the list as a "bootstrap/cross compile":
in other words, either x86_64 vs. not or freebsdA.B
vs. freebsdX.Y differences count in the criteria and
either changing for FROM->TO ends up needing a
bootstrap/cross compiler.

> 
> And of course if you are building natively, it is 'just' a regular
> bootstrap compiler.

Not for freebsdA.B -> freebsdX.Y transitions, based
on changes in default targets (and other details that
may sometimes implicitly go with that differing
default Target being used in the new compiler).

===
Mark Millard
marklmi at yahoo.com




Re: PORTS_MODULES fails with beinstall.sh

2023-03-07 Thread 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

2023-03-07 Thread 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

2023-03-07 Thread 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)