Getting cross compilation to work.

[Dridi Boukelmoune]

On Wed, Apr 22, 2026 at 7:17 AM Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>
> --------
> Per Buer writes:
>
>
> > Right.
> >
> > One could argue there is a point in building man pages for a specific arch,
> > but I'd rather there be just a single version of each man page and that the
> > man pages match what is one the web.
>
> I agree.
>
> I dont think we have ever made that an explicit decision, but as
> far as I can tell, we are already pretty close ?
>
> All platforms/archs/distros have the same set of parameters, and any
> inapplicable paramters have "#define PLATFORM_FLAGS NOT_IMPLEMENTED" which
> causes param.* CLI commands to "neuter" them, for instanc on (s390) linux:
>
>         param.show accept_filter
>         200 137
>         accept_filter
>                 Not available
>                 [too many blank lines]
>                 NB: This parameter depends on a feature which is not available
>                 on this platform.
>
> But the documentation built on that same (s390) linux, has the same
> full spiel about that parameter, as the docs built on FreeBSD where
> accept_filter does work.
>
> So as far as I can tell, it is only dynamically determined aspects of
> the parameters (min/max/default) which vary between platforms and
> in the docs ?
>
> Have I overlooked something ?
>
> > If I were starting over, I think I would prefer the doc to say
> > > "determined at runtime" rather than contain numbers which may or
> > > may not have anything to do with reality.
> > >
> >
> > That is a reasonable stance. I agree.
>
> Anybody else want to chime in ?

We should already generate the same manual for every architecture,
maybe modulus 32 vs 64 bits. So that should already cover both
"determined at runtime" but also "determined at configure time".

With param.show we get the host-specific information as it is known at
run time (including actual dynamic bounds).

I see that the default value in the manual for vcl_path no longer
shows "${sysconfdir}/varnish:${datadir}/varnish/vcl". And I see that
the minimum value for thread_pool_max is no longer "thread_pool_min"
in the manual. So it looks like a regression happened at some point,
because the whole point of 3099 was to take care of that.

https://github.com/varnishcache/varnish-cache/pull/3099


> > Reasonable. I got the CC trampoline it running last night, but autoconf's
> > default error handling is pretty lame.
>
> Dont get me started... :-)
>
> > ARM on the server-side is becoming increasingly important. It would be nice to
> > not have to find ARM hardware or spin up QEMU to build ARM packages.
>
> We have had ARM covered on FreeBSD for ages, initially on a BBB (32bit)
> and RPi (64bit) but now on a QualCom "Snapdragon" based Thinkpad.
>
> So far nobody has bothered to set up a RPI with a USB disk to get
> linux covered in a similar fashion, even though all they have to
> do is run the tools/vco_test.sh script.
>
> (Nudge, nudge, wink, wink, he said knowingly!) :-)
>
> > Also, I find the current setup somewhat offensive. Pretty clever, though.
>
> The goal was to avoid redundancy, which could get out of sync, and
> considering how seldom we add or remove params, I'll claim that it
> worked.  But yes: Not immediately obvious to the lay observer.
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.