[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:
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.
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
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
You should be able to look in .buildlink and run ldd to actually check
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"
To prove this I set:
This then built libfetch with the pkgsrc openssl and let pkgin find it
However without these options set a simple make install
in the pkgin directory won't work.
"won't work" isn't speecific enough...
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:
On a freshly installed 7.2_STABLE system.
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.
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 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.
Main Index |
Thread Index |