| Message ID | 20230724014832.2207166-1-alistair.francis@wdc.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | [v2,1/2] package/libopenssl: Copy the crypto include files | expand |
On Mon, 24 Jul 2023 11:48:31 +1000 Alistair Francis <alistair23@gmail.com> wrote: > diff --git a/package/libopenssl/libopenssl.mk b/package/libopenssl/libopenssl.mk > index 06eac8f3d9..c66a842cdf 100644 > --- a/package/libopenssl/libopenssl.mk > +++ b/package/libopenssl/libopenssl.mk > @@ -126,6 +126,10 @@ endef > > define LIBOPENSSL_INSTALL_STAGING_CMDS > $(TARGET_MAKE_ENV) $(MAKE) -C $(@D) DESTDIR=$(STAGING_DIR) install > + mkdir -p $(STAGING_DIR)/usr/include/crypto > + $(INSTALL) -m 644 $(@D)/include/crypto/* $(STAGING_DIR)/usr/include/crypto/ > + mkdir -p $(STAGING_DIR)/usr/include/internal > + $(INSTALL) -m 644 $(@D)/include/internal/* $(STAGING_DIR)/usr/include/internal/ I'm still quite concerned about this. Why the heck does libspdm require the internal/private headers of OpenSSL, and no other package needs that? It seems very odd, and potentially very wrong. One can assume such internal headers expose internal APIs that don't have the same backward compatibility guarantees as public APIs. What makes libspdm so special? Is there any potential side effect of exposing those OpenSSL private/internal headers to the wider world, as your patch does? Best regards, Thomas
On Sun, Aug 6, 2023 at 9:49 AM Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > On Mon, 24 Jul 2023 11:48:31 +1000 > Alistair Francis <alistair23@gmail.com> wrote: > > > diff --git a/package/libopenssl/libopenssl.mk b/package/libopenssl/libopenssl.mk > > index 06eac8f3d9..c66a842cdf 100644 > > --- a/package/libopenssl/libopenssl.mk > > +++ b/package/libopenssl/libopenssl.mk > > @@ -126,6 +126,10 @@ endef > > > > define LIBOPENSSL_INSTALL_STAGING_CMDS > > $(TARGET_MAKE_ENV) $(MAKE) -C $(@D) DESTDIR=$(STAGING_DIR) install > > + mkdir -p $(STAGING_DIR)/usr/include/crypto > > + $(INSTALL) -m 644 $(@D)/include/crypto/* $(STAGING_DIR)/usr/include/crypto/ > > + mkdir -p $(STAGING_DIR)/usr/include/internal > > + $(INSTALL) -m 644 $(@D)/include/internal/* $(STAGING_DIR)/usr/include/internal/ > > I'm still quite concerned about this. Why the heck does libspdm require > the internal/private headers of OpenSSL, and no other package needs > that? It seems very odd, and potentially very wrong. One can assume > such internal headers expose internal APIs that don't have the same > backward compatibility guarantees as public APIs. Yeah, you are right. I'm going to work with upstream libspdm to remove the requirement on these and then I'll try again. Alistair > > What makes libspdm so special? Is there any potential side effect of > exposing those OpenSSL private/internal headers to the wider world, as > your patch does? > > Best regards, > > Thomas > -- > Thomas Petazzoni, co-owner and CEO, Bootlin > Embedded Linux and Kernel engineering and training > https://bootlin.com
diff --git a/package/libopenssl/libopenssl.mk b/package/libopenssl/libopenssl.mk index 06eac8f3d9..c66a842cdf 100644 --- a/package/libopenssl/libopenssl.mk +++ b/package/libopenssl/libopenssl.mk @@ -126,6 +126,10 @@ endef define LIBOPENSSL_INSTALL_STAGING_CMDS $(TARGET_MAKE_ENV) $(MAKE) -C $(@D) DESTDIR=$(STAGING_DIR) install + mkdir -p $(STAGING_DIR)/usr/include/crypto + $(INSTALL) -m 644 $(@D)/include/crypto/* $(STAGING_DIR)/usr/include/crypto/ + mkdir -p $(STAGING_DIR)/usr/include/internal + $(INSTALL) -m 644 $(@D)/include/internal/* $(STAGING_DIR)/usr/include/internal/ endef define HOST_LIBOPENSSL_INSTALL_CMDS
libspdm uses the low level OpenSSL crypto APIs. In a traditional build libspdm has OpenSSL as a submodule and gets the include from there, when building with buildroot we want to use the prebuilt OpenSSL library, so we need to expose these crypto includes. This patch installs the crypto private headers so that libspdm can use them. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> --- package/libopenssl/libopenssl.mk | 4 ++++ 1 file changed, 4 insertions(+)