On 2022/11/20 05:45, Brian Callahan wrote:
> Hi ports --
>
> Here is the update to DMD hinted at in my previous email updating LDC.
> Changelog is here: https://github.com/dlang/dmd/compare/v2.100.1...v2.101.0
>
> There were some big changes to the build system, hence some unavoidable
> churn in this update.
>
> Tests from other D users appreciated.
>
> OK?
Not a D user, but regenerating the bootstraps are useful.
I'd like to suggest a general tweak to the approach we use for
bootstraps though.
> post-extract:
..
> - chmod 644 ${WRKDIR}/dmd-bootstrap/openbsd/bin64/lib*.so* # XXX
> - cp /usr/lib/libc.so.96.* ${WRKDIR}/dmd-bootstrap/openbsd/bin64/ # XXX
We might as well keep replacing the libs with copies from /usr/lib.
I don't see a downside and there are upsides because it will be
more resilient where a library has been changed in bsae due to new
requirements from the kernel.
I think it would make sense to replace all the libraries rather than
just libc. libpthread is certainly one which sometimes needs changes
like this.
For example for dmd, something like this:
cd ${WRKDIR}/dmd-bootstrap/bin64 && \
for i in lib*.so*; do \
chmod 644 $$i; \
cp /usr/lib/$${i%.so.*}.so.* .; \
done
If a library major is bumped in base then the new file for that
library won't be picked up by ld.so anyway, so the library bundled
in the bootstrap file will continue to be used. That may or may
not work depending on the nature of changes but nothing new there,
this copying doesn't change that.
Obviously this doesn't just apply to dmd - it probably makes sense
to do the same for all ports using bootstraps. These are the
ones I know about:
devel/jdk/1.8
devel/jdk/11
devel/jdk/17
lang/dmd
lang/fpc
lang/gcc/11
lang/gcc/8
lang/ghc
lang/go
lang/ldc
lang/pypy
lang/rust
Obviously with the recent change we only had problems with a subset
of these ports; not all changes affect all ports/bootstraps.
If we agree on the direction then I can prepare diffs for these other
ports.
There was an alternative suggestion to rebuild all of the bootstraps
regularly even if they don't need it but this is simply not feasible.
Rebuilding these files, uploading them somewhere for distribution,
and updating the ports to use them can't be fully automated; for
some of them it's "just work" but for others it's a huge pain. These
ports involve 8 architectures; build times vary but several of these
ports take 1-2h on a fast amd64 and some up to 30 hours on slower
machines, but will also involve building a set of dependencies in
some cases (armv7 for example could easily take a week to do this).
