problem with "make index"
Hello: On a system runing: 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-d6327ae8c1: Sun Jan 24 14:16:54 EST 2021 amd64 with the ports tree updated nightly, "make index" stops with: --- describe.x11-toolkits --- --- describe.x11-wm --- make_index: /usr/ports/www/firefox: no entry for /usr/ports/devel/wasi-compiler-rt14 Done. ... and, indeed, there is no such port. Is this something I've broken, or is there another explanation? Respectfully, Robert Huff
Re: problem with "make index"
Am 15.07.22 um 14:19 schrieb Robert Huff:
Hello:
On a system runing:
14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-d6327ae8c1:
Sun Jan 24 14:16:54 EST 2021 amd64
with the ports tree updated nightly, "make index" stops with:
--- describe.x11-toolkits ---
--- describe.x11-wm ---
make_index: /usr/ports/www/firefox: no entry for
/usr/ports/devel/wasi-compiler-rt14
Done.
... and, indeed, there is no such port.
Is this something I've broken, or is there another explanation?
You seem to have LLVM_DEFAULT set to 14:
BUILD_DEPENDS+= [...] \
${LOCALBASE}/llvm${LLVM_DEFAULT}/lib/clang/${LLVM_VERSION}/lib/wasi/libclang_rt.builtins-wasm32.a:devel/wasi-compiler-rt${LLVM_DEFAULT}
Regards, STefan
Unmaintained FreeBSD ports which are out of date
Dear port maintainers, The portscout new distfile checker has detected that one or more unmaintained ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. Please consider also adopting this port. If any ports have already been updated, you can safely ignore the entry. An e-mail will not be sent again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ japanese/mecab-ipadic-utf8 | 2.7.0-20070801 | 2.7.1-0001 +-+ sysutils/google-compute-engine-oslogin | 20191018.00 | 20220714.00 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by:portscout!
Re: problem with "make index"
Steffan Esser: > Am 15.07.22 um 14:19 schrieb Robert Huff: > > > > Hello: > > On a system runing: > > > > 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-d6327ae8c1: > > Sun Jan 24 14:16:54 EST 2021 amd64 > > > > with the ports tree updated nightly, "make index" stops with: > > > > --- describe.x11-toolkits --- > > --- describe.x11-wm --- > > make_index: /usr/ports/www/firefox: no entry for > > --- /usr/ports/devel/wasi-compiler-rt14 > > Done. > > > > ... and, indeed, there is no such port. > > Is this something I've broken, or is there another explanation? > > You seem to have LLVM_DEFAULT set to 14: That is correct. A) so there is no such port? (I was under the impression each llvm had a matching wasi-compiler-rt.) B) will setting LLVM_DEFAULT to 13 (there _is_ a wasi-compiler-rt13) fix things? Respectfully, Robert Huff
Re: problem with "make index"
Am 15.07.22 um 23:38 schrieb Robert Huff: Steffan Esser: Am 15.07.22 um 14:19 schrieb Robert Huff: > > Hello: > On a system runing: > > 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-d6327ae8c1: > Sun Jan 24 14:16:54 EST 2021 amd64 > > with the ports tree updated nightly, "make index" stops with: > > --- describe.x11-toolkits --- > --- describe.x11-wm --- > make_index: /usr/ports/www/firefox: no entry for > --- /usr/ports/devel/wasi-compiler-rt14 > Done. > > ... and, indeed, there is no such port. > Is this something I've broken, or is there another explanation? You seem to have LLVM_DEFAULT set to 14: That is correct. A) so there is no such port? (I was under the impression each llvm had a matching wasi-compiler-rt.) I have just committed a port for LLVM 14. It is build tested, but I did not have time to perform any run tests. I have copied over the Makefile of the wasi-compile-rt13 port and have only changed the DISTVERSION to 14.0.6 and regenerated the distinfo file. B) will setting LLVM_DEFAULT to 13 (there _is_ a wasi-compiler-rt13) fix things? Yes, if you do not need LLVM 14 for some reason, then staying at 13 is the easy way to resolve such issues, until version 14 is fully supported in the ports tree. Please let me know if you find that the wasi-compile-rt14 port does not work correctly. I have preserved the MAINTAINER of wasi-compile-rt13 in this port, but if there are issues, I'd feel responsible to fix them before handing the responsibility for further updates over to greg ... ;-) Regards, STefan
Re: problem with "make index"
I need to clear some stuff here. There was a phab review brewing for some time https://reviews.freebsd.org/D35288 Stefan Esser wrote: I have just committed a port for LLVM 14. It is build tested, but I did not have time to perform any run tests. First mistake. The entire WASI toolchain has to be updated, since this is LLVM and no API/ABI compatibility between major versions and all. See the phab chain, where one item actually had to be reverted to a previous upstream revision. I have copied over the Makefile of the wasi-compile-rt13 port and have only changed the DISTVERSION to 14.0.6 and regenerated the distinfo file. B) will setting LLVM_DEFAULT to 13 (there _is_ a wasi-compiler-rt13) fix things? Yes, if you do not need LLVM 14 for some reason, then staying at 13 is the easy way to resolve such issues, until version 14 is fully supported in the ports tree. Staying at 13 or another LLVM version where the entire chain's version matches is required unless you are okay with unexpected or unexplainable failures. Please let me know if you find that the wasi-compile-rt14 port does not work correctly. I have preserved the MAINTAINER of wasi-compile-rt13 in this port, but if there are issues, I'd feel responsible to fix them before handing the responsibility for further updates over to greg ... ;-) I will go further: This was not to be committed at all right now, despite appearances. And I say this as one who is still dogfooding the entire WASI-LLVM 14 chain, with www/firefox as the prime consumer, with LTO enabled. Those interested in helping dogfood, identify failure modes, et al with LLVM_DEFAULT=14 can grab the entire diff chain off phab and apply it to your own tree or overlay. But that doesn't address an even bigger issue that's still being figured out: how to make this whole situation, LTO or not, less fragile to deal with. -- Charlie Li …nope, still don't have an exit line. OpenPGP_signature Description: OpenPGP digital signature
Re: problem with "make index"
Am 16.07.22 um 03:12 schrieb Charlie Li:
I need to clear some stuff here. There was a phab review brewing for some time
https://reviews.freebsd.org/D35288
Hi,
sorry, I have not been aware of the review. It has been opened on 2022-05-22,
and I see that it has been worked on in the nearly 8 weeks since then, with
the last update of the proposed patch ten days ago.
Stefan Esser wrote:
I have just committed a port for LLVM 14. It is build tested, but I did
not have time to perform any run tests.
First mistake. The entire WASI toolchain has to be updated, since this is LLVM
and no API/ABI compatibility between major versions and all. See the phab
chain, where one item actually had to be reverted to a previous upstream revision.
The reason that I have committed the port at this time was that "make index"
is broken with LLVM_DEFAULT set to 14. I have considered this a fix of the
port system, but forgot to mention that detail in the commit log.
I have copied over the Makefile of the wasi-compile-rt13 port and have
only changed the DISTVERSION to 14.0.6 and regenerated the distinfo file.
B) will setting LLVM_DEFAULT to 13 (there _is_ a wasi-compiler-rt13)
fix things?
Yes, if you do not need LLVM 14 for some reason, then staying at 13
is the easy way to resolve such issues, until version 14 is fully
supported in the ports tree.
Staying at 13 or another LLVM version where the entire chain's version matches
is required unless you are okay with unexpected or unexplainable failures.
The problem with a missing wasi-compile-rt14 port is that it breaks "make
index" even for users that are not interested in WASI at all ...
Maybe, a port should have been committed marked
IGNORE= Not ready, see https://reviews.freebsd.org/D35288
in order to not break "make index" with the non-default LLVM_DEFAULT?
Please let me know if you find that the wasi-compile-rt14 port does not
work correctly.
I have preserved the MAINTAINER of wasi-compile-rt13 in this port, but
if there are issues, I'd feel responsible to fix them before handing
the responsibility for further updates over to greg ... ;-)
I will go further:
This was not to be committed at all right now, despite appearances. And I say
this as one who is still dogfooding the entire WASI-LLVM 14 chain, with
www/firefox as the prime consumer, with LTO enabled. Those interested in
helping dogfood, identify failure modes, et al with LLVM_DEFAULT=14 can grab
the entire diff chain off phab and apply it to your own tree or overlay.
There is no mention of related revisions in https://reviews.freebsd.org/D35288,
maybe you could connect this review to others that are required for WASI with
LLVM 14?
I see that D35286 to D35389 cover this whole topic, and that there still are
unresolved run-time issues that prevent them from actually being used.
BTW: I see that wasi-libc and wasi-libc++ do not contain the LLVM version
in their ${PKGBASE} values. I'd have expected that only wasi-libc built with
LLVM 14 could be used in wasi-compile-rt14 and thus that it would be good to
have some mention of LLVM_DEFAULT in the package base name?
But that doesn't address an even bigger issue that's still being figured out:
how to make this whole situation, LTO or not, less fragile to deal with.
I see - do you want me to revert this commit?
But there still is the issue of the missing wasi-compile-rt14 breaking
"make index" with LLVM_DEFAULT=14 and some (working or not working) port
needs to exist at that origin to allow this changed default (Which may be
required to test other ports with LLVM 14).
Please try to find a solution that does not prevent "make index" with a
non-default LLVM_VERSION - perhaps a commit of a Makefile skeleton with
just the minimum set of variables and IGNORE set as suggested above?
Feel free to revert the commit if you think it would be causing issues for
you (e.g. bug reports for a known unfinished port), but I'd really prefer
the port to exist but be ignored.
Regards, STefan
