Bug 254323 - security/openvpn: Fails to build: FAILED: either of libssl libcrypto libraries linked multiple times
Summary: security/openvpn: Fails to build: FAILED: either of libssl libcrypto librarie...
Status: Closed Not A Bug
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Some People
Assignee: Matthias Andree
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2021-03-16 01:46 UTC by DYM
Modified: 2021-03-16 23:53 UTC (History)
1 user (show)

See Also:
mandree: maintainer-feedback+
mandree: merge-quarterly-


Attachments
make_openvpn.log (102.00 KB, text/plain)
2021-03-16 08:35 UTC, DYM
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description DYM 2021-03-16 01:46:12 UTC
# uname -a
FreeBSD test 12.2-RELEASE-p4 FreeBSD 12.2-RELEASE-p4 r369447 GENERIC  amd64

Make openvpn fail on FreeBSD 12.2 from ports:
===========================================
/usr/ports/security/openvpn FAILED: either of libssl libcrypto libraries linked multiple times
libc.so.7
libcrypto.so.11
libcrypto.so.111
libdl.so.1
liblz4.so.1
liblzo2.so.2
libpkcs11-helper.so.1
libssl.so.11
libthr.so.3
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/security/openvpn
*** Error code 1

Stop.
===========================================

openvpn build wich openssl, and in make.conf enable next line:
DEFAULT_VERSIONS+=ssl=openssl
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2021-03-16 01:58:42 UTC
Thank you for your report.

Can you confirm that this fails at compile/build time? Or install or runtime? 

Can you also provide a full build log as an attachment please
Comment 2 DYM 2021-03-16 08:35:11 UTC
Created attachment 223317 [details]
make_openvpn.log

Maybe it's on line 125 Makefile:
==============================================
if test "$$*" != "1" ; then ${ECHO_CMD} >&2 "${.CURDIR} FAILED: either of ${_tlslibs} libraries linked multiple times" ; ${PRINTF} '%s\n' "$$a"; ${RM} ${BUILD_COOKIE} ; exit 1 ; 
==============================================

For some reason, it thinks that there are two identical files:
...
libcrypto.so.11
libcrypto.so.111
...

because it comes out exactly on this "exit 1" command.

If I remove command "exit 1" (imitation normal continue if-operator) -- openvpn making successfully.
If temporary move /usr/local/lib/libcrypto.so.111 to other place -- openvpn making successfully.

Tomorrow I will do a clean install from scratch and check for a completely fresh install only openvpn to exclude the influence of other ports.
Comment 3 Matthias Andree freebsd_committer freebsd_triage 2021-03-16 16:26:52 UTC
Congratulations, you've proved that the safety net "do not mix the same library in different versions into the executable" is working as intended.  This is a bug in your build, and not known for clean-room rebuilds.

Please find out, in your build/work directory, what libraries and executables require which other, in particular, why and where libcrypto.so.111 comes into the build.

We can't mix two different versions of the same library in one executable or .so file, and that's why the build fails.

In doubt, make sure that your ports directory is up to date and you fully rebuild everything with a consistent view of the default ssl provider.

Also, please provide /etc/make.conf and the output of pkg info, along with its recent change history (pkg logs pkg additions and upgrades and removals thorugh syslog).
Comment 4 DYM 2021-03-16 17:15:25 UTC
On a fresh install of the system and only this port, the problem does not appear.

I know of principle "do not mix" :-)
The point is that they are the same file.
Similar behavior when one of the files is a link to another.
I.e., it appears on the same fresh install when creating a soft or hard link.

It seems to me, that it makes sense to select only "primary" files, checking at least that the second file is not a link. So as not links enumeration mix with "real" file.
Comment 5 DYM 2021-03-16 17:31:51 UTC
Correction.
It seems like this is a reaction only to a hard link.
Comment 6 DYM 2021-03-16 17:47:19 UTC
In principle, the behavior is quite correct. The situation arose because there was a slight confusion in the library list.
I think you can close the bug report.
Even if it does arise, it is a reason to put things dicsipline in the libraries.
Comment 7 Matthias Andree freebsd_committer freebsd_triage 2021-03-16 21:37:09 UTC
(In reply to DYM from comment #4)
I've had crash reports in the past when pkcs11-helper wasn't linked to the same crypto library as openvpn, and the tests pretty much looks at ldd output, and this pretty much is effectively looking at the ELF NEEDED tags FWIW, and normally the linker put the canonical SONAME there.  

And why is there a hardlink under different names of the same library? Seems a rather atypical configuration.

I can reproduce a similar situation on 12.2-amd64 when installing the openssl port or package, so I have these in parallel:

$ /usr/bin/openssl version -a
OpenSSL 1.1.1h-freebsd  22 Sep 2020
built on: reproducible build, date unspecified
platform: FreeBSD-amd64
options:  bn(64,64) rc4(8x,int) des(int) idea(int) blowfish(ptr) 
compiler: clang
OPENSSLDIR: "/etc/ssl"
ENGINESDIR: "/usr/lib/engines"
Seeding source: os-specific

$ /usr/local/bin/openssl version -a
OpenSSL 1.1.1j  16 Feb 2021
built on: Fri Feb 26 05:24:51 2021 UTC
platform: BSD-x86_64
options:  bn(64,64) rc4(8x,int) des(int) blowfish(ptr) 
compiler: cc -fPIC -pthread -Wa,--noexecstack -Qunused-arguments -O2 -pipe  -fstack-protector-strong -fno-strict-aliasing -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -D_THREAD_SAFE -D_REENTRANT -DNDEBUG
OPENSSLDIR: "/usr/local/openssl"
ENGINESDIR: "/usr/local/lib/engines-1.1"
Seeding source: os-specific


As we can see, these are not at all the same.

$ readelf -d /usr/lib/libcrypto.so 
...
 0x000000000000000e SONAME               Library soname: [libcrypto.so.111]
...

$ readelf -d /usr/local/lib/libcrypto.so 
...
 0x000000000000000e SONAME               Library soname: [libcrypto.so.11]
...


So again, the libraries are not the same.  

You can find out which includes what with ldd -a /usr/local/sbin/openvpn (or the corresponding build directory). I think I'll add that ldd -a to the error path.

I can reproduce this:
- install pkgcs11-helper such that it uses base openssl
- install openssl as port or pkg
- build openvpn

and then I see openvpn links against libcrypto.so.11 and libpcks11-helper.so.1 links against libcrypto.so.111.
Comment 8 commit-hook freebsd_committer freebsd_triage 2021-03-16 21:46:44 UTC
A commit references this bug:

Author: mandree
Date: Tue Mar 16 21:45:51 UTC 2021
New revision: 568617
URL: https://svnweb.freebsd.org/changeset/ports/568617

Log:
  security/openvpn: run ldd -a when multi-link of "same" library found

  The build runs a sanity to check that libssl and libcrypto are linked
  only once, to catch mismatches in SSL providers to libpkcs11-helper
  and openvpn itself.  In order to assist the operator to find out
  which libraries pull in differing versions of libcrypto or libssl,
  run ldd -a in the error path. (Not run normally, not PORTREVISION bump.)

  PR:		254323 (related)

Changes:
  head/security/openvpn/Makefile
Comment 9 DYM 2021-03-16 22:13:27 UTC
Perhaps this error was related to:
1) Bug 232169 - security/ipsec-tools: Fails to build with OpenSSL 1.1.1
2) Bug 254296 - textproc/iksemel: fails to build in 12.2 amd64
since there build errors are related to availability and options DEFAULT_VERSIONS in make.conf
Comment 10 DYM 2021-03-16 22:25:15 UTC
Thanks for a very fast reaction.
For the future it will simplify the parse make errors.
This is important because the last time with the openssl update associated with a lot of build errors of other packages.
Comment 11 Matthias Andree freebsd_committer freebsd_triage 2021-03-16 23:53:47 UTC
(In reply to DYM from comment #9)
I've only had a brief look at each of them, but they appear unrelated, at first sight.

(In reply to DYM from comment #10)
Yup. If you switch important central components of the system, such as from base OpenSSL to ports/pkg OpenSSL, or back, or from -devel to stable, you more or less need to reinstall all packages that link to it for consistency.

For openvpn in particular, you should likely be able to get away with choosing your OpenSSL implementation and then rebuilding libpkcs11-helper and only then openvpn, but that's something I surmise and haven't tested.