RE: [External] Re: RHEL/Centos 7 builtin vs pkgsrc zlib clash for Makefiles that include devel/zlib/buildlink3.mk

["Lai, Peter PW" <peter.lai2%prattwhitney.com@localhost>]

> -----Original Message-----
> From: Jason Bacon [mailto:outpaddling%yahoo.com@localhost]
> Sent: Monday, August 10, 2020 10:00 AM
> To: Lai, Peter PW <peter.lai2%prattwhitney.com@localhost>; pkgsrc-users%netbsd.org@localhost
> Subject: [External] Re: RHEL/Centos 7 builtin vs pkgsrc zlib clash for Makefiles
> that include devel/zlib/buildlink3.mk
> 
> On 2020-08-10 05:50, Lai, Peter PW wrote:
> > Environment:
> >
> > * RHEL 7.7 (Centos 7 for those playing at home I guess) in Azure.
> > * Toolchain: Software collection (SCL) devtoolset-9
> >
> > * Yum installs native zlib-devel as a dependency for openssl-devel
> >
> > * openssl-devel was installed in order to support PREFER_NATIVE=
> openssl
> >
> > Observations:
> >
> > In this environment because zlib-devel is installed, bootstrap by default
> picks up native zlib (/usr/include/zlib.h). When devel/libxml2 is then built, it is
> built against native zlib (libz.so.1 => /lib64/libz.so.1).
> >
> > Next, some packages that also include "../../devel/zlib/buildlink3.mk" such
> nginx is built, it pulls in devel/zlib. This is weird because RHEL 7 includes zlib
> 1.2.7 which satisfies zlib>=1.2.3 in buildlink3.
> >
> > What happens after is that libxml2 and downstream libxml2 dependencies
> (e.g. databases/postgresql) break because they see the pkgsrc zlib first:
> >
> > /mnt/datadisk01/pkg/bin/postgres: /mnt/datadisk01/pkg/lib/libz.so.1:
> > no version information available (required by
> > /mnt/datadisk01/pkg/lib/libxml2.so.2)
> >
> > # ldd /mnt/datadisk01/pkg/lib/libxml2.so.2
> > /mnt/datadisk01/pkg/lib/libxml2.so.2:
> > /mnt/datadisk01/pkg/lib/libz.so.1: no version information available
> > (required by /mnt/datadisk01/pkg/lib/libxml2.so.2)
> > /mnt/datadisk01/pkg/lib/libxml2.so.2:
> > /mnt/datadisk01/pkg/lib/libz.so.1: no version information available
> > (required by /mnt/datadisk01/pkg/lib/libxml2.so.2)
> >
> > I worked around this by adding zlib to PREFER_NATIVE when re-building
> nginx, but is there a better way to resolve this? This looks somewhat related
> to the continuing "pkg_install fails when archivers/xz is installed" thread
> because RPATH manipulation could be involved, but I am opening a separate
> thread in case it is not.
> This does look like the same issue that we've been discussing regarding xz
> and it's a great example of the kind of problems that are avoided by using
> PREFER_PKGSRC=yes (and/or PREFER_NATIVE=no).
> 
> What's your motive for using native openssl instead of pkgsrc?  The only
> issue I've seen with the latter is the need to manually install
> security/mozilla-rootcerts* or equivalent to make curl, etc. work with https.
> 
> If there's some other disadvantage to pkgsrc openssl, maybe we should try
> to correct it.

The RHEL version of OpenSSL is backported/patched 1.0.2k with the FIPS module compiled (and validated through vendor affirmed basis as per https://www.openssl.org/docs/fips.html). So provisional compliance with FIPS 140-2 level 1 can be met for binaries linked to wrapper module when the system & kernel are fips enabled and the binary uses the required calling convention to autoconfigure or manually configure FIPS operation mode: We fork the pkgsrc repo and patch Makefiles for downstream builds' configure knobs where applicable to enable the calling of openssl's fips mode for those apps.  I don't think this is worth correcting on the pkgsrc/NetBSD level for folks who need this niche requirement but I sent the message because the xz thread seemed related when dealing with a non-openssl-related base vs pkgsrc library issue...