pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Problems building pkgin on NetBSD 7/8





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


Home | Main Index | Thread Index | Old Index