Created attachment 226091 [details] do not build _p.a libraries Planning to remove _p.a libraries: https://reviews.freebsd.org/D30833 I doubt they would be used by ports, but would like to confirm.
Some new failure logs: http://gohan04.nyi.freebsd.org/data/main-amd64-PR256873-default/2021-06-28_18h09m10s/logs/errors/NunniMCAX-1.4.1.log http://gohan04.nyi.freebsd.org/data/main-amd64-PR256873-default/2021-06-28_18h09m10s/logs/errors/ab25-0.2.5.log http://gohan04.nyi.freebsd.org/data/main-amd64-PR256873-default/2021-06-28_18h09m10s/logs/errors/bbparse-0.1.0.log http://gohan04.nyi.freebsd.org/data/main-amd64-PR256873-default/2021-06-28_18h09m10s/logs/errors/bsd-plotutils-1.4.2_2.log http://gohan04.nyi.freebsd.org/data/main-amd64-PR256873-default/2021-06-28_18h09m10s/logs/errors/gdchart-0.11.5_10.log http://gohan04.nyi.freebsd.org/data/main-amd64-PR256873-default/2021-06-28_18h09m10s/logs/errors/iconv-2.0_4.log http://gohan04.nyi.freebsd.org/data/main-amd64-PR256873-default/2021-06-28_18h09m10s/logs/errors/libdistance-0.2.2_1.log http://gohan04.nyi.freebsd.org/data/main-amd64-PR256873-default/2021-06-28_18h09m10s/logs/errors/libhash-1.0.3.log http://gohan04.nyi.freebsd.org/data/main-amd64-PR256873-default/2021-06-28_18h09m10s/logs/errors/libmtrie-1.0.3.log http://gohan04.nyi.freebsd.org/data/main-amd64-PR256873-default/2021-06-28_18h09m10s/logs/errors/libphk-0.3.20080902_1.log http://gohan04.nyi.freebsd.org/data/main-amd64-PR256873-default/2021-06-28_18h09m10s/logs/errors/librs232-20190531.log http://gohan04.nyi.freebsd.org/data/main-amd64-PR256873-default/2021-06-28_18h09m10s/logs/errors/libs11n-1.2.10_1.log http://gohan04.nyi.freebsd.org/data/main-amd64-PR256873-default/2021-06-28_18h09m10s/logs/errors/libtnl-1.5.0_7.log http://gohan04.nyi.freebsd.org/data/main-amd64-PR256873-default/2021-06-28_18h09m10s/logs/errors/libublio-20070103_2.log http://gohan04.nyi.freebsd.org/data/main-amd64-PR256873-default/2021-06-28_18h09m10s/logs/errors/pam_search_list-0.1_1.log
Looking at the first one textproc/nunnimcax: pkg-static: Unable to access file /wrkdirs/usr/ports/textproc/nunnimcax/work/stage/usr/local/lib/libNunniMCAX_p.a:No such file or directory Makefile has: .if defined(NOPROFILE) || defined(NO_PROFILE) PLIST_SUB+= PROFILE="@comment " .else PLIST_SUB+= PROFILE="" .endif so it looks like the port inherits the base system default and attempts to detect whether it builds with -pg or not but using an obsolete mechanism
Ports that attempt to package _p.a depending on the state of PROFILE knob but do not work (obsolete mechanism or other failure): textproc/nunnimcax graphics/gdchart converters/iconv devel/libhash devel/libmtrie devel/libs11n net/libtnl devel/libublio* security/pam_search_list Ports that hardcode a _p.a library in their plist: multimedia/ab25 devel/bbparse graphics/bsd-plotutils devel/libdistance devel/libphk comms/librs232
mandree@, I see devel/libublio/Makefile has: .if defined(NO_PROFILE) || defined(NOPROFILE) || defined(WITHOUT_PROFILE) || "${MK_PROFILE}" == "no" PLIST_SUB+= PROFLIB="@comment " .else PLIST_SUB+= PROFLIB="" .endif this is the only port in the list that checks MK_PROFILE (which should be the correct variable) as opposed to checking (only) NO_PROFILE / NOPROFILE, but it seems bsd.opt.mk does not get included in the ports Makefile hierarchy.
(In reply to Ed Maste from comment #4) Ed, thanks for the heads up. I think this isn't easy to solve - because the ports' make.conf and the system's src.conf are distinct - but relevant, and in order to fix src.conf I had told the port to ignore it. I think the least effort for this devel/libublio port would be to just ditch the profiling library. I will hold off on the commit until 2021Q3 has been branched though so we don't spoil it.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=62ff121df2a70f25fd1ef444ba50219585f25bd8 commit 62ff121df2a70f25fd1ef444ba50219585f25bd8 Author: Matthias Andree <mandree@FreeBSD.org> AuthorDate: 2021-07-06 18:21:29 +0000 Commit: Matthias Andree <mandree@FreeBSD.org> CommitDate: 2021-07-06 18:24:28 +0000 devel/libublio: remove *_p.a profiling library Since a port cannot reliably and easily infer the profiling configuration from src.conf (the ports framework defeats reading it, and historically the port had its troubles with that), remove the profiled libublio_p.a altogether. Bumps PORTREVISION due to pkg-plist change on most practical systems. Reported by: emaste@ PR: 256873 devel/libublio/Makefile | 18 +----------------- devel/libublio/files/Makefile | 2 ++ devel/libublio/pkg-plist | 1 - 3 files changed, 3 insertions(+), 18 deletions(-)
(In reply to Matthias Andree from comment #5) > I think the least effort for this devel/libublio port would be to just ditch > the profiling library. Thanks - that makes sense to me. I agree there's not much value in trying to keep _p.a support in individual ports (and it's also not worth trying to control it per release). I CC'd you specifically since it seems your port is the only one that tried to accommodate the current base system config. I'll try to see about submitting a patch similar to yours for important remaining ports.
CC maintainers of affected ports
I am not able to reproduce a failure in converters/iconv now.
net/libtnl: https://reviews.freebsd.org/D31446
textproc/nunnimcax: https://reviews.freebsd.org/D31447
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=fe52b7f60ef46b65b24d7810a07be04483299d89 commit fe52b7f60ef46b65b24d7810a07be04483299d89 Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2020-01-16 17:40:32 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2021-08-08 00:24:36 +0000 Disable PROFILE option by default Hardware based profiling (e.g. hwpmc) is much better and produces more useful results. Today the profiling lib archives (_p.a) serve no real purpose other than increasing the library build time. Both upstream and base system (in commit b762974cf4b9) Clang have been modified to remove the special case for linking against these libraries. Clang's -pg support and mcount() remain, so building with -pg can still be used on code that the user builds; we just no longer provide prebuilt libraries compiled with -pg. Discussed on freebsd-hackers[1] / freebsd-current [2] in 2020 and freebsd-arch [3] in 2021. A deprecation notice was added in commit 175841285e28. [1] https://lists.freebsd.org/pipermail/freebsd-hackers/2020-January/055551.html [2] https://lists.freebsd.org/pipermail/freebsd-current/2020-January/075105.html [3] https://lists.freebsd.org/archives/freebsd-arch/2021-June/000016.html PR: 256873 [exp-run] Reviewed by: imp, jhb, kib Relnotes: Yes Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D30833 share/mk/bsd.opts.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=40e75c6f7430e0b258be7d79ea1a23fe32c9df9e commit 40e75c6f7430e0b258be7d79ea1a23fe32c9df9e Author: Olivier Cochard <olivier@FreeBSD.org> AuthorDate: 2021-09-08 22:59:47 +0000 Commit: Olivier Cochard <olivier@FreeBSD.org> CommitDate: 2021-09-08 22:59:47 +0000 devel/bbparse: Fixing build PR: 256873 Sponsored by: Netflix devel/bbparse/Makefile | 2 -- 1 file changed, 2 deletions(-)