Improve build script

[deviance]

• java/jni/client.c: add support for OpenSSL 1.1
• Add --{enable,disable}-examples flag to toggle examples compilation
• Add --with-system-libsafec flag to link against system libsafec
• configure.ac: Fix AC_ARG_ENABLE/AC_ARG_WITH macros

[deviance]

@rpb5bnc Hey Pete Beal, I'd like to have this reviewed. Thanks

[dieseldad60]

Pete is on vacation and should be returning sometime next week…. On Jul 13, 2020, at 4:34 PM, Aleksandr Makarov <[email protected]<mailto:[email protected]>> wrote: @rpb5bnc<https://github.com/rpb5bnc> Hey Pete Beal, I'd like to have this reviewed. Thanks — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#81 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABZ5VGXH3JA3SG3UXNPDAULR3NVVFANCNFSM4OX7TVCA>.

[deviance]

Hey guys, @rpb5bnc @dieseldad60
Care to look at this?

[rpb5bnc]

It has been being looked at for the past week.  The libEST repo is based upon an internal version of libEST, and the internal version has different requirements then the external implementation.  In order to efficiently maintain the two versions we work hard to keep them the same whenever possible.  For example, there has generally not been a widely used implementation of the SafeC APIs in the industry, so the inclusion of the stub SafeC folder and its use in the external version of liBEST is used to allow the EST specific code to be identical in this regard in both internal and external versions.  In the case of these new PRs/issues, the suggested changes understandably cannot take into account and satisfy the internal requirements.  It was not stated which SafeC package had been installed in the system that you were using, however, I really only know of one out on the Internet and it's this one, https://centos.pkgs.org/7/epel-x86_64/libsafec-3.3-5.el7.x86_64.rpm.html If this is the case, then I'm very familiar with this version of SafeC, or at least, its earlier incarnations.  Bo Berry was the original author of this code and I was one of the two developers required to use it within Cisco in the early 2000s before it became widely adopted across the company.  I even vaguely remember the fact that it does not properly include system header files.  Our internal version of SafeC is generally not installed as an RPM package so the use of, PKG_CHECK_MODULES([libsafec], [libsafec]) will not work correctly for our internal uses.  Using the PKG_CHECK_MODULE() method to determine if a package is installed will not work when the SafeC library has been built specifically for a solution versus just installing the pre-built package.  Almost all of our product teams build our SafeC library for their product and/or platform and therefore the package manager will not know about the installation.  We use the standard method in configure to test for a package by calling an API into the package.  However again, the SafeC API we use for this retrieves the version of the SafeC library, and this API is not part of the APIs in Appendix K, so this won't work for outside or a strictly standard implementation of SafeC.  So, taking in these changes will cause problems inside and just accepting and merging these changes to the external implementation causes the two implementations to again diverge further, causing higher maintenance in the future. In regards to the Java based interface to libEST, we had dropped support of that internally several years ago.  Our internal automatic test pipelines no longer test the CiscoJEST/JEST code.  It was included in this recent update in Github as a way to make it available on an as is basis.  I do see that it needs a bit of change to make it work with the latest build environment, including OpenSSL 1.1.1.  I've looked at these issues and will make the necessary changes.  Again though, we generally did the 1.0.2 to 1.1.1 changes in a slightly different way than has been proposed here. We'll continue to look into the issues and should be able to make the necessary changes shortly. Pete On 7/27/20 1:33 PM, Aleksandr Makarov wrote: Hey guys, @rpb5bnc @dieseldad60 Care to look at this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. [ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "#81 (comment)", "url": "#81 (comment)", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[deviance]

The libEST repo is based upon an internal version of libEST, and the
internal version has different requirements then the external
implementation. In order to efficiently maintain the two versions
we work hard to keep them the same whenever possible. For example,
there has generally not been a widely used implementation of the
SafeC APIs in the industry, so the inclusion of the stub SafeC
folder and its use in the external version of liBEST is used to
allow the EST specific code to be identical in this regard in both
internal and external versions. In the case of these new
PRs/issues, the suggested changes understandably cannot take into
account and satisfy the internal requirements.

Sorry, but I do not see how introduction of an optional configuration flag, which, if not given, falls back to a well-known existing option, may be a problem. Appreciate if you clarify which requirements are needed to be satisfied in this case.

Our internal
version of SafeC is generally not installed as an RPM package so the
use of,

PKG_CHECK_MODULES([libsafec],
    [libsafec])

    will not work correctly for our internal uses.  Using the
        PKG_CHECK_MODULE() method to determine if a package is
        installed will not work when the SafeC library has been
        built specifically for a solution versus just installing the
        pre-built package.  Almost all of our product
    teams build our SafeC library for their product and/or platform
    and therefore the package manager will not know about the
    installation.  We use the standard method in configure to test
    for a package by calling an API into the package. 

The PKG_CHECK_MODULE call is not intended to be a solution suitable for both built-in/system libsafec CFLAGS acquisition.
The PKG_CHECK_MODULE is used as a method of CFLAGS acquisition only when --with-system-libsafec is given to ./configure, and if not, then the hard-coded CFLAGS for the stubbed SafeC are used.

However
again, the SafeC API we use for this retrieves the version of
the SafeC library, and this API is not part of the APIs in
Appendix K, so this won't work for outside or a strictly
standard implementation of SafeC. So, taking in these changes
will cause problems inside and just accepting and merging these
changes to the external implementation causes the two
implementations to again diverge further, causing higher
maintenance in the future.

For system libsafec, I've used a https://github.com/rurban/safeclib which you seem to reference as CentOS RPM.
I've not seen API incompatibilities when switching to it for linking.