Re: [Trustedqsl-testing] OpenSSL 3.0.0

[Rick M. <k1...@ar...>]

On Mon, Dec 20, 2021 at 9:32 AM Greg Troxel <gd...@le...> wrote:

>
> Rick Murphy <k1...@ar...> writes:
>
> > [Sorry, this draft apparently has been stalled for some time unsent,[
>
> no worries, everybody is busy
>
> > I accepted the patches here, removed the RPATH setting, removed the
> setting
> > for library path, and added an include for GNUInstallPaths, all of which
> I
> > assumed would make this a distribution responsibility.
>
> I tried to point out when I saw the patches that, while sensible in the
> environment they were for, they would break most (in a general sense)
> installs, working only for installs into the default prefix on systems
> that don't use RPATH (which may be most installs on most computers by %,
> but it's still narrow over the set of configurations).
>
> > Built a tar.gz and started down my list of VMs running various Linux
> > distributions.
>
> Certainly you can test what you can test, but I tried to say earlier and
> didn't seem to succeed: All the world is not Linux.  (Besides windows
> and mac) tqsl should work on any system meeting POSIX and for which the
> prereqs are available.  It has been working fine on NetBSD, for example,
> perhaps with a bit of cmake patching, and I would expect it works on the
> others BSDs and even on illumos, with minor effort. I have been
> regularly testing and updating pkgsrc as releases happen for a number of
> years, and I run tqsl on NetBSD for log upload.  I just don't say
> anything because almost always it builds fine.
>
> In addition, the earlier discussion has been focused on installs into
> the default prefix of /usr.  While some packaging systems (typical on
> GNU/Linux variants) do that, some don't, and users who build tqsl
> themselves will almost always use a non-default prefix.  So dropping
> RPATH setting always is basically wrong.  It is reasonable to omit RPATH
> when the libdir is known to be a system libdir that is searched without
> RPATH.
>
> I'm glad to see you testing with /usr/local.  If /usr/local/lib64 is in
> the default search path, though, I suggest you test with /usr/tqsl as
> the prefix, or /usr/foo or something else.  tqsl should work for that
> build too, and with the RPATH stuff taken out I bet it will not.
>
> > The VERY FIRST TRY failed. CentOS 7, It installed libtqsllib.so into
> > /usr/local/lib/  and tqsl couldn't be activated because that library
> could
> > not be found (worked when moved to /lib64).
>
> Presumably you will back out this change then.  You have encountered a
> problem I expected from reading the patch.
>
> > I'm still asking for help here.  People seem to be implying that
> including
> > GNUInstallPaths just fixes these library dependent issues, but I'm not
> sure
> > what to do when trying this runs right into an error.
>
> I think the only reasonable path forward is to understand multiple
> things and design a plan based on that.  I think it's
>
>   have a way to find out if the system puts libs in /lib or /lib64.  As
>   I understand it, lib64 is used on some but not all GNU/Linux systems
>   on x86_64 computers, but not on other CPU types.  Or perhaps also on
>   arm64 (and sparc64, to the extent anything still supports that).
>   lib64 is never used on NetBSD; lib is always for native libs.  I would
>   think Gnuinstallpaths would figure this out, or there'd be some other
>   direct support in cmake, as every single program needs to accomodate
>   this variation in where libs belong.  Perhaps, this can be conditional
>   on the existence of /usr/lib64 if there isn't a better way.
>
>   Set RPATH unless the configured libdir matches /usr/lib or /usr/lib64
>   (if we found out that the system is of the lib64 persuasion).  Or
>   perhaps "set RPATH unless prefix is /usr" is simpler and good enough,
>   and on refletion I lean to it.
>
> The first point is somewhat difficult, and the second should be fairly
> easy.
>
> Can someone comment in more detail on the lib64 convention on various
> GNU/Linux systems?  Specifically:
>
>   On systems with /usr/lib64, does the lib64 convention extend to
>   arbitrary prefixes that a user builds software for?  E.g if I
>   "./configure --prefix=/usr/foo" etc. should that instlal to
>   /usr/foo/lib or /usr/foo/lib64?
>
>   On typical systems, what directories are in the default linker search
>   path, so that libs in them may be found without RPATH?  Is that
>   uniform across GNU/Linux variants?
>
>   Are there any norms and standard procedures for how to find out
>   whether to use lib64 or not?  Please describe.
>
>   Are there any norms and standard procedures for how to find out if a
>   libdir is in the standard linker path and RPATH can be safely omitted?
>
>   Are there norms for when RPATH should be omitted for libir in default
>   path, and are they uniform over all GNU/Linux variants or varying?
>
>
> For NetBSD the answers are
>
>   always lib, never lib64
>
>   /lib, /usr/lib is reliable.  Don't assume more.
>
>   [don't ever do anything about lib64]
>
>   It's ok to omit RPATH for /lib and /usr/lib, and best practice is to
>   do so, but it's also irregular to build programs not provided with the
>   operating system with --prefix=/usr, so this doesn't come up in
>   practice.  It is never ok to drop RPATH otherwise.
>
>
> Hope this helps; there is no easy way out.
>
> 73 de n1dam
>

Thanks, Greg - appreciate the detail here.
This isn't a one-size-fits-all.   And yes, I'm quite aware of non-Linux
systems. If BSD builds are ever broken, I'd like to know.  I'm an OpenBSD
user but that's a firewall so no GUI.
73,
    -Rick
-- 
Rick Murphy, D.Sc., CISSP-ISSAP, K1MU/4, Annandale VA USA