Imported adjustments from Tuukka.

Remove redundant code, as suggested by des@. (Thanks!)

Removed redundant braces.

Simplified the code obtaining LOCALBASE as per @des' suggestion. (Thanks!)

• Avoid file conflicts in the -lib32 base packages (no duplicate installation of SPDX files)
• Rename the PCFILE variable to SBOMFILE to avoid confusion with PCFILES
• Fix typo in libmd.pc (thanks stephane.rochoy_stormshield.eu for the heads up!)

Use a stack buffer of MAXPATHLEN for localbase, as suggested by @des.

This update takes care of PERSONALITY_PATH in addition to PKG_DEFAULT_PATH.

In D56404#1309826, @markmi_dsl-only.net wrote:

What is the relationship of this type of change to use of ${PREFIX} when ports install themselves and it is not the /usr/local default value? (There is also a linux compatibility related standard default for PREFIX and folks can specify things like /opt .) There was a later change to use /usr/local/ when LOCALBASE was undefined.

But in response to that last change there is now from eduardo@freebsd.org :

This change doens't honour PREFIX when it is set to other path than
default "/usr/local/"

(Due to the message Nuno picked to reply to I ended up listed as the "To:", des and the lists Cc:'d.)

I figured I could at least ask the question here of the folks involved in the original review so that the question is not completely lost.

In D56474#1308969, @ivy wrote:

a couple of comments:

• i'm not sure this should be in release/, since it doesn't seem specific to building releases. iiuc, any src build will include the SBOM data if enabled.

In D56474#1309051, @ziaee wrote:

One thing we may want to investigate is building the SBOM files into the ELF headers instead. Sony has compiler extensions to do that -- https://github.com/sony/esstra/tree/poc/rust-llvm

• The SPDX files are now placed in their respective base packages.
• The source .pc files from illuusio were imported into release/sbom.

LGTM, thanks!

In D56591#1296034, @khorben wrote:

In D56591#1295928, @khorben wrote:

The latest update (with WARNS?=3) built correctly with clang; I am still testing with GCC 14.

It built correctly with GCC 14 as well.

Reverted the copyright to myself, and the license to ISC.

In D56589#1296262, @ngie wrote:

In D56589#1296252, @khorben wrote:

I gave the copyright back to pkgconf, as the comment and description primarily come from the pkgconf project.

While there, I also updated the SPDX-License-Identifier to pkgconf, as per the discussion here, and confirmed at https://spdx.org/licenses/pkgconf.html.

Does that mean that you need to credit DuckDuckGo or Google whenever you find a result?

I gave the copyright back to pkgconf, as the comment and description primarily come from the pkgconf project.

Updated the copyright, license text, and added the licenses = [ "pkgconf" ] as per ngie's advice; thank you!

In D56591#1295928, @khorben wrote:

The latest update (with WARNS?=3) built correctly with clang; I am still testing with GCC 14.

This is already in D56589; which version is best?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294724 confirms this patch to be fixing the build issue.

The latest update (with WARNS?=3) built correctly with clang; I am still testing with GCC 14.

Disable stricter warnings for the moment for libpkgconf, bomtool(1), and pkgconf(1) as suggested by ngie. Thanks!

This should address feedback from ivy:

Imported in 6294b6ab217a2d5f1d2bc23a64505a228294c508.

This addresses feedback from ivy, moving /usr/include/pkgconf into the pkgconf-dev package.
It also adds the files in /usr/include/pkgconf to the list of obsolete files when disabling the pkgconf option.

This update addresses feedback from bapt, more precisely:

In D56373#1291176, @bapt wrote:

I don't understand the point of merging both version why not only the latest ?

This patch adds /usr/local/etc/pkgconfig/personality.d to -DPERSONALITY_PATH in lib/libpkgconfig/Makefile, as requested by bapt at https://ron-dev.freebsd.org/FreeBSD/src/pulls/9.

This depends on the vendor import from D56373.

See also https://github.com/freebsd/freebsd-src/pull/1994 for a more complete draft pull-request and discussion around this project, together with a preview of the "finished product".
There is also a newer branch implementing the same on a more recent main, at https://github.com/khorben/freebsd-src/tree/khorben/spdxtool2.

This seems to do the trick for me too, testing on macOS/amd64; it does not seem to harm FreeBSD/amd64.

I offered the same patch in D51897, with:

Should we involve secteam@ regarding the extra algorithms enabled?
I am not aware of any security concern there as of today, but I think we had stuck with OpenSSL's own list of default algorithms so far for the base system.

In D51897#1186369, @ngie wrote:

This is sort of what the SRCS should be in libcrypto.so: https://gist.github.com/ngie-eign/e3fb2de6dc32bdfddb9be119058c4792 (it's not a complete picture, but it's a start).

In D51897#1186364, @ngie wrote:

params_idx.c is missing from secure/lib/libcrypto/Makefile. That's where the source should be plugged in (not the legacy provider).

Committed as e7be843b4a162e68651d3911f0357ed464915629 and 4757b351ea9d59d71d4a38b82506d2d16fcd560d.

Note that I have reservations about the part adding params_idx.c to the list of files built: from what I can tell, OpenSSL expects this to be available from libcrypto.so, instead of a copy inside the legacy provider module.
I suspect the more correct fix is to add the ossl_param_find_pidx to secure/lib/libcrypto/Version.map instead - which also kinda feels wrong.

In D47933#1185773, @carlavilla wrote:

@khorben_defora.org can I commit this?
For me is ok

Got 32-bit PowerPC to build.

I am now trying to build 32-bit PowerPC with this set in secure/lib/libcrypto/Makefile.common:

In D51613#1178895, @philip wrote:

I don't think PowerPC 32 failing is a blocker for main or stable/15: we're ending support for 32 bit platforms. Do we ever plan to merge this to stable/14 though?

I think this diff should also update secure/lib/libcrypto/Makefile.inc with the corresponding OPENSSL_VER and OPENSSL_DATE.

Even though I have the approval of my mentor, it would be great to have approval from the installer group for this change before I proceed with the commit.
Please let me know!