Re: [Trustedqsl-testing] OpenSSL 3.0.0

[Greg T. <gd...@le...>]

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