Created attachment 219630 [details] Patch file * Update to 4.94. * Update or remove patches that are included in upstream. Change Log: https://github.com/lsof-org/lsof/releases/tag/4.94.0
Created attachment 219789 [details] Updated patch file Fix build with __FreeBSD_version >= 1300130.
(In reply to Yasuhiro KIMURA from comment #1) This allows me to build and install on head. Thanks!
Checking __FreeBSD_version >= 1300130 is less reliable than checking for PWDDESC_KVM_LOAD_PWD. Wouldn't you think?
Created attachment 219864 [details] Updated patch file Fix build with Clang 11 without setting 'CFLAGS+=-fcommon' in Makefile.
(In reply to Cy Schubert from comment #3) What do you mean? In base r367777 FILEDESC_KVM_LOAD_PWD is replaced with PWDDESC_KVM_LOAD_PWD and also __FreeBSD_version is bumped to 1300130. So there is no difference between checking if PWDDESC_KVM_LOAD_PWD is defined and checking if __FreeBSD_version is 1300130 or later.
I really shouldn't have to explain myself as it should be obvious: There's a huge difference. If or when patch is MFCed, you or someone will need to add additional #if logic to fix the build yet again, this time for -STABLE, making for complex CPP logic. That's another PR and another patch that needs to be applied, additional churn to the repository.
(In reply to Cy Schubert from comment #6) One thing to mention. There is no MFC target specified in the commit message. If it's not a mistake, checking for __FreeBSD_version would be sufficient. Moreover, MFC'ing the commit could be POLA violation. There is no warranty that no other software, regardless in ports tree or in the wild, depend on the renamed macro. Of course, you are right if MFC is planned and the change is NOT considered as POLA violation.
MFC can happen even if MFC after is not specified. I've done it. And, anyone can MFC another committer's commits. Especially if the commit is a prereq. Anyhow, it's up to the port maintainer wants to do and maintainability. But personally, I'd try to avoid churn from the get-go.
Created attachment 220023 [details] Updated patch file Check if PWDDESC_KVM_LOAD_PWD instead of __FreeBSD_version is 1300130 or later.
(In reply to Cy Schubert from comment #6) Thanks for explanation. I didn't think of MFC at all.
This bit cannot possibly ever be correct: ++#else /* defined(PWDDESC_KVM_LOAD_PWD) */ + pwd_addr = (KA_T)FILEDESC_KVM_LOAD_PWD(&fd); you are passing filedesc to where pwddesc is expected.
Created attachment 221093 [details] Patch using new pwddesc structure instead (In reply to Alexander Kabaev from comment #11) Yes, indeed. Here's an alternative patch for the dproc.c part, which hopefully does the right thing. Builds OK, and while I can run lsof just fine, I'm unsure if I have correctly exercised this new part of the code.
Created attachment 221153 [details] Updated patch file Include Dimitry's patch.
Is there a reason this hasn't been committed yet?
Created attachment 222017 [details] Build on 14-CURRENT Build and install on 14-CURRENT.
*** Bug 251266 has been marked as a duplicate of this bug. ***
A commit references this bug: Author: dim Date: Sat Jan 30 13:12:17 UTC 2021 New revision: 563403 URL: https://svnweb.freebsd.org/changeset/ports/563403 Log: sysutils/lsof: Update to 4.94 * Update to 4.94. * Update or remove patches that are included in upstream. * Fix build with Clang 11 without setting 'CFLAGS+=-fcommon' in Makefile. * Use new pwddesc structure if applicable. Change Log: https://github.com/lsof-org/lsof/releases/tag/4.94.0 Submitted by: Yasuhiro Kimura <yasu@utahime.org> PR: 251096 MFH: 2021Q1 Changes: head/sysutils/lsof/Makefile head/sysutils/lsof/distinfo head/sysutils/lsof/files/patch-Configure head/sysutils/lsof/files/patch-dialects-freebsd-dlsof.h head/sysutils/lsof/files/patch-dialects_freebsd_dnode.c head/sysutils/lsof/files/patch-dialects_freebsd_dnode2.c head/sysutils/lsof/files/patch-dialects_freebsd_dproc.c head/sysutils/lsof/files/patch-dialects_freebsd_dsock.c