Re: Problems building pkgin on NetBSD 7/8

[Mike Pumford <mpumford%mudcovered.org.uk@localhost>]

On 2020-01-21 20:22, Greg Troxel wrote:
> Mike Pumford <mpumford%mudcovered.org.uk@localhost> writes:
>
> > On 2020-01-21 00:45, Mike Pumford wrote:
> > > Anyone else seeing this:
> > >
> > > checking for library containing socket... none required
> > > checking for library containing inet_addr... none required
> > > checking for strlcpy in -lnbcompat... yes
> > > checking for library containing fetchGetURL... no
> > > configure: error: libfetch not found.
> > > *** Error code 1
> > >
> > > libfetch IS installed. The .a is in /usr/pkg/lib and pkgsrc itself says:
> > >
> > > => Build dependency libfetch>=2.39nb1: found libfetch-2.39nb1
> > > => Build dependency cwrappers>=20150314: found cwrappers-20180325
> > > => Full dependency pkg_install>=20130901: found pkg_install-20191008nb1
> > > => Full dependency openssl>=1.1.1dnb2: found openssl-1.1.1dnb2
> > > ===> Overriding tools for pkgin-0.15.0nb1
> > >
> > > My chroot package builds using libkver have started reporting this
> > > on Both 7.2 and 8.1 amd64. Build host is actually 9.0-RC1 and
> > > building pkgin for the native 9.0-RC1 amd64 work fine.
> > Okay I THINK I've figured this out.
> >
> > pkgin is now forcibly depending on openssl 1.1.1 from pkgsrc on 8.x
> > and 7.x.
>
> pkgin depends on openssl.  On systems that don't have 1.1, it's going to
> use the pkgsrc version, because 1.0 is too old to use.
>
> > However its libfetch dependency is being built to satisfy pkg_install.
>
> I completely do not follow that statement.
>
> > libfetch doesn't default to building with openssl support at all and
> > has to be forcibly told to use pkgsrc openssl over the builtin one. I
> > THINK (but I'm not 100% sure that openssl support might be enabled in
> > libfetch using the system openssl by default).
>
> It's messier than that.  See net/libfetch/options.mk, where it does
> something a bit complicated and non-standard to try to enable openssl by
> default if using openssl would use the system openssl.
>
> We are going to have to choose between this style and just using pkgsrc
> openssl, or not using openssl in libfetch.   I think the real question
> is if system openssl on 8.x is good enough, or if it isn't good enough.
> We need one answer to that question, not two.
>
> > So I suspect that the reason libfetch can't be found is because there
> > is a conflict between the system openssl and the one being referenced
> > by pkgin.
>
> You should be able to look in .buildlink and run ldd to actually check
> those asssmptions.
I did confirm that libfetch was in the buildlink directory and after the 
fact did confirm that libfetch used the system openssl. Your earlier 
hint about checking .buildlink did help me work this out. I couldn't run 
ldd as the chroot I'm playing in deliberately self destructs at the end 
of the build at the moment :( I will be adding some logic to keep around 
the work directories for failing builds so I can troubleshoot this 
better in future.

> > To prove this I set:
> > PKG_OPTIONS.libfetch=inet6 openssl
> > USE_BUILTIN.openssl=no
> >
> > This then built libfetch with the pkgsrc openssl and let pkgin find it
> > successfully.
>
> > However without these options set a simple make install
> > in the pkgin directory won't work.
>
> "won't work" isn't speecific enough...
Won't work will in this case mean: "Will fail to build reporting a false 
error about being unable to find libfetch even though the pkgsrc 
libfetch (built with the system openssl) has been correctly buildlinked 
into the .buildlink directory"

I first ran into this in my 7.2 stable chroot using pkg_comp where apart 
from cwrappers, osabi  and libkver which are built by pkg-comp pkgin is 
the first package I build so pkgsrc was entirely responsible for 
building all packages. Meaning I effectively ran:

cd /usr/pkgsrc/pkgtools/pkgin
make install

On a freshly installed 7.2_STABLE system.
> There are no bulk builds (that I know of) for 7 and 8 with
> pkgsrc-current.  I think that's not good, but someone needs to set them
> up, which is not only effort but some beefy compute/ram/ssd resources.
>
> I think it's quite plausible you are the first.  The commit to update
> openssl to 1.1.1 is very recent.
I didn't know that. I don't mind being the canary for this and other 
8.x, 7.x build issues with pkgsrc-current :). Whilst I don't have the 
resources to do a full bulk build I do do weekly package builds for 
7.2-STABLE amd64, and 8.1_STABLE amd64 and i386 that contain the 
packages I need.

I was being it bit paranoid about reporting this as I'm experimenting 
with a more homegrown chroot system and I wasn't 100% sure that the new 
environment was set up correctly.

Mike